I’ve always wanted to try ARM but i want to get a basic setup running and try it out to see if i am going to like it before i commit 50+ dollars to it. I am currently trying to design a board for the lpc2138 on the cheap; I am planning on just buying the chip itself and making a board for it in eagle.
I have a question that i cant seem to find the answer to anywhere in the datasheet/online:
Can this micro be programmed exclusively over a serial connection via (for example) an ft232 USB to UART IC, or do i need to implement JTAG on my board for the bulk of the programming? If serial is possible can it be done out-of-the-box, or do i need a bootloader for it?
I would like to keep this thing as small as i can get it (a JTAG header would make it bigger than i’d like, and would make it more expensive to get made), as i’m going for a layout with minimal components and all GPIOs broken out to a stamp type configuration that can be inserted into a breadboard; kinda like the mbed only not dependent on the web based toolchain, and not 80 dollars.
danvm:
I have a question that i cant seem to find the answer to anywhere in the datasheet/online:
Can this micro be programmed exclusively over a serial connection via (for example) an ft232 USB to UART IC, or do i need to implement JTAG on my board for the bulk of the programming? If serial is possible can it be done out-of-the-box, or do i need a bootloader for it?
Yes. We do all of our programming and development using FlashMagic via UART0 and the on-board bootloader.
Download a copy of the LPC213x User Manual (UM10120) - it has far more information in it than the Data Sheet.
stevech:
Breakpoint debugging in an IDE using JTAG is far more productive than “crash and flash” debugging on the serial port.
This assertion depends on a number of unstated assumptions.
For those programming in a language like C or assembler with minimal built-in protection against programming blunders, or those using unreliable / buggy development tools cobbled together from a variety of sources I would agree that it likely to be true.
However, not all of us do that - by far the most productive / least expensive software development results when using a system that identifies errors at the earliest possible opportunity - at runtime is much too late. Alternative modern programming languages like Oberon-07 are carefully designed to help clearly identify the maximum number of programming errors at the earliest possible opportunity i.e. compile / link time.
Most remaining problems that cannot be statically detected (e.g. index arrays out of bounds, overflow etc.) are automatically trapped and their source identified at runtime - not left to fester and result in spurious and obscure secondary side-effects some time later. Any remaining problems are likely to be hardware or real-time dependent so require an oscilloscope or logic analyser to track down anyway!
We were actually able to implement the Armaide runtime system itself (in Oberon-07) for the NXP MCUs without assistance from a JTAG debugger - even in the initial stages when the Oberon-07 compiler code generator was still being developed; it doesn’t get much harder than that!
C’mon, Chris, based on your past postings around the 'net, we’d expect a less biased (for your product) discussion here.
No matter the programming language, embedded firmware debugging is very much I/O device/timing, etc. dependent. Big-computer programming errors like array out of bounds are low priority as compared other embedded-related debugging, where the problem is more often a misunderstanding of the I/O device, registers, mistakes in the wiring, and so on. Not high level language issues.
Even the most powerfull IDE, compiler, tools, etc, could not resolve all bugs when you write bad or wrong code to implement complex algorythm. Code could be absolutely correct regarding types cast, sementics, etc…but do the wrong things. And whithout a real debugger, it is difficult du debug such code.
Polux rsv:
Even the most powerfull IDE, compiler, tools, etc, could not resolve all bugs when you write bad or wrong code to implement complex algorythm.
Correct - even the best designed languages and tools are not going to help a sloppy or incompetent *hacker*. However a good *programmer* spends more care and time at the design and code stage (including code walkthroughs). In my experience that is the **most productive** way to solve these problems - not depending on debuggers to find needles in haystacks (when much of the time you do not know which haystack to look in!). Don't get me wrong - I do use debuggers - but only as a last resort.
Given the choice between:
a) a fragile development system with minimal programmer safety but an excellent debugger, and
b) a reliable development system with good blunder detection and minimal debugging facilities
I’d choose the latter any day - but then, as Steve rightly points out - I am biased
