Working or Blogging?

 A very good question.  I would like to blog 4 to 5 times a week, but it never seems to happen.  There is always too much to do and never enough time to do it.

I have been working on cleaning up the code some more for the train PCBs.  By creating conditional compiles on the type of board, the amount of code that needs to be maintained has been reduced by almost half.  This is a good thing, since making updates and adding new features is much faster now.   The biggest change was to implement the Switch-Case structure using STATES in a cooperative multi-tasking model that is implemented in Harmony PIC32 code.  The next big change was to implement structures instead of random variables everywhere.  Again this is the standard in the Harmony implementations.  With PIC18s and limited RAM, you have be careful about instantiating these structures multiple times or you run out of memory quickly.  Judicious use makes the code much easier to maintain.  But this did not come for free.  It has taken time to work out these changes and then get them to work across the four PCBs the code runs on.

On thing that changed dramatically was the MiWi implementation.  I have been using the last non-libary version of the MiWi framework for PIC18.  Each PCB had its own implementation that may or may not be correct.  One configuration item I know I got wrong was correctly setting the coordinator device vs end device role.  This led to all kinds of issues on startup and trying to initialize the app sitting on top of the MiWi framework.  Sometimes it would come up and other times it would just spin.  So here is what I did.

First I created a module with a basic interface that starts and runs the MiWi framework.  Using multiple implementation examples, I condensed this down to several functions calls that handle this within the Switch-Case model.  These are:

MiWi _CreateNetwork is used by the coordinator device to create the network

MiWi_JoinNetwork is used by the end device to join an existing network

MiWi_AppTasks is used by both devices to service the MiWi framework through its various states, depending on the type of device.

There is a built in 10 second delay in joining an existing network, this gives time for the coordinator device to boot up.  This assumes that all devices power on at the same time, which is true in my train layout.  There are also two other support functions.

MiWi_ChannelScan is used by either device to scan all the channels and report the results.  This is a wrapper for the framework implementation.

MiWi_CountConnections is used by the coordinator to count the current number of connections.  I use this to determine if all the end devices have connected and then begin the application processes.

There are two states that are enumerated and one structure that contains all the information about the MiWi Network status and connections.

If you want to see the code, it can be download from the MyMakerTools website.