On Thursday 04 January 2007 07:53, David Anderson wrote: > On 1/3/07, Charles Manning <[EMAIL PROTECTED]> wrote: > > If you've been around ARM-based micros before, then getting going on the > > low-levels is not too difficult. The hardest part was getting the i2c > > link to the AVR going properly because the documentation did not match > > what was happening, compunded by the fact that the SAM7 I2C peripheral is > > buggy. > > I see. I've had minimal (cousework, using windows dev tools) > experience with arm architectures, but my objective now is to get a > full toolchain for open platforms. > > > As Lawrie has already stated, we can run code in three ways, one of which > > supports gdb-level debugging through jtag. > > Speaking of that, what jtag probe do you use for debugging, and does > it work in linux? I'm looking to buy one (because loading code and > watching the nxt do "nothing" is getting old very quickly), but I'd > rather not have to fight with jtag-gdb for a few weeks before I can > start debugging.
I have been using gnuarm.org based stuff for ages and most things are pretty good. I've used this in a few products over the last 3-4 years. I could not get gcc 4.1.1 working so we're currently using 4.0.2. If you want to get steeped in ARM embedded development then I suggest joining the gnuarm email group. gdb (or other debuuger) is normally used via gdbremote on embedded targets and works well with Linux. The gdbremote protocol is also used by many other debuggers. The jtag tools typically fall into two groups: 1) Host-based gdbserver runs on the host and converts gdb remote transactions into jtag requests. Most well known is openocd which supports a wide range of jtaggers from thiungs you can make yourself for $10 (wiggler clone) up to many-hundred-dollar devices. I suggest you start by looking at openocd. 2) Self-hosting gdb remote servers. These are typically the most expensive devices (eg. bd12000 at approx $2400). I happen to be using a bdi2000 right now, but for smaller devices (like used here), download speed etc is less critical and a cheaper option is more than adequate. > > > That's the model being used here. > > Just replace main with the code you want and you're off to the races. > > > > Since I've used dead code stripping, you can even leave the VM code in > > the build (but don't call it :-)) and it will just get stripped from the > > final image. > > I saw that. The code you have looks very nice. I had started doing > things slightly differently: I have an asm/C bootstrapper that takes > care of stack setup, as well as flash, clock and AIC initialization, > before copying a payload into ram, remapping and starting execution. > The bootstrapper is designed to be as generic as possible, so that you > can bootstrap into anything and start at kernel_main() with interrupts > disabled and the basics configured. > > I think I'm still going to go on with my own kernel code (if only to > learn about writing the stuff and working the toolchain), but I will > certainly take inspiration from the lejos kernel, and try to stay > compatible with it where possible. > > Have you considered moving the platform code into a project separate > from the lejos VM? I have considered that, but this is effort and requirtes some motivation (in other words if I have a few hours I'd rather put it into more Lejos features). > > > We got a substantial distance down the road before the Lego fw was > > available. Thus far I've only used it to confirm a few things I've seen > > on a scope etc. > > Right. I looked mostly at the AVR code, to see how the copyright > string was being handled on the receiving end. > > - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Lejos-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lejos-discussion
