There is a really good open source code library for the EzSBC2 at https://github.com/microbuilder/LPC11U_LPC13U_CodeBase .
I will write a board projectconfig.h file as soon as I get a chance.
The easiest to install (on Windows) tool chain is probably the one based on Code::Blocks with the mingw GCC compilers found here http://www.codeblocks.org/downloads/26
For commercial offerings, Rowley Crossworks for ARM is probably the best value for money and it definitely has the best support staff and response times. It is also fully cross platform with executables available for Windows, Linux and Mac OS X.
For people who want to write code 'that just works' look at the Oberon compiler offered here : http://www.astrobe.com/default.htm
The EzSBC2 is fully supported by the compiler.
Daniel
Code for the EzSBC2
Re: Code for the EzSBC2
Hi Daniel,
After brief background I'd like to ask a few questions about Code::Blocks, answers to which were not easily found on their website.
I've never used Code::Blocks. A brief scan of their web pages didn't list supported OSes but I found mention of Ubuntu (my OS) in the forums so I assume Code:Blocks is supported.
I use and continue to develop software for my embedded and control projects on laptops (Ubuntu), TI and Atmel targets. I try to reuse as much code as I can so C/C++ is my preferred language.
1) does Code::Blocks support target debugging, i.e. single step, breakpoints, inspecting variables, reading memory, etc?
2) do you happen to know whether this type of debugging is available on linux (Ubuntu)?
3) Is the USB/bootloader the primary means of debugging? Only, if not JTAG?
Thanks
After brief background I'd like to ask a few questions about Code::Blocks, answers to which were not easily found on their website.
I've never used Code::Blocks. A brief scan of their web pages didn't list supported OSes but I found mention of Ubuntu (my OS) in the forums so I assume Code:Blocks is supported.
I use and continue to develop software for my embedded and control projects on laptops (Ubuntu), TI and Atmel targets. I try to reuse as much code as I can so C/C++ is my preferred language.
1) does Code::Blocks support target debugging, i.e. single step, breakpoints, inspecting variables, reading memory, etc?
2) do you happen to know whether this type of debugging is available on linux (Ubuntu)?
3) Is the USB/bootloader the primary means of debugging? Only, if not JTAG?
Thanks
Re: Code for the EzSBC2
Hi
Many people start off by using a compiler and serial port debug strategy like they do or did for PIC's and AVR's. They spend an enormous amount of time reinventing basic things such as a working C library and startup code.The quality of the C-library that you use will determine your mental health if you write anything but tiny programs. A much better use of time and money is to buy one of the two tool suites that come with decent C-libraries, debuggers and supports a host of different vendors, CPU models and hardware debuggers. There are two really excellent tool suites available for moderate amounts of money. Rowley Crossworks for ARM is sensibly priced, works on Windows, Linux and MAC and has an excellent C-library that includes a multitasking library. The other is the CodeSourcery tools. The IDE is based on Eclipse (not the greatest) and it has an OK C-library. It has a proper source level debugger that supports many third party debugging tools. They have free versions available with limitations on the debugger. Both tool suites use the GNU tools as the compilers, linkers etc and provide custom debuggers (instead of gdb) that work well. I'm somewhat locked into the CodeSourcery tools but should I buy today, I'd buy the Rowley tools. The CodeSourcery tools work on (at least) Windows and Linux but may require more than one license. Rowley has one license per developer, independent of the platforms used.
Commercial IDE's save time and frustration but cost money. Most embedded tools are insanely expensive but the ARM tools provide excellent value for money. Note that I didn't mention the traditional tool vendors and some other Eclipse based tools. They are either too expensive or don't provide much by way of value and try to lock you in with weird libraries. I have experimented with at least four more tool sets that I can't recommend even if they work well or they have proven to be a major waste of time.
I started working with a command line compiler, Olimex debugger and worked like that for a while. I spent more time debugging my setup, C-library and debugger than I did making my project work. I got an evaluation version of Crossworks and CodeSourcery tools and eventually bought the CodeSourcery tools because of an offer too good to pass up. I mostly use an editor and command line tools with their library but for stubborn bugs I break out the debugger. I liked (and still do) Crossworks better but I was bribed by a good price. BTW, I have no relationship with either company.
Hope this helps.
Daniel
Code::Blocks is an editor with support for debugging, particularly gdb, but you need a target interface for that to work and that is normally some form of JTAG or SWD debugger with support for gdb. There are relatively few low cost debuggers available with gdb support. The Segger J-Link has good support but it does not qualify as low cost. Olimex makes a debugger that has gdb support but the software is not by Olimex and was very hard to get working if you don't know quite a bit about the weirdness of ARM CPU's. The software is Open Source and it is called OpenOCD. Lots of information here: https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD/ . I have not used it in some time so my information may be badly out of date.1) does Code::Blocks support target debugging, i.e. single step, breakpoints, inspecting variables, reading memory, etc?
Yes it is. OpenOCD works pretty much everywhere.2) do you happen to know whether this type of debugging is available on linux (Ubuntu)?
Pretty much. Most people who use ARM CPU's seriously buy some form of IDE with a debugger. You can get a lot done with a serial port (or VCOM port) and print instructions if the compile, upload, debug cycle is fast. The USB drive method of uploading code is very fast and is used a lot without debuggers. The library that I pointed to in another post has working routines so it is easy to get going.3) Is the USB/bootloader the primary means of debugging? Only, if not JTAG?
Many people start off by using a compiler and serial port debug strategy like they do or did for PIC's and AVR's. They spend an enormous amount of time reinventing basic things such as a working C library and startup code.The quality of the C-library that you use will determine your mental health if you write anything but tiny programs. A much better use of time and money is to buy one of the two tool suites that come with decent C-libraries, debuggers and supports a host of different vendors, CPU models and hardware debuggers. There are two really excellent tool suites available for moderate amounts of money. Rowley Crossworks for ARM is sensibly priced, works on Windows, Linux and MAC and has an excellent C-library that includes a multitasking library. The other is the CodeSourcery tools. The IDE is based on Eclipse (not the greatest) and it has an OK C-library. It has a proper source level debugger that supports many third party debugging tools. They have free versions available with limitations on the debugger. Both tool suites use the GNU tools as the compilers, linkers etc and provide custom debuggers (instead of gdb) that work well. I'm somewhat locked into the CodeSourcery tools but should I buy today, I'd buy the Rowley tools. The CodeSourcery tools work on (at least) Windows and Linux but may require more than one license. Rowley has one license per developer, independent of the platforms used.
Commercial IDE's save time and frustration but cost money. Most embedded tools are insanely expensive but the ARM tools provide excellent value for money. Note that I didn't mention the traditional tool vendors and some other Eclipse based tools. They are either too expensive or don't provide much by way of value and try to lock you in with weird libraries. I have experimented with at least four more tool sets that I can't recommend even if they work well or they have proven to be a major waste of time.
I started working with a command line compiler, Olimex debugger and worked like that for a while. I spent more time debugging my setup, C-library and debugger than I did making my project work. I got an evaluation version of Crossworks and CodeSourcery tools and eventually bought the CodeSourcery tools because of an offer too good to pass up. I mostly use an editor and command line tools with their library but for stubborn bugs I break out the debugger. I liked (and still do) Crossworks better but I was bribed by a good price. BTW, I have no relationship with either company.
Hope this helps.
Daniel
Re: Code for the EzSBC2
I forgot to mention that I had issues with the Olimex driver for the debugger when other boards use the native drivers for FTDI chips. It is particularly awkward to debug a board with an Olimex debugger if the board itself has a FTDI chip on the board. I never resolved this issue and YMMV but I moved to a different debugger.
Daniel
Daniel