Picobit embedded in Chibios
I was looking at the Small Scheme Stack a little more than a year ago. I couldn't find the source, so I contacted the authors asking them if it was available under an open source license. Marc Feeley got back to me, asked a few questions about the scheme I planned to use, and suggested Picobit.
At the time I abandoned that idea, and finally got around to looking at Picobit about a week ago This afternoon, I've managed to embed it in Chibios. It's already been ported to a specific ARM board, but I wanted to embed it in Chibios to avoid writing a lot of drivers. I've now got a little scheme program that flashes a led on and off on an STM32F4 Discovery board. You can see the fork of picobit here. It's a work in progress: my build in particular is a bit of a mess. Chibios wants your makefiles to follow a fairly rigid structure, and Picobit's makefiles are a little complicated: copying details about the memory map from the vm build across to the compiler.
I think the way the pre-existing ARM target is meant to work is that you build Picobit on the device once. The Picobit compiler generates intel hex files, which are instructions about what to write into what bits of memory. I.e. it's sparse. You just choose a number beyond where Picobit is flashed, which is the pre-agreed program start. Then you flash the output of the Picobit compiler onto the device.
This doesn't work so well if you want to embed Picobit: Chibios varies in size depending what you include, and you might write some parts of your application in C, so there's no easy way to pick a value. This is what linkers are for! What I've done instead is convert the hex output of the compiler into an object, using objcopy and ld from the cross compiler, and use the start symbol that ld adds to reference the rom. This means I'm using a set up more or less like the host architecture version.
My larger goal is to create a simple boot loader for Picobit that would let me replace the scheme program remotely. That's a lot simpler than a real boot loader, and should be almost as versatile: the set of Chibios drivers needed is unlikely to change for a given bit of hardware.
For now, it would just be nice to be able to add Picobit to any old Chibios project by including a makefile from Picobit.
But even before that, I need to have a go at writing some non trivial programs to see if Picobit is useful. I'm thinking I'll try and interface to a real time clock via I2C, and see if I can build a scheme calendar library.
There are a few other things worth being aware of. Picobit has a fixed memory partitioning scheme, which adds up to about 64K. I've 192K on the board I'm using, so I can just have an array that big. The existing demo runs on a board with 8K of RAM. I could be wrong but I think it only works because it never invokes the GC or uses any vectors. Anyway, for now that limits me to exactly one board. Picobit can probably only run in a single Chibios thread for now.
Finally, I have no idea why CODE_START is 0x8000, or why in the host architecture, the ROM_BYTES is limited to 8192.
At the time I abandoned that idea, and finally got around to looking at Picobit about a week ago This afternoon, I've managed to embed it in Chibios. It's already been ported to a specific ARM board, but I wanted to embed it in Chibios to avoid writing a lot of drivers. I've now got a little scheme program that flashes a led on and off on an STM32F4 Discovery board. You can see the fork of picobit here. It's a work in progress: my build in particular is a bit of a mess. Chibios wants your makefiles to follow a fairly rigid structure, and Picobit's makefiles are a little complicated: copying details about the memory map from the vm build across to the compiler.
I think the way the pre-existing ARM target is meant to work is that you build Picobit on the device once. The Picobit compiler generates intel hex files, which are instructions about what to write into what bits of memory. I.e. it's sparse. You just choose a number beyond where Picobit is flashed, which is the pre-agreed program start. Then you flash the output of the Picobit compiler onto the device.
This doesn't work so well if you want to embed Picobit: Chibios varies in size depending what you include, and you might write some parts of your application in C, so there's no easy way to pick a value. This is what linkers are for! What I've done instead is convert the hex output of the compiler into an object, using objcopy and ld from the cross compiler, and use the start symbol that ld adds to reference the rom. This means I'm using a set up more or less like the host architecture version.
My larger goal is to create a simple boot loader for Picobit that would let me replace the scheme program remotely. That's a lot simpler than a real boot loader, and should be almost as versatile: the set of Chibios drivers needed is unlikely to change for a given bit of hardware.
For now, it would just be nice to be able to add Picobit to any old Chibios project by including a makefile from Picobit.
But even before that, I need to have a go at writing some non trivial programs to see if Picobit is useful. I'm thinking I'll try and interface to a real time clock via I2C, and see if I can build a scheme calendar library.
There are a few other things worth being aware of. Picobit has a fixed memory partitioning scheme, which adds up to about 64K. I've 192K on the board I'm using, so I can just have an array that big. The existing demo runs on a board with 8K of RAM. I could be wrong but I think it only works because it never invokes the GC or uses any vectors. Anyway, for now that limits me to exactly one board. Picobit can probably only run in a single Chibios thread for now.
Finally, I have no idea why CODE_START is 0x8000, or why in the host architecture, the ROM_BYTES is limited to 8192.
