Picobit with serial console

I added some I2C primitives, and to do this I wrote a few helpers to access vectors from Chibios. Then I though: I need a simple way to test this, so I added support for Serial over USB. This didn't work, and when the micro-controller crashed. it took the Linux USB driver with it, and I had to reboot. That precludes using the debugger - since it connects via USB too.

So now I have a double defence: The micro-controller dev board is connected to the raspberry pi via USB, and also via serial: the pi has a 3.3V serial port which is perfect for this. You can read some instructions here. You don't have to reboot though: just do

$ sudo init q
instead to get init to reload it's configuration.

If I have to reboot the pi to get USB access back that will be OK, but using the serial port makes that unlikely anyway.

I still haven't used the debugger. My problem turned out to be a cut and paste error: Picobit passes arguments to primitives in 4 global variables. This makes sense: these variables can easily be included in the roots for the GC, so GC is safe inside primitives. It is, however, a great fault injection vector.

Through all of this, I keep getting tripped over by the broken Makefile: I'll make a change to a primitive, or change a setting, and either the relevant files won't get built early enough for the compiler to use them, or Racket will have compiled the old one and ignore the changes anyway. I've replaced gen.config.rkt with a command line option: --code-start to set the code start address. I'd really like a module system, so I can do away with the gen.library.scm and gen.primitives.rkt.

Tony Garnock Jones, an ex college of mine at LShift is now at Northeastern university. It sounds like he shares an office with one of the Picobit authors too. I know of p-syntax from SISC, but Tony suggested I use Racket #lang, which looks very interesting indeed. I might turn the Picobit compiler into a Racket back end.

I've found Source-to-Source compilation in Racket, and the example Magnolisp matches my use case in that I want Racket to implement modules for me.

I don't know if I should dive into this now or try writing some scheme to talk to the real time clock. I want parametrized modules, so for example I can create an instance of the TinyRTC module with the second I2C controller as a parameter, and then create and instance of SRFI-19 using my TinyRTC instance to get actual dates.

Popular posts from this blog

3D Printer ramblings

 I have a Prusa i3 mk2.5 in storage. I used to use it in my shed I used not to worry about it's harmful emissions: I just didn't share the space with it. I had, however, added an enclosure, and was planning to add a HEPA filter too it. Once it's in an enclosure, it's massive. Even if I had added the filter, there's no where to put it. I'd like a small printer that has an enclosure or is easy to enclose. I figure I could get by with 150x150x150 build area: I was rarely patient enough to wait for my i3 to print bigger models. 200x200x200 would probably actually replace my current printer, so that would be a bonus. Not many printers have HEPA filters, which is really a shame. It seems just to be the result of a misconception about HEPA filters, and about filtration in general. Read this . E.g. I was looking at a used Lulzbot mini, and there are ready made enclosure s for it, however . In this particular case, it's no big deal: opportunities to buy a Lulzbot min
Read more

Balance Bot V2

Image
My current balance bot sort of works, but it's surprising it does: it's centre of gravity is actually only about 60mm above the motor axis. The whole thing ways 320g. The 6 AAA batteries only weigh 70g, so despite being right at the top, the don't affect the centre of gravity much. 6 AA batteries would weigh about 180g. That would add a 34% to the overall weight, and move the centre of gravity much higher. Seems like a dramatic increase in weight: it would be nice to be a bit more incremental. More AAA batteries isn't really worth considering: they only weight 12g, vs 30g for an AA. 4 AA would deliver much less power/torque, so that's no good. There's no middle ground, in other words. I'm also going to make the whole thing a bit taller: I need more space to add more sensors in any case. Last time I made the frame, I needed an elaborate jig to get it square and it actually didn't work that well. This time, I decided to use some short bits of a
Read more

Robot arm

Image
I 3d printed this robot arm I original found on Thingiverse, but the Instructable is recommended. There's a MK2, and also a delta style arm, both of which look like good alternatives, but this will do for now. Here's a video of it moving: I've attached it to an STM32F4 Nucleo board, via a prototype shield: In the video, I'm sending commands from a python script that runs on my desktop, communicating via USB serial. I've written an implementation of canonical s-expressions in c++ that doesn't require memory allocation, as well as a python version to talk to it. It's the main reason I haven't posted for so long, and of course overkill for just controlling some servos, but should prove more generally useful. Here's the code . It uses platformio for the build, and mbed rtos.
Read more