Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
02/24/11 07:54
Read: 1112 times

#181297 - I don't ever build on target hardware unless target is a PC
Responding to: Richard Erlacher's previous message
I have been working for a number of years with a Linux-based platform.

But I do 100% development on a PC running Linux - or a standard Linux installed in a VMware virtual machine.

A large percentage of the code can be debugged on the PC (since a large percentage of Linux applications can be compiled and run on a large set of Linux-supporting platforms). The Linux have drivers for most peripherials in which case I don't need to debug any drivers. I just have the application use similar devices on the Linux of the PC. I sometimes creates virtual devices on the PC, so I can simulate input from hardware on the real target. For example a GUI showing all digital inputs/outputs as graphical LED:s and switches and with knobs or sliders for analog values.

But the GNU debugger gdb can also perform network debugging, in which case you can run the debugger on a PC (Windows or Linux) and debug a Linux application on the Linux target.

Doing the source code management, building, most of the debugging etc on a PC is way faster, easier, streamlined, ... A PC can potentially stream 50MB of log data/second from an application while still run the application at the real-time speed required for the intended target hardware. A target hardware don't have huge excess capacities unless I force the customer to buy a device that is seriously overspeced for the intended job.

But all the above is for developing software for embedded use on a Linux target.

Lost of the development are for non-Linux targets, i.e. normal ARM7 or Cortex-class processors. In that case, a typical target hardware may have 32kB of RAM and 256kB of flash. So the programs are built on the PC (the target hardware isn't even capable of running a real tool chain). And the upper layer logic can be debugged as modules on any PC (Windows or Linux doesn't matter as long as the code can be compiled for that target - uint32_t is a 32-bit integer supported by all standard-compliant C compilers so code making use of it can be tested anywhere).

The lower level code that makes use of interrupt handlers, FIFOs, magic SFR etc have to be debugged on the target hardware. Easy to do with a JTAG interface. And once the interrupt-driven FIFO-using UART code does work, I don't need to worry about it anymore. One day to fix support for UART0, UART1, UART2, UART3 and put into my "library" for the specific processor. One or more days to add master-side SPI support, or ADC support etc.

The big difference between an ARM and a 8051 is that the ARM instruction set works so much better with high-level languages. So I can write C code for all devices, and implement them as some form of driver layer. And then add the business logic on top. And the mapping between C and actual hardware will mange to produce a compound binary that will still run (for most of the time) only some percent slower than a fully hand-written assembler module where the business logic is glued into the hw access code for maximum optimization.

So Linux targets are only used when the product needs that type of functionality. Maybe because it is expected to run with multiple Ethernet interfaces and perform firewalling. Maybe it is expected to be able to remotely download new software applications to learn new tricks years after the equipment was installed out in the field, using a GPRS, HSDPA, HSUPA, CDMA, ... modem.

Most of the time, I see ARM chips as similar building blocks as standard 8051 chips, and costing maybe $5 and down to less than $1. And which ARM that gets used depends on number of pins, and specific peripherials implemented, amount of RAM + flash etc in relation to the specific project. When I can, I prefer to stay in same family since that allows me to keep the low-level code almost unchanged.

As a foot note - even for 8051 code, I always look into what functions I can compile and test with a PC compiler allowing the build machine to perform automatic code testing besides the system testing on the real hardware. The real hardware is of course the only (as I see it) practical way to introduce the specific timing restrictions.

