When I first went back to this project, in December or January, I looked at using Avenue33's code. There were a couple of issues.
First, his library hadn't been updated for use with Arduino 1.0, and required a hodge-podge of NewSoftSerial and some modification of other libraries. I couldn't get things to work, and I couldn't get help getting them to work (I'd been told three times "Use the new library").
Second, Avenue33's library (the last I looked at it) allowed you to drive the display completely from the serial port. Screen rendering, data storage, everything, all would be done by the Arduino, with no real usage of the uOLED's on-board processor. I think that's the big trick for this project: Have a gearbox computer that drives "AEG Stuff" and a display computer that drives the user interaction other than the trigger.
https://lh4.googleusercontent.com/-NAfU ... 2Bcopy.jpg
Here's where I want to get the tactical display, eventually.
I'd like the display to be as innocuous as possible. There when you want it, able to yell at you if it needs to, but other than that, quiet.
If you need more information, you can look a little harder at the display, and it's available. If you need detailed information, you're going to jump into a higher level of interaction with the computer (Hands off the trigger and selector).
The data that needs to be updated, on the fly, is really represented by the four quadrants. You're not going to change your fire mode in the middle of firing.
(I just noticed that the FPS value is seriously in error).
All of the data is accompanied by a small relative status indicator. This will give a level of situational awareness beyond a simple number. It's designed to give you some idea of how close you are to your pre-established limits. Hitting a warning threshold will trigger some kind of notification. Hitting a critical threshold will change the behavior of the AEG (Under-volting will shut off the gun. Spiking the temperature will lock out the firing circuit. I have a neat idea for the low mag critical event, I'm saving that until I have a chance to test it). All of these behaviors will be user definable through the programming code. I'm hoping I can define the behaviors through "Code-Blocks", to let the user "pick and choose" the behaviors they want for their AEG.
Back to the points you guys made:
I think I've gotten my head around the use of binary. I'm having to go down mental levels of abstraction, but I'm getting it.
If I'm reading Dan's point correctly, and I understand the serial protocol correctly, should we break the message up into two bytes, minimum? First for the message type (Amperage Min/Max, Voltage, Temp, etc), with the second byte being the encoded value? Doesn't your system require two packets anyway (A 5 bit frame and an 8 bit frame)? I'd like to have more room to send different messages, and a "unified protocol" to send the messages, whether the gearbox is firing or not. Right now, the display is not really going to be able to tell when the gearbox is firing. It doesn't need to. It just takes the information, processes it, and serves it to the user.
Looking at the "Round Fired" suggestion you posted, wouldn't it be better to have the "Round Detected" read "11111" and "No Detection" read "00000"? This method gives "Five degrees of certainty" and would also be able to give an indication of noise on the line (Any "Round Fired" packet without all 1's or 0's would still give us the information we really need, and tell us something else as well).
Dan's testing code sent two pieces of information, every millisecond, down the serial link. We don't need to send that information every millisecond. We need to send it at the summation of every shot. The Arduino needs to look at that information, but the processing is done locally, and the decisions to keep cranking the gearbox are all local.
Once the gearbox has registered a completed cycle, it sends off the needed information to the display. My understanding is that the serial port is buffered. It takes less time to write to the buffer than it takes to send it. That works for us because the sent information isn't "gearbox critical", and the gearbox can continue doing it's thing. If each shot, on average, takes 20 milliseconds (That would be 50 shots per second), that still gives us an insane amount of time to send what we want to send.
I don't see a reason to send data every millisecond (or any other period of time), except during a diagnostic mode when we really only care about what is happening in the gearbox (This is Dan's earlier code that generated the spreadsheets after I learned how to us PuTTY). If we just send it at the summation of every shot, it's fine. Outside of a firing sequence, I'd have the gun do periodic checks on the status (Temp, voltage, etc), but those aren't critical.
I'll try to get a flowchart up of how the two processors are interacting. I think that will help.