8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: Yuriy K. on 11 Sep 2006 23:17 Vladimir Vassilevsky wrote: > >> I did some flash programming routines for HC08/HC12 cores. Some >> compilers can generate relocatable code, some can't and you have to >> use assembler. > > Some linkers can make the location of execution > different from the location where the code resides, the others can't. This was the problem. > However you can always manipulate with the hex files. Which is outside of the compiler control. You can even develop your own object file processor if necessary, but the point is to do it using just the capabilities present in the compiler/assembler/linker. It was easier for me to write single location independent function to program flash byte/word and call it from C code. -- WBR, Yuriy. "Resistance is futile"
From: John F on 12 Sep 2006 04:57 Yuriy K. wrote: > 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 No. I won't ;-p > You might need one more little feature, but there is no room for > improvement. There is always room... just port one or two things to asm and see, there is enough place for putting it in twice. C is for convenience only. >>>>> 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. Well... No. Non sequitur! >>> 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. :) Then your field of operation will be very limited. >>> 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. It is! Of course not for someone like you. Someone fond of the underlying assembler would do. It has to be maintainable since it is production code. Every step is documented and the number of cycles taken is noted on every change. Has to be done, has to work. Is done, is working. >> 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. It makes timing issues worse. I've done things on a 2k System you wouldn't even get into a 16k System. That's the difference between asm and C. C is a general purpose tool. ASM is the special case tool. That's it. You won't take a hammer to saw a brick of wood :-) -- Johannes You can have it: Quick, Accurate, Inexpensive. Pick two.
From: Terran Melconian on 12 Sep 2006 09:25 On 2006-09-06, steve <bungalow_steve(a)yahoo.com> wrote: > > Joerg wrote: > so how do think other engineers design MSP430 products without this > info? Same problem with the AVR datasheets. Design by experimentation We generally don't anymore. We tried a design using an AVR's internal comparator. The next revision put it back in an external device. On the other hand the ADC has been adequate for a lot of purposes. Our general policy now is that any internal analog components on uCs should be presumed worthless until proven otherwise, especially considering the lack of adequate specifications. We suspect they let the digital guys build them for fun or something. :)
From: Joerg on 12 Sep 2006 10:26 Hello Yuriy, >>>>>> >>>> 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. > It is but you could also get a layout package from them. However, it was not used much back then and the layout was done on Autotrax or others. I cannot see a major productivity difference between then and today. For an intricate analog board it still takes about two weeks until first fab is done, like it used to. And we still have the same incompatibilities where the only way to get the data into the layout package is a netlist. If the EDA industry had buried their tomahawks and agreed on an EDIF standard productivity would be higher. But they didn't. > PCAD2004/PADS/Pulsonix/even Eagle will easily beat this package today. > Even Altium Designer can beat it. > PADS is what my layouter also uses. But he does not do expensive upgrades every time they holler. Neither do I :-) >>>> 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. :) > Nope. But my chisel does. That's why we know so much about the Romans ;-) >> 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 could embed schematics, pictures, tables and whatever I wanted into DOS-Word. No problem. Also database lists. Excel probably as well but I am a firm believer in databases so I did not use it much and still don't. >> 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... > ASCII is a wonderful standard. Has saved many people's butts when salvaging old docs. But again, for longevity I prefer chisel and granite :-) -- Regards, Joerg http://www.analogconsultants.com
From: Joerg on 12 Sep 2006 11:58
Hello John, >>>>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. :) > > Then your field of operation will be very limited. > Yuriy probably has not yet worked in a cut-throat cost environment like consumer or dispoable medical. Selecting too big a micro can put you out of business there. > >>>>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. > > It is! Of course not for someone like you. Someone fond of the > underlying assembler would do. It has to be maintainable since it is > production code. Every step is documented and the number of cycles > taken is noted on every change. Has to be done, has to work. Is done, > is working. > The key word is "Every step is documented ...". Good point. Comments in the code ain't enough although some people think it is. Anything other than a top-down architecture with a thorough FRS and version control isn't going to fly in the long run and would raise a red flag with FDA and agencies like that. > >>>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. > > It makes timing issues worse. I've done things on a 2k System you > wouldn't even get into a 16k System. That's the difference between asm > and C. C is a general purpose tool. ASM is the special case tool. > That's it. You won't take a hammer to saw a brick of wood :-) > My father automated a whole cold-rolled steel line with 2k because that's all the early machines had. Nowadays the young lads need 128MB+ just to be able to write "Hello World". -- Regards, Joerg http://www.analogconsultants.com |