List of 65 messages in thread
NXP suggests 32-bit ARM Cortex-M0 family for 8-bit replaceme        Jan Waclawek      02/21/11 04:03      
   Funny indeed!      Andy Neil      02/21/11 05:15      
      Rest of NXP's 8051 line to follow..?      Valentin Angelovski      02/21/11 05:37      
         comments      Erik Malund      02/22/11 08:23      
            I've been watching them for 20 years now ...      Richard Erlacher      02/22/11 08:40      
               So, what to do?      David Good      02/22/11 09:58      
                  Biting the ARM bullet      Andy Neil      02/22/11 10:27      
                  SST89E58      Jan Waclawek      02/22/11 11:15      
                  Well, if I had to do something ...      Richard Erlacher      02/22/11 21:32      
                     Linux?      Per Westermark      02/22/11 22:34      
                        Just a thought ...      Richard Erlacher      02/24/11 07:15      
                     Leaping to Linux would be ludicrous!      Andy Neil      02/23/11 00:17      
                        Unless...      Andy Neil      02/23/11 01:07      
                           The target wouldn't necessarily be the host      Richard Erlacher      02/24/11 07:26      
                              I don't ever build on target hardware unless target is a PC      Per Westermark      02/24/11 07:54      
                        Supplement - not replace      Andy Neil      02/23/11 01:21      
                           I can't disagree      Richard Erlacher      02/24/11 07:29      
                              Competition always needed      Per Westermark      02/24/11 08:05      
                              not everyone wants the 805x to survive      Andy Neil      02/24/11 08:29      
                                 newer '51 releases      Erik Malund      02/24/11 08:44      
                        It depends on your ultimate goal ...      Richard Erlacher      02/24/11 07:18      
                     Real cheap ARM eval boards      Oliver Sedlacek      02/23/11 02:19      
                        ADuC ARM      Jan Waclawek      02/23/11 02:23      
                           Nearly, ADuC702X      Oliver Sedlacek      02/23/11 04:11      
                        Yes! Lots of Real cheap ARM eval boards!!      Andy Neil      02/23/11 02:36      
                           Why go cheap ...      Christoph Franck      02/23/11 03:19      
                              Prototyping can interfere with extras        Per Westermark      02/23/11 03:30      
                                 "nfity" != "useful" or "helpful" (necessarily)      Andy Neil      02/23/11 03:59      
                                 That's often a problem with EvK's      Richard Erlacher      02/24/11 07:36      
                                    50/50 Agree/Disagree      Andy Neil      02/24/11 08:21      
                                       Perhaps you're right about the second point      Richard Erlacher      02/25/11 02:05      
      Cortex-M0s      Christoph Franck      02/21/11 06:00      
         "low end"      Andy Neil      02/21/11 06:18      
            How low is "low" ?      Andy Neil      02/21/11 06:22      
            money      Jan Waclawek      02/21/11 06:30      
               Depends on view      Per Westermark      02/21/11 07:07      
                  the small embedded view      Jan Waclawek      02/21/11 07:38      
                     yes      Per Westermark      02/21/11 08:22      
                        applications of low pin count      Jan Waclawek      02/21/11 08:35      
                           Either help with real-time or with wire count/length      Per Westermark      02/21/11 08:47      
               Money and technology      Oliver Sedlacek      02/22/11 01:23      
                  ARM core already tiny enough that you gain no more      Per Westermark      02/22/11 02:24      
                     Fab costs      Oliver Sedlacek      02/22/11 03:58      
                        Old fabs or old fab equipment      Per Westermark      02/22/11 04:57      
               Other Meanings      Andrew Ayre      02/24/11 03:14      
   Colonial English      Andy Neil      02/21/11 14:32      
      No new models      Per Westermark      02/21/11 15:07      
         End of the roadmap      Andy Neil      02/21/11 15:49      
   Anachronism      Andy Neil      02/21/11 15:50      
      Quite common to extend meaning of old terms      Per Westermark      02/21/11 16:35      
   a bit related      Erik Malund      02/24/11 09:23      
      Doesn't add any advantage so totally cornered      Per Westermark      02/24/11 09:34      
         16-bitters      Jan Waclawek      02/24/11 11:11      
            I think you missed the point      Per Westermark      02/24/11 12:28      
   NXP 8051s      Jim Granville      03/08/11 20:33      
      you are a bit slow      Erik Malund      03/09/11 06:23      
         you are a bit slow      Andy Neil      03/09/11 09:14      
            lots of power needed to swing 5V devices      Per Westermark      03/09/11 11:06      
               not just the swing      Erik Malund      03/09/11 11:58      
                  The area myth gets busted      Jim Granville      03/09/11 13:28      
                     Long time since chips started to get different scaling      Per Westermark      03/09/11 13:48      
         Wide Vcc is growing trend      Jim Granville      03/09/11 12:10      
            no such ceiling, just no avoidance      Erik Malund      03/09/11 12:49      
      3V3 or 5V      Per Westermark      03/09/11 06:41      
         Oxide thickness      Jim Granville      03/09/11 13:39      

Back to Subject List