Project kickoff

[adamgreen]

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!

[Tiogaplanet]

@adamgreen This is great news! Glad to see this project and thanks to you for starting it.

I was never able to get enough of the original board working to really constructively criticize its features. I'd be happy with the changes you've described above and then making sure we can get a functioning library to run on it before considering other changes. Do you plan on keeping the room onboard to add headers? I was looking forward to employing those to be able to add even minor functionality to the MiP.

[adamgreen]

Do you plan on keeping the room onboard to add headers? I was looking forward to employing those to be able to add even minor functionality to the MiP.

Yes, but I switched all of the Vcc (3.3V) pads to 5V. Should I expose the 3.3V supply as well? JP8 and JP9 allow you to select between 5V and Vin (~6V) but are split so that you can have one of those voltages on the bottom half and the other on the top. I could modify the bottom jumpers so that they select between 3.3V and Vin instead. What do you think?

[adamgreen]

With commit dcafb2c, 3.3V is now exposed on the lower half of the two vertical power buses in the prototyping area of the board.

[adamgreen]

I have placed an order with OSHPark to have the new version of this board produced. Here are previews downloaded from OSHPark:

[Tiogaplanet]

@adamgreen It looks great! I can't wait to have another go at this.

I'm on travel right now and for most of March, hence my silence. But I can't wait to see how this all turns out.

[adamgreen]

@Tiogaplanet There is a good chance I probably won't get back to it until early April either since it will take a few weeks to get the boards back and by then I too will be traveling. I hope your travels go well.

I will reply back here again once I get the new board populated and tested.

[adamgreen]

@Tiogaplanet I just wanted to update you on my latest status. The new PCBs arrived from OSHPark while I was traveling and I just got around to soldering them up last week. So far the new PCB design appears to be working well. I did find one issue with the 3.3V supply that I will investigate a bit more but I already hacked the current PCB to work around that issue for now so that I can continue testing. I did verify that this version of the PCB can reliably read the software version out of the MiP via the UART @115200.

I will port my existing MiP-Capi library to the Arduino and use it to conduct more thorough testing this week.

Here is a photo of the new PCB mounted on my MiP.

I created a custom jig to allow me to program the Arduino compatible bootloader into the AVR. This only needs to be done once and then it can be programmed via the Arduino IDE.

[Tiogaplanet]

@adamgreen That looks great! Are you ready or willing to ship? If so, I'd love to continue trying to develop my own library. I'd offer assistance with yours but I doubt you need it.

[adamgreen]

@Tiogaplanet There are a few problems with this version of the PCB that I plan to correct in the near future. So far there isn't anything major and I have been able to work around them. I could wait and build up one of the corrected PCBs or I could populate another of these and send it to you. It's up to you.

As for the library, I was planning to finish porting & testing my C API in the Arduino IDE. Currently it has 2 layers. The high level MiP protocol exposed to developers and an underlying transport abstraction. Once I have that working, I was thinking that I would merge the 2 layers for the Arduino version. The code is already kind of object oriented so I would just complete that by turning it into a C++ class. It wouldn't be in the style expected for Arduino libraries though.

How would your library differ from mine or the existing Sparkfun one? Do you just want to take what I end up with and finish turning it into something more comparable to other Arduino libraries?

[Tiogaplanet]

@adamgreen I'm sure I can wait until you have a finished product. This whole project started with my kid's interest. My library was meant to be a direct outgrowth of Sparkfun's original library but using function calls a kid could understand or at least recognize. I don't have my heart set on any particular implementation as long as I or a kid can quickly put a sketch together and have the MiP do something, even if the action is basic.

[adamgreen]

I'm sure I can wait until you have a finished product.

Ok, let me finish my current porting/testing and then we can decide once I have a better handle on all of the issues in the current design. Sending you one of the current versions gets you a board to play with earlier but sending you the revised version means that the final board design as found on GitHub will get more test coverage.

I don't have my heart set on any particular implementation as long as I or a kid can quickly put a sketch together and have the MiP do something, even if the action is basic.

Once I finish my current port, you can take a look at it to see if you want to:

• Contribute changes back to it which Arduinize and/or simplify it.
• Just pull code from it to create your own MiP library.

[adamgreen]

@Tiogaplanet I have completed my port and initial attempt to make it more Arduino friendly. You can see my current Arduino API here. Examples can be found here. I will start documenting this new API later in the week.

I would really appreciate any feedback you have on this API.

[adamgreen]

My first attempt at the documentation can be found here

[adamgreen]

