Skip to main content

Squawk on MINDSTORMS

8 replies [Last post]
rasped
Offline
Joined: 2008-01-31
Points: 0

I have made a toolchain that can compile the vmcore and toggle the light sensor from the arm_main method in os.c. Pls. see
https://nxtsquawk.dev.java.net/.

You can look in SQUAWKROOT\vmcore\src\rts\arm-elf-gcc-nxt to look at the Makefile. My environment is cygwin and the arm-elf-gcc toolchain from the WinArm project. You can also get a toolchain from http://www.gnuarm.com/. For now I made a copy (at svn repository https://nxtsquawk.dev.java.net/svn/nxtsquawk/trunk)of the Squawk code because I made several hacks to get it to compile. More info at http://forums.java.net/jive/message.jspa?messageID=258805#258805

Best, Rasmus

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jorgemc
Offline
Joined: 2008-02-20
Points: 0

Great work, Rasped!

Can you tell us the RAM and ROM footprint of your build? I am interested in a port for an ARM7TDMI wich has less memory than the NXT.

rasped
Offline
Joined: 2008-01-31
Points: 0

Here is some example output from the build process:
squawknxt.elf :
section size
.text 51532
.data 2284
.bss 2352
So ignoring the Java part, the C part let's you could get away with something like an AT91SAM7S64, but with a CLDC-like Java library the AT91SAM7S256 is already tight.

rasped
Offline
Joined: 2008-01-31
Points: 0

I have added/modified a little tool from the nxtgcc.sf.net project that is called binsert. It can insert a .suite file in the firmware after the vmcore is compiled to a binary image. Just to show the principle you can look in the Makefile and the nxtsquawk.bin file that I committed. You need a hex viewer and can see where the suite is inserted.
Best, Rasmus

eric_arseneau
Offline
Joined: 2004-07-15
Points: 0

Your going to have to be careful here, the Squawk VM exe has some direct pointers into the bootstrap suite that it needs to know about. With the model you and I discussed this weekend, it will be much easier and simpler for you to have the suite and the VM be generated and flashed onto the device.

Its something we've had to learn to deal with here a lot :) Any change to the bootstrap suite normally requires a new VM to be built.

eric_arseneau
Offline
Joined: 2004-07-15
Points: 0

Cool stuff !!! I am happy you are able to make some progress with so little documentation.

One question I have for you, we have a tool chain that we build in order to provide an executable for the Sun SPOT. Should this same tool chain be able to support your efforts as well ? I would be interested in finding out, as then we could use a single tool chain to support both efforts ? Doing this would reduce duplication of efforts, but also help with being able to pass the Java tests.

I am unsure about how to confirm whether the Sun SPOT tool chain would work for you as well, other than providing the binaries. Let me see if I can get some info on my side and get back to you. If you have any ideas, dont hesitate to share them :)

rasped
Offline
Joined: 2008-01-31
Points: 0

Well, thanks... I think a generic toolchain for one example board would be helpful for us in the community. Or even better; if your team can make three versions of Squawk: (a) A CLDC 1.1, (b) CLDC 1.0 (no float), and (c) a really minimal JVM with no GC with minimal memory footprint (JavaCard like HW), then I think it could benefit many. I did a number of hacks to get it to compile something that resembled option (b) :-). One example is the forum post regarding the 8051 MCU, which may not host a full Squawk. I suspect that people are more motivated to start from your generic toolchain and some fitting Squawk version (than say from a project specific one like the one for the nxtsquawk project). The ant based toolchains (as in the spot-core-libraries project) look flexible and extensible with multiple events that one can hook into.

Another thing; I am not sure that the all the constants in ChannelConstants.java belong in the generic Squawk (or at least not the SPOT specific SPI and AVR stuff), perhaps there can be a "SPOT" build flag in build.properties that include these when building for SPOT. This is not a critique, but just ideas for more work for you...when time permits.
Documentation: For now it would just be fine if someone extended an existing presentation with 5-10 slides with the most crucial hints, like where the things are placed in flash and what the most typical build.flags are for an embedded build. But that said, I find the Builder well documented from the command line with the -h option as you pointed out in an earlier post.
Best, Rasmus

eric_arseneau
Offline
Joined: 2004-07-15
Points: 0

Just took a look at the source tree on your side today. Can we find a way to work such that you dont have to copy the whole tree. I took a shortcut with the phoneme stuff, but working on removing that very shortly. It is a pain to have to download from multiple source repositories, but it does make it easier to see differences if all you have is your stuff in your project.

As for CLDC 1.0, you can use FLOATS=false in build.properties and that should give you what you want. What did you have to hack ?

What can we do to make it easier for you to have a delta rather than an entire tree copy ?

I am working on doing something similar now for the phoneME stuff, so maybe I will work on figuring out how to make this mechanism work for ports such as yours. Any ideas on how we should do this would be appreciated :)

rasped
Offline
Joined: 2008-01-31
Points: 0

Nice that you are working on the phoneme stuff. It looked deceiving easy with [i]CLDC1.1=false[/i] and [i]FLOATS=false[/i], but I got some problems when trying to build for the arm. But I will try again:-)
You are right about multiple source trees. It was just convenient for now...
I think it would be of general interest to see a toolchain for the Squawk that runs on Spot when/if time permits.
Best, Rasmus