I've started mounting mini switches in the pegboard lid of the project box. I think I'll teach Adam to solder and have him practice on all those switch leads soon :) The pegboard worked out really well since I didn't have to drill any holes, and I get a nice alignment grid...
I've been doing lots of thinking in my "in between time" this week - and "picking the brains" of some people I interact with. I'm using this post to document those thoughts and I'll share some parts I've ordered, as well as some tools / books that I think will increase my learning.
Thinking:
Most of my thinking has been about the "configuration" for a specific car. How will an input trigger lead to output commands on a specific slave? I don't want this logic co-mingled with all the send / receive code on the master, and I'd rather not mess with reflashing the gator+ each time I want to change the behavior of a specific output.
For now, I have an array structure in mind that I think will do the trick.
Example:
Pin 5 on the master is wired to the headlight switch.
In the master's main loop(), all inputs are read >50 times per second
A Pin 5 read returns LOW showing that the switch has been turned on (You can switch ground instead of 12v+ so you reduce the possibilities of short circuits under the dash and the size of the wires to switches, etc)
The array is read to locate all rows where the first integer is 5 (for pin 5)
In this case 3 rows are found:
Input Pin, Slave, Command, Var1, Var2, Var3, Var4
[05][01][01][01][07][00][00]
[05][01][01][01][09][00][00]
[05][02][01][01][11][00][00]
So, this means that three commands should be sent (these are hypothetical...)
[05][01][01][01][07][00][00]
Input Pin: 5
Slave: 1
Command: 1 (this is the on/off command)
Var1: 1 (this means turn ON the output pin)
Var2: 7 (output pin 7 is the pin to be turned on, and output 7 on slave 1 are the headlights)
Var3: 0 - parameter not used for this command
Var4: 0 - parameter not used for this command
[05][01][01][01][09][00][00]
Input Pin: 5
Slave: 1
Command: 1 (this is the on/off command)
Var1: 1 (this means turn ON the output pin)
Var2: 7 (output pin 9 is the pin to be turned on, and output 9 on slave 1 is the dash lighting)
Var3: 0 - parameter not used for this command
Var4: 0 - parameter not used for this command
[05][02][01][01][11][00][00]
Input Pin: 5
Slave: 1
Command: 1 (this is the on/off command)
Var1: 1 (this means turn ON the output pin)
Var2: 7 (output pin 11 is the pin to be turned on, and output 11 on slave 2 are the taillights)
Var3: 0 - parameter not used for this command
Var4: 0 - parameter not used for this command
This would be a very simplistic "if input" "do something" without any real logic. My goal sometime soon would be to try to map out the full operation of a car in this structure to see if I need something more fancy. I have another more complex structure in my head that would maintain a state machine and then allow commands that modify the state machine, allow if / then logic, etc. but that might be overkill.
Once I know the size of this array, I can determine if searching it for a high pin number is CPU prohibitive. I may need to add an index to the array and then have a lookup table like
Input Pin, Start Index, End Index
This would allow me to quickly go to the commands for that input pin. However, if the total command list is only 50-100 items, the other array may not be worth the overhead.
This array structure could easily be read from EEPROM, SD Card, etc - which would allow changing of the car's configuration without reprogramming. For now I'll just build have the array setup in code, but it seems like a good way to go. I can't help but feel like I'm reinventing the wheel here with a command structure and array storage, so I need to look around to see what others have done before. For those with automotive knowledge, there are standards for this stuff - my I2C network & messaging is really a simplified CAN. I don't plan to interface this stuff with other hardware, so I figured CAN was overkill.
I've also been considering the power consumption of the 3 gator+ boards since they will be on all the time on a car that doesn't get much use. There is a sleep mode I'll investigate and I may need to switch the LCDs in some way to reduce their power consumption. It may also be possible to leave just the master on and power down the slaves until needed.
Parts:
LCDs - I know I want the master node to have a serial LCD for output of important items, I'm not sure about the slaves. The "control panel" used a bare LCD and took WAY too many I/O pins, so I spent a little more money and ordered serial / I2C 20x4 blue / white displays. I bought 3, even though I may not use them for slaves long term, they are really handy for debug output, so why not have them for now. I will try them in I2C mode, but I'm not sure I want any extra traffic on that bus, so they will likely get connected to the spare UART on the gator+ boards. This way, I have the option.
I2C Buffer ICs - I found these last weekend - the I2C network is working great now, but for future projects, I really like the idea of I2C instead of ethernet over long runs of cat5. I almost ordered them, and was already designing the perfboard in my head when I saw this line - "Breakout board available soon. This board will enable easy remote I2C bus extensions with standard cat-5 cable. With RJ-45 connector, breakouts for unused cable pairs, option for providing remote power and selectable bus pull-up resistors." Perfect. I'll wait for those boards to be available, and if I suddenly have I2C problems on this project, then I'll grab the ICs at that point. This type of learning is so awesome, I just keep adding to the toolbox of components I know exist and I know how to use if needed.
Storage - I want some way to store the car-specific configuration and read that configuration at system startup. I'm looking at several options - SD Card, USB Flash Drive, and EEPROM. SD and USB Flash are easily removable and readable via computer, they also give me storage for logging - BUT they consume lots of precious memory space with the libraries that read / write. It might not be an issue... EEPROM is inexpensive, but not so easy to unplug and connect to the computer to update the configuration. I need to keep thinking on this one to determine a) how important is logging, and b) how would an end user that isn't an arduino coder update their car's configuration...
Tools:
Power Supply - I've been wanting to get a selectable voltage benchtop power supply for some time. I'm sure there are less expensive options, but I'm eyeing this one from SparkFun. Once it cools down a bit, I want to setup one of my garage workbenches properly to be able to work in the garage on this stuff without creating a room full of wires & parts.
Logic Analyzer - The more I'm learning, the more I want to be able to troubleshoot faster and see what is happening at a lower level. Adding tons of debugging Serial.println() statements and reflashing the arduino program gets old fast. I've learned about logic analyzers and want to get the analyzer from Saleae Logic. I think this will also be a great way to learn more and to help my sons see how digital circuits work.
Inexpensive Oscilloscope - Never owned one, always wanted one - this portable o-scope is a great start without spending $2k :)
Books:
I purchased "Make: Electronics - Learning Through Discovery". I think it will be perfect for teaching the boys in a "lab" type setting. The book has a great line on the cover "Burn things out, mess things up - that's how you learn."
I also grabbed "Practical Electronics for Inventors". I've looked at it a few times before, but wasn't ready. Now that I need to go deep into some MOSFET circuits, I'm ready to get more into the theory and try to do it right. Should be a good way to kill some upcoming airport / airplane travel time.
No comments:
Post a Comment