Winding down, switching gears
Feb 7, 2018

Let me get right to the point: the scheduled daily weekly posts on this JeeLabs weblog are coming to an end. I’m going to move away-and-onwards from the “blogosphere”.

There are several reasons for this decision. A central one is my desire to spend (even) more time reading and tinkering, but also less time talking and writing. The web has become an amazing (infinite!) knowledge resource. Call me crazy, but I still want to learn more - just for the sake of learning!

My plan is to wander off and try to get into discovery- and tinkering-mode when I can, without considering what-to-write-about.

This weblog was started in 2008, and all of it is still online and browsable through the Archive link at the top of the page. Being 100% static, it’s trivial to keep this website up, so please continue to look around and enjoy all the content from the past decade.

Let me end with my all-time favourite quote from the late Steve Jobs:

Stay hungry, stay foolish.

Which I interpret as: hungry for knowledge and foolish enough to remain true to myself.

Cheers,
-jcw


P.S.

To rephrase a bit: you won’t hear from me again on a regular basis, just an occasional shriek when I come across delightful stuff.

Such as this circuit made from six simple components, behaving in a “chaotic” way:

Isn’t that amazing? It’s from decades ago … I’ve done some research on this. No, it’s not a weblog post. No more of that. Onwards!

For comments, visit the forum.

Data structures for JET, cont'd
Dec 27, 2017

I made some good progress on the design of an early prototype for last week’s JET data structure design. So far, it’s all working out well (I’m coding this in C), with some useful refinements:

  • the gadget + wiring configuration can be serialised to a binary format, this can be used as data exchange format when sending a setup to a µC

  • there is now also an extension to the GC’d memory manager, which allows storing structures compactly in ROM

What this all means, is that I think I now have an early-but-working starting point for implementing the Pd-like JET engine, which can fit in small µCs and support a flexible message-based dataflow design.

I realise that all these deliberations and notes about “JET” will mean very little to most people. It’s all based on a vague idea I’ve been toying with for several years now.

Here’s a little example to show how the different ideas will hopefully come together later on. This is a “circuit” to control the brightness of an LED via a rotary encoder:

A few notes to clarify this diagram:

  • each block and circle is a “gadget” in JET terms and the wires carry msgs, usually flowing from top to bottom
  • the rotary encoder is tied to 2 GPIO pins, and would use a “driver gadget”
  • likewise, the LED is tied to a GPIO output pin which can be set and cleared by sending the proper msg
  • metro 25” is a “metronome” gadget which ticks every 25 ms
  • delay 1” sends msgs coming in on the left inlet to its outlet, after a delay
  • we can change the delay by sending a new (int) value to the right inlet
  • within 1 24” limits incoming ints to the range 1..24 and passes them on
  • onload” sends a message on startup, to start the metronome ticking
  • everything runs using the dataflow mechanism, parallelism is built-in

At this stage all of this is imaginary, i.e. pure vapourware. And I don’t even have any practical experience with Pure Data, so many, many details are bound to change.

I also want to implement a visual diagram editor in the browser, so that the above is literally the way circuits are constructed. With a set of “gadgets” to allow building interesting stuff. But that’s for later…

The reason this keeps me hooked, is that it could all excel in terms of modularity and scalability, IMO. The “gadgets” are self-contained modules, and the messages flowing between them clearly define the interfaces. Anyone can add more gadgets, and they can expose all the intricacies of the underlying hardware.

These circuits are self-documenting and trivial to extend. Also, since everything is message- (i.e. event-) based, intercepting them will allow convenient debugging.

The Node-RED project has numerous similarities, but its engine is JavaScript and intended to run on much heftier systems than what I’m aiming for. Then again, I wouldn’t be surprised if JET could be made usable in combination with Node-RED.

Is JET ambitious? Heck, yes - I’m not sure it’s even possible to get it all working across remote links and pared down enough to fit in a small µC. But it’s a worthy goal, IMO!


And with that, dear reader, we’ve reached the end of 2017. I’m going to make some changes to my posting frequency - starting right now - by announcing a break for the coming month. I need some time off (for a number of reasons, not all related to me or this weblog) and want to be able to work on things which take a bit longer to complete.

Allow me to wish you a peaceful, healthy, and fulfilling 2018, with lots of creative energy. I’ll post again in February, 2018!

For comments, visit the forum.

Data structures for JET
Dec 20, 2017

Another post about the JET project. This time around, I’m trying to come up with simple data structures to get the job done, i.e. supporting a PureData-like dataflow engine, able to fit in very small µC setups.

That means minimal redundancy, given the limited amount of RAM. One useful trick is to store int indices where possible, instead of 4-byte pointers to the various items.

Apart from processing dataflow messages, I also want the whole setup to persist across power cycles, i.e. the entire dataflow circuit has to be stored in flash or in EEPROM.

Here is a first tentative design. It may not make much sense to you right now, but I need these diagrams - as “notes-to-self” - even if some will change again later on.

The gadget is the central object. Each one has “inlets” which accept messages and “outlets” that can send out new ones:

These gadget objects (i.e. instances) have a fixed size, their array index is used as “id”.

The “type” field refers to the actual code for the gadget, which will be called as follows:

myHandler(int id, int inlet, Value msg);

The “state” points to a RAM area allocated for that gadget, “wiring” determines where to send each outgoing message, and “chunk id” refers to optional GC’d memory.

To save space, “state” is an array offset. The size of each area can be calculated from the next gadget’s state offset, since all areas are allocated in the same order as the gadgets:

The same trick is used for all the “wiring” entries, since each gadget can also have its own specific number of outlets:

In the example shown above, gadget #1 has 5 outlets, #2 has 1, and #3 has 3. Note that there will need to be a dummy last gadget to take care of the boundary conditions.

Each outlet points to a “netlist”, this is an ordered list of inlets to receive that outlet’s messages. If an outlet has nothing attached to it, its netlist will be null (see gadget 1, 3rd outlet). Multiple outlets can send messages to the same net (i.e. unlike direct electrical wiring, but like open-collector/diode logic).

When a netlist has only a single entry, that entry is stored in the outlets array itself.

All the above data structures, except states and chunks, can be ROM-based. Since they are just data, the idea is to store them in flash memory, ready for the JET engine to pick up and “execute” on power-up.

For now, I’m assuming there will be very little memory. Gadgets take up 8 bytes, each outlet is 2 bytes, and netlists also need 2 bytes per entry. The limits I’ve chosen allow at most 1000 gadgets, 250 gadget types, 4000 outlets, and 16000 netlist entries. These limits are sufficient for most of the low end STM32’s I’d like to run this on. A mere 100 gadgets should already be enough for a range of non-trivial circuits, I expect.

The way it’s meant to be used, is that there will be a fixed firmware image with the JET engine core and all supported gadget types (i.e. handlers) built-in, and that the “circuit” (i.e. application) is written into a separate area in flash or EEPROM.

Seen from another angle: the JET engine will take care of event handling and the call graph (defined as data, not code!), while the gadget handlers act as the components from which the application is constructed. All the information flow between gadgets takes place as (GC’d) messages, but the gadgets themselves can process and save their own state in whatever (efficient) way they like.

Note that this is just a very early design / thought experiment. There’s no code yet to verify that it’s feasible and makes sense…

For comments, visit the forum.

Weblog © Jean-Claude Wippler. Generated by Hugo.