Brick Buddy 2 Serial Port Integration

As I stated in this post, the serial port integration turned out to be a little harder than I had hoped.  Brick Buddy 2 uses two serial  ports (USART in PIC32 terminology).  USART #2 is setup as the console port.  This is only to be used during code development and has limited value in the final product. USART #1 is used as the interface to the Bluetooth Module.  This interface is critical to the operation of the Brick Buddy 2.

The system console port is setup as basically described in this document.  The USART is setup as a static driver that is blocking.  This is the simplest setup possible and thus has the fewest dependencies.  At this point this implementation has been integrated for a while.  Changing it now would require a lot of changes I am not interested in attempting.

The BT Module serial interface needs to be very responsive. In the original Brick Buddy (PIC18F implementation), this was an interrupt driven process on the Rx side and a blocking function on the Tx side.  The Tx was limited to 4 bytes at a time, though. This USART will also be a static implementation, interrupt driven with call backs.  This will allow for Tx and Rx buffers to be used to move the data in and out of the BT Module.  Of the three transfer models described here, the byte-by-byte model seemed the best to use.

I created a new project and implemented the System Console and the System Debug services.  Then tested the firmware to make sure it was working.  Then I created a second project that implemented the BT Module USART.  Currently I have no way to test this, so compilation was the only test.  Then I started to merge the second project into the first project, doing a manual code merge and incrementally testing to verify that the console port was still working.

The first attempt failed miserably. Harmony would not let me change the  USART index to 1 in a single USART project.  Thus after creation, I had to go through the code manually and change all the references from 0 to 1.  Not all references were the same, so a global find and replace wouldn't work and I missed a few, in files drv_usart_mapping.c, drv_usart_static.c and drv_usart_static_byte_model.c.

Then there were single case switch statements that had been created by the first project for the console.  They had to be expanded to include the BT USART.  While 80% were just cut and paste, some of them were different from the console implementation.  This is where attention to detail is important. Some of these functions might not be called until much later and remembering what I did today, then, will be very problematic. 

Next step is to test this whole integration.  One way is to install the BT module.  The other is to connect the BT module development board I have.  Need to think this over some and see what will get me through the verification the fastest.