Thought I would do a separate post on my open source control boards, System Shock which I am creating for my Skyrim pin.

Here is the family portrait, first time all have been in one photo together since being redesigned. All use cat5e ethernet for rs485 communications and easy installation. each board has a jumper to set the board as the last board on the rs485 chain. the boards rs485 is designed to run at 156250 baud which is something like 20kb/s something. thats 20 bytes per 1000th of a second (basically you could send the entire 128 switch state around the bus 1000 times a second theoretically, good thing we dont need it that often!)

xP7063215.jpg

Top left is the 64 RGB LED insert driver
Top right is the master board, 128 switch inputs
Bottom left is the 32x FET driver
Bottom right is the wee raspberry pi comms board

xP7063231.jpg
This is a closeup of the master board;

128 direct switch inputs, not charlieplexed/multiplexed. Has an eeprom for game settings, config, audits etc. There is a 2 digit error display, also a 48bit unique serial number on each board (would be good for ID'ing a game over the lan when hooked up to a central server to take in game scores, audits and such!) It has a USB plug that is fused with a 2A auto fuse to provide power to the raspberry pi board. This can be the rs485 master board, run the rules etc.

xP7063225.jpg
The FET driver, 32x individual fets. Can be configured to have up to 4 of these boards on the rs485 chain.

xP7063229.jpg
The RGB Insert driver, can drive 64 individual RGB LED's with complex light shows, fades, all running off its own cpu. Can have up to 4 of these boards for 256 RGB LED's. These are not chained, so if one goes down it does not take down a string of them.

xP7063232.jpg
this wee board is the raspberry pi rs485 comms board, it also can be a master.

So I've said the word 'master' a few times, the original design had the switch board being the master, it ran the rules, read the switches and pumped the switch info out over the bus for all the child boards to snoop on and act opon, as well as sending other messages out over the bus. It would send messages to the RPI for doing audio/video like PLAY_SONG #1, SET_SCORE 123113300, etc.

but the pi comms board was the last board I did and I made it so I could use it outside of this project for other things, so that meant I could make it a master board as well.

with the pi being the master board, all the rules could move to here, off the switch driver board. that would make it more flexible for non C coders (the switch board is PIC32, and you need to write the rules in C), since the PI can run whatever (misson etc if I did the port). the only downside there is the switch board would be trying to 'control' the bus more than the master (PI) board would be, and software would need to be written to handle contention of having two boards being able to 'control' the bus.

once I've soldered them all up and tested them, then I will push it and the base code to my github.

Im probably forgetting things but its late and I'm tired lol

one thing I became aware of later was I'm hooked to the 3v3 pin on the pi, which can only supply 40ma or something, so that board may need a change to swtich 5v down to 3.3v so I dont kill the 3v3 pi pin... and i may just go back to my original design of tethering the pi directly to the switch board with a good old idc cable so the pi is off the rs485 bus.. <random thought>

1) eventually Id love to sell them as like a little kit.

2) at this point dunno. Need to get what I have together first and start testing

Ill have to look into seeing what it would take to port mission over. I'm not a python guy at all, dont like it one bit. c or ruby or death!

but ill see if i can find some time to see what mission needs for a port.

Morning Brian, I loosely follow MPF on git and pull it for updates every once in a while. As for system shock boards, each board has its own processor that gets initial configuration on boot up from the master board, then it does its own thing. the solenoid board takes care of pwm'ing the solenoids etc, you basically send a "SX" X being hex number, and the board will either fire it once and be done or fire and pwm it until told otherwise, it also adds a random time to the pulse so its not always the same strength (unless configured to be). same for the RGB LED boards, send a "L0:0" and light show 0 plays on led 0, and a light show could be a list of 10000 commands (the LED board runs a bytecode interp that does fades/wipes/pauses etc), the switch board (currently the main rs485 master), pumps the switch state over the wire every N times a second, which goes to all child boards. Im going to have to do some code rewrites to try and get the PI to become the master board and get the switch board to be a subordinate and it can request switch state to be sent, that should fix a few things up.

With the child boards all having their own processor I'm not sure how much MPF will need to do behind the scenes.

yeah. I think you could use standard rs232 to usb from the switch board and then rs485 over the gpio rx/tx pins