You may enjoy [this journal/tutorial I have written. I am just moving away from Arduino so I am not an expert by any means. I was surprised at the nearly complete lack of tutorials for getting started with ARM on Linux, so I wrote one. I am using the AT91SAM7S256 header evaluation board that SFE sells.
The target audience is programmers who have simply outgrown Arduino but haven’t had experience with ARM before.](http://carrierwave.wordpress.com)
You’re quite welcome. This is an ongoing learning experience for me, so please feel free to suggest new topics. Coming up soon (next week or so…) is a GPS interfacing example.
Thank you. As far as I am concerned, I’d particularly appreciate some gentle introduction to JTAG/openOCD and stuff like that.
Besides, somewhere on the internet (really can’t remember where) I’ve read something about a kind of restriction on flashing ARM. While the flash memory certainly should endure 10000s of (re)write accesses, reportedly there are some corresponding lock/unlock bits that (again, reportedly) endure only ~100 (re)writes. Can you shed some light on this matter?
Excellent points, which demonstrate how little I know…
The cycling issue is true. The NVM, Lock bits, and Security bit are only rated for 100 cycles (see the errata for the chip). Though this seems to be somewhat of a low estimate, this is still a problem as SAMBA writes to them every time it recovers. Workarounds include loading to a different part of the memory (to not overwrite SAMBA), using SRAM, and JTAG. [Here’s a good explanation.
I had initially hoped to only use SAMBA, but I guess this issue forces me to get a programmer. Sigh… I suppose I will be doing a writeup on JTAG eventually anyways. If you need an introduction now, there are a lot of good tutorials linked from Olimex’s pages on their programmers. I think I’ll be getting the “Tiny” USB programmer.](http://www.at91.com/samphpbb/viewtopic.php?f=15&t=4745)
Maybe this alternative [bootloader can help getting rid of the SAM-BA related issues. The author states that the SAM-BA recovery procedure won’t be neccessary anymore.
Thanks for your explanations regarding the lock and security bits!](pcb-dev.com)
I have put up my experiences getting a basic (non-Eclipse) flashing environment working with JTAG and OpenOCD on Linux. I’m still figuring out how to trigger the appropriate scripts in Eclipse, but it is gradually coming together.
I tried that bootloader but it failed to flash correctly, and I gave up. Fixing it is out of my league right now.
New post, “Automatic Makefile generation for ARM in Eclipse” at the end of the journal. I am artificially reversing post dates because I like it as a journal, not a blog. It takes about 10 minutes to do the template Autogenerate project, from then on it is just a matter of copying it and excluding the unused resources for each new project.
Also, if I am just spamming up the forum, let me know and I’ll stop posting updates here.
Added new topics: 3 parts of JTAG/OpenOCD (Command line Flashing, Eclipse Flashing, and Eclipse Debugging).
Edited the autogenerate instructions - there were a few very stealthy bugs (linker object order matters?! wth). Also lots of path changes to make it so you can copy the template without changing anything in the properties. I’ll get around to uploading my step-by-step pictures eventually, but wordpress is irritating me at the moment and the text is there.
Now it is a full zero to debug tutorial. All this hassle really makes you appreciate Arduino… But I can finally just code now that the entire workflow is functional. I may make some more posts about getting FreeRTOS running, but I think this journal’s topic, setup, is complete. Let me know if you have any issues or I did something stupid along the way.
I just came across this thread and think a tutorial on getting things together to work with the AT91SAM is just great. The more there is out there on using this processor the better. More documentation means more users to share their experience. This tutorial and the one by James Lynch complement each other.
I’m looking at the AT91SAM because I want to have a multi-tasking OS to use and though I think it may be possible to port an RTOS like FreeRTOS to the Arduinio, I think it would be a much easier job on the ARM processor. I believe Linux and Windows CE have already been ported. I lean toward freeRTOS because it doesn’t have all the baggage of an OS like Linux. FreeRTOS was built to support multi-tasking and really nothing else as I understand it.
Back to the tutorial, I find that the part on JTAG and programmers to be particularly helpful. So, far I’ve been mostly confused when it comes to setting them up.
BTW, there really is not much that is particular to Linux in the tutorial.
Glad I found this. I am pondering the jump from AVR to ARM. It looks like a !@#$ton of work. I’m curious…how much longer or shorter would the process be if an ARM-newb (like me) went straight for CrossWorks and an Olimex ARM-USB-OCD? That’s my current plan, although I can’t execute said plan for at least a month.
carrierwave:
The target audience is programmers who have simply outgrown Arduino but haven’t had experience with ARM before.
I don't think it's a matter of outgrowing the Arduino platform. Rather, I think it's whether the Arduino is appropriate for a given application or not.
I have two LPC2148 ARM7 boards I bought sometime ago, but I have had problems getting a solid development system setup and working for them. The only workable option I have seen to date for myself is the CrossWorks for ARM development system from Rowley Associates, which just works and works excellently. I just haven’t had the funds to invest in a personal license.
I am using the Arduino in projects, and will continue to do so, but I also want to learn the ARM7 and the ARM9 Linux platforms for applications where I need more power. I am going to be using a couple of Arduinos and a BeagleBoard for one of my robots, for instance.
I will definitely look at your tutorial, but I am not fond of Eclipse at all. I’d like to see if WinARM can be integrated into the Code::Blocks IDE instead.
That’s a pretty odd position considering your username, heh… Though I certainly agree with using what is best for the job. As a side note, I am still struggling to get FreeRTOS working, and help from anyone more experienced with it would be greatly appreciated!
I wish someone would make an introductory tutorial with the FriendlyArm ARM9 linux 2.6 board that is all over ebay. $75 for a 3.5" touchscreen - how do they do it? Camera, full ports, and wifi too. It is cheaper than even many OpenWRT hacks. The BeagleBoard is more than twice the price with fewer ports, no screen, and a Cortex A8 (which is actually an ARM7).
carrierwave:
That’s a pretty odd position considering your username, heh… Though I certainly agree with using what is best for the job. As a side note, I am still struggling to get FreeRTOS working, and help from anyone more experienced with it would be greatly appreciated!
Well, I will be using a BeagleBoard on my next major robot, but Arduinos on my smaller swarm robots. :) I've sort of had FreeRTOS working on an LPC2148 Prototype Board, but it's been a LONG time since I tinkered with it due to not having a decent free (I hate Eclipse) IDE for ARM. I'm trying to figure out how to connect Code:Blocks with WinARM now.
carrierwave:
Excellent points, which demonstrate how little I know…
The cycling issue is true. The NVM, Lock bits, and Security bit are only rated for 100 cycles (see the errata for the chip). Though this seems to be somewhat of a low estimate, this is still a problem as SAMBA writes to them every time it recovers.
Presumably, this is unique to the Atmel, versus NXP and others?
I don’t know if the cycling issue is unique to Atmel (it is a hardware issue related to the way memory cells are programmed, so it may be shared), but the point is really moot since JTAG bypasses them. Using SAM-BA quickly becomes tiring once you find out how fast JTAG is, though I do appreciate its brick recovery capability.
I’ve re-flashed AVRs and ARM7s (NXP) a thousand or more times, I suspect. Not counting flash-breakpoints - where the sector is erased and re-written with trap instructions - then erased and re-written to remove breakpoints.