Work has been going on feverishly to get the obsolescence upgrades to this development board into final release, stuff components and get example firmware developed to demonstrate the basic features and capability of this neat little board.
Currently, the new design is complete and a proof has been built to test code.
The changes to the MSP430AFE253 Development Board were recently completed and first prototype placed on order through OSH Park. These boards are expected to be received by mid August. There is some basic firmware ready for this board that supports serial port communication and button and LED test.
Please make contact via the contact page if you are interested in purchasing one or more of these boards. For more information, including design files, etc, please see the github repository here. Or see more after the break.
Have you created various libraries for the Arduino to interface with different pieces of hardware? Have you ever bought an Arduino shield that had multiple hardware interfaces but it didn't come with a proper library, and instead maybe a jumbled mess of code in one big sketch file? Writing a self-standing library (see also base class or parent class) for the Arduino isn't the hardest thing, but when you progress into multi-level class structures with class dependency and inheritance, things get a little more complicated, but the end result hopefully is a well organized library with structured data encapsulation and a more simple model for future enhancements and maintenance. As most of my embedded experience lies within the traditional bounds of the ANSI C language however, I find myself having to do a fair amount of searching from time to time on how to implement the features I want using the C++ language.
My latest task found me wanting to create a library that encapsulated the functionality of multiple libraries that already existed into one library interface. This is referred to as a parent/child relationship, or a base class and a derived class. The parent is the base class and it's features can be inherited by the child class. The child class is also called the derived class, as it's functionality and features are derived from the base class. I'm not going to get into access modifiers, such as public, protected, private, etc. In my case, however, I was wanting to have one child class, a library interface to a common Arduino shield, which was derived from multiple parents, or base classes.
Last weekend, I had a chance to catch up on development and testing of code for the Serial NVM boards. As you recall, I had a slight mishap on the last rev of boards ordered from OSH Park, to which I have added a jumper wire and am using these for code development and testing. Last month I completed the Arduino library to drive the Microchip MCP23S08 serial IO expander and can be downloaded from my bitbucket repository here.
I had previously begun working on Arduino libraries for the different versions of the Serial NVM board, and last weekend I completed the library for the M95M02 SPI EEPROM and tested it alongside the MCP23S08 to ensure the chip select schemes and timing all worked well together, which they did. I had a little trouble at first writing and reading back a test string, but thanks to my USB logic analyzer, it was an obvious timing issue of not waiting for the recommended write time 'tw' after releasing the chip select before attempting to read back the data. The library for the M95M02 is also open source and can be downloaded from this repository here. Next step is to create a new library that wraps these two libraries into one, allowing access to all the functionality from one library while also allowing the entire array of chips to be accessed as though it were one contiguous chuck of memory.
Usually I'm able to figure most things out on my own - but since late yesterday, I have been battling getting my MSP-FET430UIF debugger to work in eclipse after the debugger firmware was upgraded to V3. I knew there was the option of downgrading, but I knew, I just knew there had to be a way to integrate my existing debugger, upgraded to V3 firmware, with an IDE I favor (eclipse) and the gcc debug environment. Read the rest of the story after the break...
I am long overdue for an update, so this will probably be a lengthy one... Last year had some cool highlights from basically starting my website for Casco Logix to being featured on hack-a-day here and here, to being featured on EEWeb as the "Site of the day" here, to launching some initial simple but fun products for sale on my site here.
Here are some of the other things I've been working on lately since my last post.
There was a fairly significant design flaw in the first rev of the Serial NVM boards regarding the manner in which the chip select (CS) signals were asserted by the MCP23S08 IO expander chip. This design flaw came to light after I took a mental "break" from the project while waiting for the boards to arrive in the mail from OSH Park. The issue was realized literally as I was opening the mail pouch.
So, rev 2 was implemented...? What's going on now...?
About a month ago I got an unsolicited email from someone asking if it would be okay to highlight my website as the "website of the day" on their website. Initially I thought it was a joke or scam of some sort, but in fact it wasn't, and not only was it not a joke or a scam, the website requesting permission to highlight my own was none other than EEWeb, a mainstream engineering science and technology internet resource. Thank you EEWeb!
The order for the rev 2 Serial NVM Boards is officially in. I hope to have these new boards by December. Still kicking myself for overlooking the communication protocol issue (e.g. chip select). But with the changes I was able to slightly shrink the board, removing several pullup resistors and adding 3 new parts to correct the chip select issue.
I just finished the rev 2 board layout for the Serial-interface NVM Expansion Board with the added hardware to properly assert the CS lines in a mutually exclusive manner. I was also able to slightly reduce the overall size to 1.0" x 2.0". These will get submitted to OSH Park in the next day or two, or as soon as I have time to generate gerbers and carefully review them - a must unless you like spending your money on PCB's that will only get used for wall art. As I mentioned in a previous post, sample firmware development as begun and I hope to have this available soon to share. I also have plans to repackage this board into an Arduino form factor once all functionality is proven out. Stay tuned...