So, I decided to create what I started to call a "physical block-based programming language" (I need a better name - any ideas?) and had tentatively selected the Arduino as the core of the project. A big factor in this decision was that I already had a handful of Arduinos (Nanos and Pro Minis) and they are relatively inexpensive - around $2USD for Pro Mini clones. My budget as a student could stretch that far at least. ;^)

I had purchased some tiny breadboards in the past and I thought they might be useful for this project. The boards have 170 tie points (17 rows x 10 holes (2 lots of five)) and a Pro Mini fits nicely leaving 5 unused rows. Alternatively, 400 tie point boards could also be used if I need more space. I do like the look of the tiny boards though - the colours could be used to represent different programming constructs...

Picking the platform (Arduino) and the form factor (170 tp breadboard) was the easy part - now I need to work out how to connect the blocks/modules and get them to communicate. There needs to be some way for a control unit to query all the blocks/modules attached to it to determine their order and functions.

(Aside: I tend to use the terms block and module interchangeably with this project. I am still not quite clear myself if there is a distinction between the terms (in the scope of this project) and if so, why. I _think_ a block should represent a programming construct - a variable, IF, THEN, ELSE, output, etc. - and a module probably also includes things like expressions and any input or output devices. That seems to make sense and is how I will try to use the terms, but forgive me if I slip up and switch the terms around every now and then...)

I want(ed) to keep the blocks (and modules) as simple as possible and minimise the wiring, while maximising the flexibility of the designs. Each block should represent a single programming construct and should therefore know what thing it represents. (i.e. "I am a blue variable" or "I am a FOR loop".) The connections between the blocks needs to be standardised, no matter the function of the individual blocks. For example, I want to avoid having a FOR block requiring 6 input connections and a variable only needing 4 inputs. 

My initial thoughts were I2C, SPI or serial connections. I2C was ruled out early on, as that would require each block getting a dedicated address (although I think I have a neat way of dynamically assigning I2C addresses that I want to try out) and I couldn't find an easy way to work out the order that the blocks were connected. SPI was also rejected early on, leaving serial as a likely possibility.

I grew up with Commodore computer (the Vic 20 followed by the Commodore 64) and these wondrous devices used a serial bus for their peripherals. Peripherals could be daisy-chained together, with each device having a pass-through port to connect the next in the chain. This seemed like a good fit, although with Commodore's serial bus, each device had a unique id used to address the device - I needed to allow blocks to be connected in an arbitrary configuration.

If I connect the blocks using a serial connection, I still needed a way to determine the order the devices were connected. For this I took inspiration from the WS2812 LEDs (aka NeoPixels) that are so popular. When using these LEDs, you can send a stream of data out and the first LED takes the first few bytes as its command and passes the remaining data through, the next LED takes the next few bytes and passes everything else on, and so on. The only problem with the WS2812 protocol is that it was unidirectional - data was sent by the microcontroller, but the LEDs did not send any response back upstream. I thought this scheme might be worth exploring if I could solve the unidirectionality...

(Note: While my proof of concept works, I am revisiting the whole process while documenting it here to see if there is anything I would do differently to improve the project. I already know some changes I want to make, but trying to document my thought processes might help me discover other changes I might want to include.)