- Fri Nov 19, 2010 3:15 am
#113900
Using a codesourcery toolchain is as simple as a tar command (on linux).
Building a gcc toolchain is something a little more tricky. Having it build is only a small part from it, having good binutil/gcc/lib versions is the real part.
I agree that most people never need to do this, except student because it's a very valuable knowledge (it's mandatory to know how a toolchain works this if you want to be hired where I work). Some linux distribution (like gentoo) make the toolchain building an easy task.
Setup a full IDE system with prebuild toolchain and eclipse with pluggins is a matter of an hour.
The toolchain is only a compiler/linker and sometime C library for a given architecture,ie familly of processors for short, like arm. You can use the same toolchain with arm processors from ST, NXP or other for example (unless the arm familly variant is not supported by the toolchain). It's like GCC for x86: you can build code from i386 to the latest core familly of processor.
Then you need additional support: additional library support, board support files (like startup file and linker files).
IDE packages all this with they own build system/debugger/editor, I do not like this approach myself as I mainly worked on projects that do not fit this approach (and being also an emacs addict).
For the JTAG, it's more or less used as a debug and programming interface. In fact it is a very low level interface to the chip, but it's another story.
You can use it for programing, but it's primary use is debugging. For programming, a bootstrap on usb/serial is often easier and faster to use.
OpenOCD allows to link you board to GDB debugger, through the JTAG interface. OpenOCD needs to know how to access your jtag interface. I use myself a embeddedproject jtag interface which is well supported and fast enough for my use, and it's cheap also.
OpenOCD allows also to program your board thought script.
OpenOCD itself is very painful to configure: very low level, configuration changes between major versions (making some examples found on the net obsolete).
Building a gcc toolchain is something a little more tricky. Having it build is only a small part from it, having good binutil/gcc/lib versions is the real part.
I agree that most people never need to do this, except student because it's a very valuable knowledge (it's mandatory to know how a toolchain works this if you want to be hired where I work). Some linux distribution (like gentoo) make the toolchain building an easy task.
Setup a full IDE system with prebuild toolchain and eclipse with pluggins is a matter of an hour.
The toolchain is only a compiler/linker and sometime C library for a given architecture,ie familly of processors for short, like arm. You can use the same toolchain with arm processors from ST, NXP or other for example (unless the arm familly variant is not supported by the toolchain). It's like GCC for x86: you can build code from i386 to the latest core familly of processor.
Then you need additional support: additional library support, board support files (like startup file and linker files).
IDE packages all this with they own build system/debugger/editor, I do not like this approach myself as I mainly worked on projects that do not fit this approach (and being also an emacs addict).
For the JTAG, it's more or less used as a debug and programming interface. In fact it is a very low level interface to the chip, but it's another story.
You can use it for programing, but it's primary use is debugging. For programming, a bootstrap on usb/serial is often easier and faster to use.
OpenOCD allows to link you board to GDB debugger, through the JTAG interface. OpenOCD needs to know how to access your jtag interface. I use myself a embeddedproject jtag interface which is well supported and fast enough for my use, and it's cheap also.
OpenOCD allows also to program your board thought script.
OpenOCD itself is very painful to configure: very low level, configuration changes between major versions (making some examples found on the net obsolete).