Hi,

 

When a stack has more than one Master, we're dealing with a multi-processor system. Q: do each of the processors then run a full TF "kernel", executing code for their 4 Bricklets only, or does the master Master Brick CPU run the code for all bricklets in the whole stack?

 

I can imagine the answer, but I don't recall any of the docs explaining this architectural point.

 

do each of the processors then run a full TF "kernel", executing code for their 4 Bricklets only, or does the master Master Brick CPU run the code for all bricklets in the whole stack?

Each Brick runs the code for his Bricklets. A Brick can be in SPI Master Mode (The bottom Master Brick) and in SPI Slave Mode.

 

The SPI Master builds a routing table of UID<->Stack height/RS485 address/Chibi address. On the basis of this routing table the SPI Master can route messages to the correct Brick.

 

This is the part of the firmware that changed in Protocol V2. In V1 the routing table was create once on startup, that worked fine with USB but had problems with RS485/WIFI. Now the routing table is created dynamically, if the Master doesn't know a UID the packet is just broadcasted. This can mean that the system is a little bit slower for the first few seconds, but that is well worth the other advantages.

That's what I suspected. This means that the SPI Master is a bottleneck.. the taller the stack, and the more Bricklets, the more this one Master is going to have to crunch packets. If that Master also has its full complement of four Bricklets to deal with.. at what point do the demands of the controlling application place such a load that TimeoutExceptions start to surface? As a user, I can't profile stack-side code, so I have no idea what level of CPU loading is generated.. (wouldn't it be nice if.... ;-)

 

My polling rate is only 1Hz, but I sample all my input Bricklets without pausing between each getXXXX(). Maybe this "burst" approach doesn't help?