Thanks Kåre,
The art show is going well. Her stuff will be up all month (at least the pieces that have not sold
She put up several new ones yesterday, to replace the ones that have already sold.
Yes, the Seedstudio boards do look nice. As you noticed the boards by OSHPark, are done by combining several orders into one panel that all get's fabricated together. On one of my orders it mentioned, that there were 87 different orders combined for a total of 501 boards, in the panel they sent out for fabrication. When I get them back I use nippers to clean it up a little.
Yep - I probably should also have some form of ventilation. So far I don't do enough boards to worry too much about.
I am playing with the code Input DIY code now, to see what works. As I mentioned I ran into some issues with compiling all of my code base for the Arbotix. Serial.flush() has not been updated. Serial.readBytes() has major flaw, INPUT_PULLUP is not defined... Would like to upgrade the Arbotix project hardware/core to be compatible with Arduino 1.0.5 r2. I may do a quick and dirty update of my fork of their code to the 1.0.5 core, with the necessary changes. Not sure yet if anything other than not creating Serial1 object?
As I mentioned trying to decide how to handle the buttons. I have code currently that tries to read all of the pending packets in and maybe making a composite value. That is we have a 16 bit value, (one bit for each button on the keypad. My current code is trying something like:
Code:
if (ReceiveXBeePacket(&g_diyp)) {
uint16_t wCompositButtons = g_diyp.s.wButtons;
// With new protocol, we may have received several packets from remote during the last interation
// How should we handle this. For most of the fields, maybe the last one is as good a thing as any
// but buttons, we may want some form of composit, so we won't miss some button events.
while (g_diystate.fNewPacket) {
wCompositButtons = (uint16_t)(wCompositButtons & (uint16_t)~g_diypPrev.s.wButtons) | (uint16_t)g_diyp.s.wButtons;
if (!ReceiveXBeePacket(&g_diyp))
break;
}
The idea is that if the button goes down on any of the messages that happen during the time from our last call here, the composite value will have that button as pressed. But if a button was pressed before I came in here it will only show as pressed if it is still pressed on the last packet retrieved. (as to allow for the button to be released). I am running into some issues with it so I may try the KISS method (just use value from the last packet). This is simple, but you may miss quick presses of buttons.
Kurt
Bookmarks