I'm a software guy. New to ARMs. Not new to software in general or embedded
in particular.
Need something that would drive a 7" TFT. Not much besides the LCD, maybe a
USART or two.
Looking at this kit to start with:
http://www.digikey.com/product-detail/en/UEZGUI-1788-70WVT/622-1058-ND/3202483
The kit seems to come with some sort of eUZ GUI library, which seems to use the
Rowley Crossworks compiler. Nothing against either one, especially since I
don't really know anything about either one. If I get the kit, I think for
now I will just use whatever tools it will come with. But I'm a command
line/makefile/emacs kind of guy. Therefore, in the longer term, I would like to
do something more ambitious, like blink an LED or something like that, on a bare
LPC1788 board, with the plain GCC? How would one go about doing something
like?
- What arm*gcc.exe (for Windows) to get?
- Where to get it?
- What about libc/crt?
Questions like this probably have been answered million times already. But, you
know, every time you try to start doing new, your google-fu ability somehow get
lost ...
Thanks,
Eugene
How to blink LED on LPC1788
Started by ●May 21, 2013
Reply by ●May 21, 20132013-05-21
Hi
> - What arm*gcc.exe (for Windows) to get?
> - Where to get it?
=> https://launchpad.net/gcc-arm-embedded
> - What about libc/crt?
libc => newlib, part of the tool chain. crt might need some tweaking (I
use my own).
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
> - What arm*gcc.exe (for Windows) to get?
> - Where to get it?
=> https://launchpad.net/gcc-arm-embedded
> - What about libc/crt?
libc => newlib, part of the tool chain. crt might need some tweaking (I
use my own).
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by ●May 22, 20132013-05-22
Thanks for your reply!
I've not done anything yet. Except that now I have the kit that I mentioned in the OP - UEZGUI-1788-70WVT. I will probably start playing with it over weekend.
- launchpad.net/gcc-arm-embedded - that sounds good
- newlib, part of the tool chain - that sounds good too
- crt might need some tweaking - that does not sound too good. At least not right away. Since I have a particular micro (LPC1788) in mind, is there is a place that I can get an off-the-shelf library (and include files?) for it?
- I assume that Rowley, CodeRed, etc come with some sort of newlibs? Can they still be used if I do not use the corresponding toolchain itself?
- For anyone familiar with this particular kit, are there any simple examples for it? For example, I see that the board has a heartbeat LED. Any blinking LED tutorial for LPC1788 and launchpad.net/gcc-arm-embedded?
- If I'm successful with LED blinking, my next big step would be a USART communication with the PC. I see the board has a couple expansion connectors. Anyone know knows how I can plug into that, specifically, TX and RX lines?
Eugene
I've not done anything yet. Except that now I have the kit that I mentioned in the OP - UEZGUI-1788-70WVT. I will probably start playing with it over weekend.
- launchpad.net/gcc-arm-embedded - that sounds good
- newlib, part of the tool chain - that sounds good too
- crt might need some tweaking - that does not sound too good. At least not right away. Since I have a particular micro (LPC1788) in mind, is there is a place that I can get an off-the-shelf library (and include files?) for it?
- I assume that Rowley, CodeRed, etc come with some sort of newlibs? Can they still be used if I do not use the corresponding toolchain itself?
- For anyone familiar with this particular kit, are there any simple examples for it? For example, I see that the board has a heartbeat LED. Any blinking LED tutorial for LPC1788 and launchpad.net/gcc-arm-embedded?
- If I'm successful with LED blinking, my next big step would be a USART communication with the PC. I see the board has a couple expansion connectors. Anyone know knows how I can plug into that, specifically, TX and RX lines?
Eugene
Reply by ●May 22, 20132013-05-22
> - I assume that Rowley, CodeRed, etc come with some
sort of newlibs? Can
> they still be used if I do not use the corresponding toolchain itself?
CrossWorks does not come with newlib; we implemented our own library which
is licensed.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> they still be used if I do not use the corresponding toolchain itself?
CrossWorks does not come with newlib; we implemented our own library which
is licensed.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●May 23, 20132013-05-23
Why make life hard for yourself? Given the questions you are asking, it does not
sound like you want to be messing with creating your own toolkit
If you use one of the 'commercial' tools they come with examples that work, out-of-the box. If you use LPCXpresso, it is free to 128k of code. If you use Keil or IAR, they a free up to 32k (? - I think).
Surely your job is creating products, not creating tools - leave that to the experts!
--- In l..., "ezharkov" wrote:
>
> Thanks for your reply!
>
> I've not done anything yet. Except that now I have the kit that I mentioned in the OP - UEZGUI-1788-70WVT. I will probably start playing with it over weekend.
>
> - launchpad.net/gcc-arm-embedded - that sounds good
> - newlib, part of the tool chain - that sounds good too
> - crt might need some tweaking - that does not sound too good. At least not right away. Since I have a particular micro (LPC1788) in mind, is there is a place that I can get an off-the-shelf library (and include files?) for it?
> - I assume that Rowley, CodeRed, etc come with some sort of newlibs? Can they still be used if I do not use the corresponding toolchain itself?
>
> - For anyone familiar with this particular kit, are there any simple examples for it? For example, I see that the board has a heartbeat LED. Any blinking LED tutorial for LPC1788 and launchpad.net/gcc-arm-embedded?
>
> - If I'm successful with LED blinking, my next big step would be a USART communication with the PC. I see the board has a couple expansion connectors. Anyone know knows how I can plug into that, specifically, TX and RX lines?
>
> Eugene
>
If you use one of the 'commercial' tools they come with examples that work, out-of-the box. If you use LPCXpresso, it is free to 128k of code. If you use Keil or IAR, they a free up to 32k (? - I think).
Surely your job is creating products, not creating tools - leave that to the experts!
--- In l..., "ezharkov" wrote:
>
> Thanks for your reply!
>
> I've not done anything yet. Except that now I have the kit that I mentioned in the OP - UEZGUI-1788-70WVT. I will probably start playing with it over weekend.
>
> - launchpad.net/gcc-arm-embedded - that sounds good
> - newlib, part of the tool chain - that sounds good too
> - crt might need some tweaking - that does not sound too good. At least not right away. Since I have a particular micro (LPC1788) in mind, is there is a place that I can get an off-the-shelf library (and include files?) for it?
> - I assume that Rowley, CodeRed, etc come with some sort of newlibs? Can they still be used if I do not use the corresponding toolchain itself?
>
> - For anyone familiar with this particular kit, are there any simple examples for it? For example, I see that the board has a heartbeat LED. Any blinking LED tutorial for LPC1788 and launchpad.net/gcc-arm-embedded?
>
> - If I'm successful with LED blinking, my next big step would be a USART communication with the PC. I see the board has a couple expansion connectors. Anyone know knows how I can plug into that, specifically, TX and RX lines?
>
> Eugene
>
Reply by ●May 23, 20132013-05-23
--- In l..., "thenewfallguy" wrote:
...
> Surely your job is creating products, not creating tools - leave that to the experts!
Several reasons. I like GCC. I don't like been stuck with node locked licenses. I want to be able to use exactly the same version of the toolchain 5 or 10 years down the road (I learnt that the node locked licensing tend not to work when you move to next version of the operating system).
In short, this just makes me feel better.
...
> Surely your job is creating products, not creating tools - leave that to the experts!
Several reasons. I like GCC. I don't like been stuck with node locked licenses. I want to be able to use exactly the same version of the toolchain 5 or 10 years down the road (I learnt that the node locked licensing tend not to work when you move to next version of the operating system).
In short, this just makes me feel better.
Reply by ●May 23, 20132013-05-23
--- In l..., "ezharkov" wrote:
>
> --- In l..., "thenewfallguy" wrote:
> ...
> > Surely your job is creating products, not creating tools - leave that to the experts!
>
> Several reasons. I like GCC. I don't like been stuck with node locked licenses. I want to be able to use exactly the same version of the toolchain 5 or 10 years down the road (I learnt that the node locked licensing tend not to work when you move to next version of the operating system).
>
> In short, this just makes me feel better.
>
You might be surprised to find out how many commercial toolchains are using GCC. The discussion earlier had to do with newlib and that is owned by RedHat. Yes, it's free but it's intended for PCs so it might be a little bulky for an embedded system. Memory allocation/disposal is a particular issue for small memory systems and newlib uses malloc() for things like printf(). Many other libraries don't need malloc(). It turns out that the embedded programmer frequently has to implement sbrk() to allocate dynamic memory. These are called syscall stubs:
http://www.openhardware.net/Embedded_ARM/NewLib_Stubs/
To see how it is done, go to www.jcwren.com/arm and look at his code.
The easy way to get into GCC if you don't want a commercial package is to install YAGARTO. Everything you need is included. The IDE is Eclipse and the compiler toolchain is GCC. Newlib is included but it is easy to work around it.
Write your own string and conversion functions by copying the code from "The C Programming Language" and finding a copy of rprintf.c on the Internet. This way you won't be dependent on dynamic memory allocation.
RIchard
>
> --- In l..., "thenewfallguy" wrote:
> ...
> > Surely your job is creating products, not creating tools - leave that to the experts!
>
> Several reasons. I like GCC. I don't like been stuck with node locked licenses. I want to be able to use exactly the same version of the toolchain 5 or 10 years down the road (I learnt that the node locked licensing tend not to work when you move to next version of the operating system).
>
> In short, this just makes me feel better.
>
You might be surprised to find out how many commercial toolchains are using GCC. The discussion earlier had to do with newlib and that is owned by RedHat. Yes, it's free but it's intended for PCs so it might be a little bulky for an embedded system. Memory allocation/disposal is a particular issue for small memory systems and newlib uses malloc() for things like printf(). Many other libraries don't need malloc(). It turns out that the embedded programmer frequently has to implement sbrk() to allocate dynamic memory. These are called syscall stubs:
http://www.openhardware.net/Embedded_ARM/NewLib_Stubs/
To see how it is done, go to www.jcwren.com/arm and look at his code.
The easy way to get into GCC if you don't want a commercial package is to install YAGARTO. Everything you need is included. The IDE is Eclipse and the compiler toolchain is GCC. Newlib is included but it is easy to work around it.
Write your own string and conversion functions by copying the code from "The C Programming Language" and finding a copy of rprintf.c on the Internet. This way you won't be dependent on dynamic memory allocation.
RIchard
Reply by ●May 23, 20132013-05-23
I will look at YAGARTO. Thanks!
Regarding the library. I should have been more clear. I don't worry about the C standard library - I don't think I really need anything from it. At least not at the beginning. And if need something, I'm pretty sure I can find my way around. My concerns at this point are more about CRT startup, specific for a particular chip (stack pointer initialization, .bss and .data initialization, etc.) I.e., stuff that happens before main(). For example, will I be able to run out-of-the-box YAGARTO on LPC1788, to the point where the program enters main()?
Many toolchains are using GCC - yes, I see that. I'm really very allergic to IDEs. Just cannot stand all those windows with gazillion buttons. Therefore, when I see an IDE on top of GCC toolchain, for me it is rather a minus than a plus. I would probably rather pay someone to strip all the IDE part and just give me the command line mode.
Eugene
Regarding the library. I should have been more clear. I don't worry about the C standard library - I don't think I really need anything from it. At least not at the beginning. And if need something, I'm pretty sure I can find my way around. My concerns at this point are more about CRT startup, specific for a particular chip (stack pointer initialization, .bss and .data initialization, etc.) I.e., stuff that happens before main(). For example, will I be able to run out-of-the-box YAGARTO on LPC1788, to the point where the program enters main()?
Many toolchains are using GCC - yes, I see that. I'm really very allergic to IDEs. Just cannot stand all those windows with gazillion buttons. Therefore, when I see an IDE on top of GCC toolchain, for me it is rather a minus than a plus. I would probably rather pay someone to strip all the IDE part and just give me the command line mode.
Eugene
Reply by ●May 24, 20132013-05-24
--- In l..., "ezharkov" wrote:
>
> I will look at YAGARTO. Thanks!
>
> Regarding the library. I should have been more clear. I don't worry about the C standard library - I don't think I really need anything from it. At least not at the beginning. And if need something, I'm pretty sure I can find my way around. My concerns at this point are more about CRT startup, specific for a particular chip (stack pointer initialization, .bss and .data initialization, etc.) I.e., stuff that happens before main(). For example, will I be able to run out-of-the-box YAGARTO on LPC1788, to the point where the program enters main()?
>
> Many toolchains are using GCC - yes, I see that. I'm really very allergic to IDEs. Just cannot stand all those windows with gazillion buttons. Therefore, when I see an IDE on top of GCC toolchain, for me it is rather a minus than a plus. I would probably rather pay someone to strip all the IDE part and just give me the command line mode.
>
> Eugene
>
There is certainly no reason to use the Eclipse IDE if you don't want to. You can always run GCC from the command line. I did that for a while when I was using Linux. I used gedit as the editor and ran everything from the command line.
Bottom line, I prefer an integrated environment. One button to make the code and another to download it to the processor. I don't use gdb and at the time I wasn't using JTAG.
Today I use Rowley Crossworks with the Crossconnect JTAG setup. It works really well. There is an inexpensive personal license available.
The Keil uVision (free version) is a very classy setup as well.
And no, you can't run YAGARTO on the target processor. First, it is a Windows application (actually a Java program) and, in general, these small processors don't run Linux. Even when they do, the system code is generally cross-compiled. I suppose the RaspberryPi could build its own code but I don't think it is done that way.
You should be able to find a generic CRT.s for the family of chips. There will be unresolved symbols which are defined by the linker map file. The code basically sets up the stacks, initializes .data and clears .bss. The size and location of these segments is provided by the linker. Usually, when a change is made to a different mode, interrupts in that mode are disabled. There are startup files out there than enter main() with interrupts disabled. I turn them on in CRT.s before I call main(). And, yes, main() should probably be called and if the function returns, let the chip hang in a loop. Main() should never return and a branch to main() could be a problem if it did return.
Richard
>
> I will look at YAGARTO. Thanks!
>
> Regarding the library. I should have been more clear. I don't worry about the C standard library - I don't think I really need anything from it. At least not at the beginning. And if need something, I'm pretty sure I can find my way around. My concerns at this point are more about CRT startup, specific for a particular chip (stack pointer initialization, .bss and .data initialization, etc.) I.e., stuff that happens before main(). For example, will I be able to run out-of-the-box YAGARTO on LPC1788, to the point where the program enters main()?
>
> Many toolchains are using GCC - yes, I see that. I'm really very allergic to IDEs. Just cannot stand all those windows with gazillion buttons. Therefore, when I see an IDE on top of GCC toolchain, for me it is rather a minus than a plus. I would probably rather pay someone to strip all the IDE part and just give me the command line mode.
>
> Eugene
>
There is certainly no reason to use the Eclipse IDE if you don't want to. You can always run GCC from the command line. I did that for a while when I was using Linux. I used gedit as the editor and ran everything from the command line.
Bottom line, I prefer an integrated environment. One button to make the code and another to download it to the processor. I don't use gdb and at the time I wasn't using JTAG.
Today I use Rowley Crossworks with the Crossconnect JTAG setup. It works really well. There is an inexpensive personal license available.
The Keil uVision (free version) is a very classy setup as well.
And no, you can't run YAGARTO on the target processor. First, it is a Windows application (actually a Java program) and, in general, these small processors don't run Linux. Even when they do, the system code is generally cross-compiled. I suppose the RaspberryPi could build its own code but I don't think it is done that way.
You should be able to find a generic CRT.s for the family of chips. There will be unresolved symbols which are defined by the linker map file. The code basically sets up the stacks, initializes .data and clears .bss. The size and location of these segments is provided by the linker. Usually, when a change is made to a different mode, interrupts in that mode are disabled. There are startup files out there than enter main() with interrupts disabled. I turn them on in CRT.s before I call main(). And, yes, main() should probably be called and if the function returns, let the chip hang in a loop. Main() should never return and a branch to main() could be a problem if it did return.
Richard
Reply by ●May 26, 20132013-05-26
OK, it blinks.
Thanks everyone for help getting started!
Eugene
(I ended up using Embedded Artist's kit instead of FDI, for now. And using LPCXpresso's includes/libraries/scripts. I learnt that code_red is now owned by NXP. That made me feel a little better about using all the code_red stuff. I do have a few question about LPCXpresso, however ... I will probably start a new thread.)
Thanks everyone for help getting started!
Eugene
(I ended up using Embedded Artist's kit instead of FDI, for now. And using LPCXpresso's includes/libraries/scripts. I learnt that code_red is now owned by NXP. That made me feel a little better about using all the code_red stuff. I do have a few question about LPCXpresso, however ... I will probably start a new thread.)
