At 20:29 04-04-08 -0700, Vitaly Luban wrote: >N. Coesel wrote: >> At 05:35 04-04-08 -0700, Vitaly Luban wrote: >> >>> So what? It does not change the fact that I have all the BDM details for >>> all the processors I need, >>> I have my own JTAG supporting ARMs (OpenOCD) and Freescale, and what do >>> you have for >>> latest MSPs? Closed source windoze dll? >>> >>> If Freescale go down the sink I can easily switch to STM, albeit STM is >>> a bit more expensive... >>> >> >> If you write you code portable, you can use and CPU you want. > >That is not true. First of all, certain "features" of the mspgcc make it >difficult to >use even highly portable code on MSP w/o additional sizable effort.
In that case you are doing something very wrong. I'm using the same code (even the standard library from MSPGCC) on several ARM devices, MSP430 and Renesas devices without any pain. Just hit compile and go (ofcourse the low level hardware drivers and startup-code are different). >> Besides, >> debugging on an embedded device is not the fastest way to debug. > >This is also not exactly true. While it is possible to do the "proof of >concept" this way, >real embedded code on a production board will have totally different >timing profile, so >any possible timing bug /race will possible be unnoticed in a PC >implementation, Then, That is an often heard excuse. But in practise very few processes are real time. Race conditions can be eliminated by carefull design. >peripherals, like a/d and d/a converters etc. one can use on a PC will >have different >charaqcteristics like linearity, error magins, noise... That makes it >impossible to do real >world debugging using simulation. I'd like to turn that around. On a PC you can simulate the extends of noise, non linearities, etc, etc to proof software works even if the analog parts are on the edge of their specs. And ofcourse it takes some experience to know what kind of constructs work or won't work on an embedded device. Being able to maintain software is the key word here. Rewriting or maintaining different versions for different platforms is a real pain in the ass (and can kill a company because they got trapped by a solution). Just a few weeks ago I wrote a set of routines that will work on microcontrollers (like ARM, MSP430), Windows and Linux. This means a bug can be fixed or functionality added for all platforms in one go. Because the routines where designed with the microcontroller environment in mind they have a very low memory footprint if they have to. Using GCC as a compiler is a key factor here. >> Just write >> for Windows/Linux first and then port your code to the embedded device. >> You'll find you won't need JTAG for debugging at all. >> >> >Have you done any real project so far? Real device that's produced in >enough quantity >to force you to shave fractions of cents from the design as every extra >0.1 cent in the BOM >means some $100,000.00 loss for you? Try it and you'll see for yourself >that you're wrong >here. If you have to shave off such small amounts, then the exchange rate of de dollar, oil prices, salary increases, etc have more influence on your product price than adding or removing a resistor from your design. And yes I have been doing real projects for the past 15 years. Nico Coesel
