8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Joerg on 9 Sep 2006 17:23 Hello Dimiter, >>Sure. But often we have to make do with the bare bones in CPU resources. >>Turn every dime around and around. ... > > That would make a real lot of dime turning... to save the few % power > (which you are bound to have anyway in your system if it can do the > task synchronously) it takes to do simple things like separating > buffering, processing and real time actions... Perhaps an > option if you have no real programmer around, I don't know. > I have even turned pennies around :-) > >>Many times we use uCs as state machines and then they have to perform >>the same way as if we had done it in logic chips. IOW totally >>process-synchronous. > > You certainly don't need to do those state machines 100% synchronously, > you just need to make sure the output states change when they have to > and you take the input signals you need. There is such a lot of > mechanisms > to do these things I really have a problem to pick an example, perhaps > a good > one would be the output compare timer mechanism introduced to me > many years ago with the HC11, or FIFO sort of things etc. It takes no > programming genius to do most of these (but it does take some > programming > literacy allright). > Yes, but these mechanisms require the availability of a timer. Or often "the" timer because there is only one, as mentioned earlier. Many times this timer is already loaded with lots of jobs. Recruiting the WDT away from its original purpose can't always be done, at least not in medical electronics. The agency folks would frown if we did. -- Regards, Joerg http://www.analogconsultants.com
From: Jim Granville on 9 Sep 2006 17:42 Ulf Samuelsson wrote: > I would be much, much better to have a little extra performance > and a more advanced timer which would idle the CPU until a condition occurs. > > #define CYCLE_TIME 0x4711 > > uint16 TIMER_CNT=0; > uint16 next_top = 0; > sbit(START_TIMER,TIMER_CTRL); > > loop > TIMER_TOP_VALUE += CYCLE_TIME; > // do something... > sbit(WAIT_UNTIL_TOP_VALUE,TIMER_CTRL); > __sleep(); > end loop; We have done this, and the (eg) 80C51 wakes up from sleep with no jitter, but this solution places some large restrictions on the system: one is that sleep cannot exit elsewhere (eg UART int). A solution that appeals for uC, is that of hard thread timeslices. Ubicom have niche devices doing this. Hard thread timeslice is a design candidate for FPGA cores, where a core can easily flip access to BRAMs. Larger devices can have co-processors handling hard-time tasks, like the eTPU in freescale's devices, but they are not your 80c uC :) We have used two (small) 80C51's in systems where tight time control is needed of core-tasks, and they are getting smaller/cheaper : eg AT89LP216 makes a great smart UART. SPI-RS485 for example ? -jg
From: Yuriy K. on 11 Sep 2006 22:59 Joerg wrote: >>>>>> Very good example. I vote for today's software over any 10-years old. >>>>>> And definitely over any 25-years old software... >>>>> >>> OrCad SDT-III 3.22 >> >> Inferior to almost any current PCB design package. Very limited >> capability. >> > > In which ways is it inferior and limited? In productivity. I.e. how long will it take you to get from idea to the routed PCB. I used it a little about 15 years ago. It was quite good at that time, but PCAD 4.5 happened to have more features and complete support from schematic to PCB and backward. AFAIR, SDT is just a schematic capture. One still had to use a separate PCB routing software. PCAD2004/PADS/Pulsonix/even Eagle will easily beat this package today. Even Altium Designer can beat it. >>> MS-Works >>> DOS-Word >> >> Inferior to current MS office set. Or even to OpenOffice. > Sorry, but I don't think so. MS-Works does all my record keeping nicely. I bet notepad will do all your records even better. :) > I can work on the files in DOS or a newer Win version, no problems. Embedded pictures, graphics, excel and visio objects, styles, tables, spell checker, bla-bla-bla. > I would still use DOS-Word if it weren't for the fact that I must handle > files created by others with Win versions and also because MS has > (unfortunately) chosen to not pay much attention to backward > compatibility. In Works they did, in Word they didn't :-( Use notepad and plain ACSII text. Compatibility forever. Best way to keep records is to print them on the plastic. Metal engraving is even better, but a little bit inconvenient... -- WBR, Yuriy. "Resistance is futile"
From: Yuriy K. on 11 Sep 2006 23:03 Eric wrote: >> I'd never buy a car with dozens of controllers. > > It's getting hard to buy a car now that has less than a dozen > controllers, if you consider all of the electronic gizmos (power > mirrors, power steering, power windows, air bags, anti-lock brakes, > cruise control, fuel injection, electronic ignition, emissions control, > entertainment systems, ...). > > The trend is still moving upward with no end in sight. That's why a lot > of controller makers have recently introduced CAN support, and extended > termperature range devices. One could repair some 1950 model. Keep it clean and shiny and it could take a part in antique car show. :) -- WBR, Yuriy. "Resistance is futile"
From: Yuriy K. on 11 Sep 2006 23:11
John F wrote: > C has it's place. Sure. Everyday stuff should be done there. But if > you ever had to switch to a larger ?C just because of a few bytes of > code don't fit into memory, you'll soon learn to use ASM... trust me. Or you'll soon learn to choose bigger processor. Trust me. :P You might need one more little feature, but there is no room for improvement. >>>> I write all my interrupt routines in C. It means the proper >>>> processor >>>> selection and good task division between interrupt and >>> And? :-) >> And the rest of the software. Minimizing tasks you need to do in the >> interrupt is very helpful. > Less than 5 lines of ASM is hardly ever possible. Still 80% of time is > taken there. Inadequate processor or overall system architecture selection. Both 5 lines and 80% of time tell that. >> Unfortunately, I did quite a lot of x51 assembly programming. Just >> did not know better at that time. Fortunately, these days were long >> ago. > > They are back! Not for me. :) >> I could believe that you have specific constraints in the >> particular design. I could not believe that using assembler is the >> only solution or even the best solution. > > It is the only solution. You can't guarantee in C that with every > optimisazion you get the same length of execution time. It's just not > possible. This code is not maintainable. > I don't even do inline assembly because of the prologue and > epilogue the compiler adds. > > You don't have any control over that in C. That's what C is about! It > hides this stuff. Exactly. It improves software development time. -- WBR, Yuriy. "Resistance is futile" |