@Tiogaplanet, the updated PCB design has been sent off to the fab. I will post here once I receive them.

[Tiogaplanet]

@adamgreen I can't wait to see it!

[adamgreen]

@Tiogaplanet , I received the new PCBs today and should have time to solder and test them next week. I have an electronic mail account at yahoo.com. The alias I use there is adamgrym. Drop me a line and we can work out how to get the board to you once I have it ready.

[Tiogaplanet]

@adamgreen OK, I reviewed the API and I'm confident that it will be easy and fun to use. Documentation looks great, examples are helpful, code is self-documenting. Once I resume writing sketches for the MiP I can offer informed feedback but I do have a few initial impressions.

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.

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

How about implementing a disconnect per the Wowwee API, in addition to having the end function in your API?

My own struggles with reading the software version using the original Sparkfun board had me implementing cache variables for reads that never or seldom change. Software version and hardware version never change so there is no reason to clobber the serial connection once you've read the version numbers once. Same thinking applies for doing multiple gets with no set in between.

You've done great work here. I can't wait to use it!

[adamgreen]

@Tiogaplanet Thanks for the great feedback! Much appreciated. It sounds like once you start writing sketches again for your MiP, you can probably use my Arduino library as your starting point instead of the Sparkfun one. That would be great!

Once I resume writing sketches for the MiP I can offer informed feedback but I do have a few initial impressions.

👍
I agree. All the more reason I need to get these boards soldered up and sent off to you! :)

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.

I agree.

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

You are correct. I didn't implement that functionality but it could be added.

How about implementing a disconnect per the Wowwee API, in addition to having the end function in your API?

I just used the begin()/end() nomenclature since it is so common in other Arduino libraries. In actuality, I don't ever call end() in my samples since it is such a pain to get it out of sleep mode (need to power cycle the bot after uploading new code). Maybe end() should be switched to use disconnect instead and have a separate API for putting the MiP to sleep?

My own struggles with reading the software version using the original Sparkfun board had me implementing cache variables for reads that never or seldom change. Software version and hardware version never change so there is no reason to clobber the serial connection once you've read the version numbers once.

But on the flip side, you shouldn't be asking for the software/hardware version so often that it is worth caching. However if you didn't want to return the version information in a structure but instead have separate calls to pull out each piece (year, month, day, etc) then it would make sense to cache in that case.

Same thinking applies for doing multiple gets with no set in between.

That might be the case. Once you start using the library to write your own sketches, you might hit performance bottlenecks and that will put the spotlight on where we should make such optimizations. I should mention that I traded off performance a bit to make the library more robust by doing almost the opposite: I often issue a get as part of the corresponding set to make sure that the set actually got through since the MiP does sometimes ignore requests and it has no acknowledge for sets. I tried to make the library as robust as possible with error detection and retry logic so that the user wouldn't need to.

Once you start using the library, you can enter issues here and then we can figure out if you want to fix and send a PR or if I should attempt to make the fix instead. Even for the above mentioned items (playSound(), setGame(), disconnect, ...) would you prefer to make those changes once you start using the library or would you prefer for me to work on them?

Thanks again for everything!

[adamgreen]

All the more reason I need to get these boards soldered up and sent off to you! :)

@Tiogaplanet, I am happy to hear that you have received these boards. Sorry it took so long for me to get everything ready and sent off to you. I can't wait to see your feedback and updates! Best of luck!

[Tiogaplanet]

Soldered a header on last night and ran SRSdemo. Worked perfectly first time around.

Will spend some time coding this weekend. I'm thinking of writing some kind of program to exercise everything you've already implemented. Let's see how far I get.....

[adamgreen]

Excellent!

[2stacks]

@adamgreen great work! I like @Tiogaplanet never gave up working on my MiP. Id love to be involved and help out if I can.

[adamgreen]

@adamgreen great work!

Thanks! @Tiogaplanet did a lot of the preliminary investigation that lead to the kickoff of this project as well and then helped verify my work!

I like @Tiogaplanet never gave up working on my MiP.

That's awesome to hear! What kind of projects have you been doing with your MiP?

Id love to be involved and help out if I can.

Sounds great! Take a look around the current project and let me know what areas you would like to help with.

[adamgreen]

Since the initial version of this project is now available, I am thinking that I should soon close up this kickoff issue. We can now open issues that are specific to the issues and/or features that we would still like to see addressed. Any objections?

[Tiogaplanet]

No objections. I think it's pretty safe to say we're happily past the project kick-off phase!

[adamgreen]

Excellent!

Thanks again for helping out with the kick-off!