adamgreen / mip_promini-pack Goto Github PK

I started this project in response to this issue. This issue concerns the fact that the Sparkfun MiP ProMini-Pack running at 8MHz/3.3V can't reliably receive 115200 bps serial data from the MiP.

I am opening this issue to open a dialog with @Tiogaplanet and anyone else that might be interested in this attempt to produce an updated version of the board running at 16MHz/5V.

Progress So Far

• I have committed a first draft of the changes that I want to make to the schematic:
  • Bumps the clock rate up to 16MHz and the voltage up to 5V (5V needed for AVR to run reliably at 16 MHz).
  • By default I no longer connect the FTDI header's VCC pin to anything. I have never liked that both it and the MiP battery could be powering the board at the same time with no diode protection in place. There are also some FTDI adapters out there that supply 3.3V on this pin while most supply 5V. If the user has a 5V FTDI adapter and want to power the board from it then they can short the 2 pins of J1.
  • The TS3USB221A switch is still powered at 3.3V. I added 1k ohm current limiting resistors to its inputs and also added a Schottky diode for 5V->3.3V level conversion on the TXO pin.
  • I cascaded the 3.3V regulator off of the 5V supply so that the board will work if powered from the FTDI cable.
  • Added an AVR ISP header to make it easier for me to get the Arduino compatible bootloader initially loaded into the ATMEGA328. My plan is to place this on the back of the board and use a temporary pogo pin connection instead of soldering in a bulky header that would interfere with the battery pack. Would want to do this bootloader programming before C2 is installed on the RESET line since it will cause the programming to fail otherwise.
• I haven't done any work on updating the PCB layout yet. I want to feel like we have finalized the schematic updates before starting the layout.

@Tiogaplanet I would appreciate any feedback you have on the schematic changes made so far. Anything else you think I should address? All feedback welcome!

I just tried installing one of my MiP ProMini boards on a recently purchased MiP and it fails to connect to the MiP as @Tiogaplanet describes in WowWeeLabs/MiP-BLE-Protocol#20.

I have entered this issue to track my investigation into this issue from my end to see if it is caused by a hardware/software issue that I introduced or can work around.

My hardware version shows up as the following in the official iOS application:
d060217 v1 bV0.6

It make sense to have the existing end() function use the new disconnect functionality and expose the old behavior via a new sleep() method.

I will work on this change.

More of a question/suggestion than actual issue. For animating the eyes, the verification that the write was successful uses the serial line unnecessarily, IMO. Any appetite or suggestions for disabling the check? Maybe disabling the checks or making two new members called:

void writeHeadLEDs(MiPHeadLED led1, MiPHeadLED led2, MiPHeadLED led3, MiPHeadLED led4, boolean doCheck);
void writeHeadLEDs(const MiPHeadLEDs& headLEDs, boolean doCheck);

For example, I am doing writes of random on/off values to each of the four eye LEDs every 500ms to indicate rain. I don't need to verify that every random write was successful.

Feedback from @Tiogaplanet on commit 90f350b:

How about keeping it at five tries of 115200 and with each failure, try 9600 also?

Opening this issue to track that possibility.

Original feedback from @Tiogaplanet:

I don't see any setGame functions but I may have overlooked them.

Rather than adding a public setGame() function, we could follow the enableRadarMode(), disableRadarMode(), enableGestureMode(), etc APIs to add functions like:

• enableCageMode()
• enableDanceMode()
• enableStackPlayMode()
• etc.

@Tiogaplanet, would you like to try adding this support? If not, I can try my hand at it as well.

Original feedback from @Tiogaplanet:

I like the ability to play a list of sounds. I would not have thought of implementing such a thing. On the flip side, I'd still like a simple playSound function that just plays a single iteration of whatever enumerated sound value is passed to it.

This seems like a good idea. I would also like to update the addEntryToSoundList() API to take an optional parameter for setting the volume so that the user doesn't have to explicitly use the MIP_SOUND_VOLUME_* entries. It is probably ok to also default the existing delay and repeatCount parameters for addEntryToSoundList() and playSoundList().

This functionality would be useful for storing variables across power cycles on the MiP. It could also be used to transfer data between Arduino sketches and Bluetooth apps.

I've started the work, shown in my latest commit. It's not working quite right and I think the problem is in one of the lower transport levels. My output from ReadWriteEeprom.ino looks like this:

ReadWriteEeprom.ino - Writes data to EEPROM and reads it back.
MiP: Bad OOB command byte: 0 (discarded 0 bytes)
MiP: Bad OOB command byte: 0 (discarded 2 bytes)
MiP: Response timeout
Scrambled password: 0
Recovered password: 0

Will resume writing/debugging tomorrow.

I'm creating this issue to track my progress on enabling IR support. I've started by trying to send and receive IR dongle code. I think this needs IR remote control enabled to work but I can't tell for sure after reviewing WowWee's documentation. Right now my recieveIRDongleCode() goes into an infinite loop of MiP timeout error messages. I need to fix it up so that if there are no dongle codes waiting, then exit quietly. I suspect the implementation needs to look like reading gesture or radar events.

Anyway, I've gotten as far as I'll get tonight. My latest commit is posted.