Before a couple of weeks the CLI code compiled and downloaded to the target. It took a few hours to do any necessary code porting due to compiler differences (mostly some defines).
I also had to fix some project settings on my Processor Expert (PE) configuration to work correctly on Internal RAM or Internal Flash configurations for the Perseus board. Now everything is smooth. I prefer to test on Internal RAM (as a program memory) as at this phase I will need to do many iterations (and thus save my flash memory for later). The code is not very big at the moment so It can fit on the 64KB of my MCU.
The first hickup was that my terminal was receiving 2 bytes as a response (ie. 0x30, 0xFF) from my target. I was afraid that my FTDI which was in a QFN package may not be correctly soldered. I already had difficulty to solder it. I used a QFN part by mistake, as I try to avoid them for prototypes which require manual soldering. I had to probe with my Oscilloscope to the Rx/Tx lines. I soon discovered that the stop bit seem to have double width (and thus re-initiating a Start sequence for the UART). I could not control this through Processor Expert (the Parity was grayed out). I then discovered that I used a wrong PE component. I used AsyncroMaster instead of AsyncroSerial. Using the correct component I was ready to go.
I had tested everything on TDD, so I was keen to find out if this would work well the first time. Nahh. Merphy’s law. A few things worked or worked partially a few other did not work at all.
Well it is about specifications. I did test with TDD and I assumed how VT100 would work, but did not test the behavior beforehand. Well assumption is mother of failure, right?
The first problem was <CR> or <LF>. Initially my code could handle either one as an end of line character, but did not work well on PuTTY which sent always <CR>. Thus I modified the code to be robust on this matter and do not care about <CR> or <LF> (or select between the two correctly at compile time).
The majority of the minor issues where easily solved. First I tested the behavior in PuTTY and then replicate that on my TDD testbed. The most difficult part was the <DEL> button. Actually the key <DEL> sends the backspace character! Well there is a very good explaination here why.
In anycase everything sort out very fast, and I apprecieated that my TDD testbed helped do lot’s of functional tests before going to the target. As long as the protocol was understood, it was easy to test all the functionality and make sure nothing was broken in the change process.
After the basic line editing worked, I started testing the history function. Ohh, that was easy, worked from the begining… thanks TDD.
The help function had some issues but it was also a quick fix. The help function has to access the top level command table and then get the relevant help strings. Because it has multiple lines to output, the CLI service shall wait the serial port to complete the previous line outputs. Thus a state machine inside the CLI core and the relevant command (in this case Help) to output multiple lines. This is to avoid using extra RAM buffers simply for text outputs.
Did I finish? No I had to test the Flash Read/Write functions, RAM Read and Write, CPU and Version. Everything was set within a few hours.
SPI was another beast, as it did incorporate the newly built driver. This time TDD did its work! Hehe, everything went smooth. I checked the data with the my Osciloscope and tried to access my on-board Serial Flash. Great, I can see it!
It took me about 40 hours for CLI, another 30 Hours for the SPI drivers, and around 10 hours for debugging these modules. I hope the next sprint would go faster. It seems that before doing anything you need to plan (yeah, I already knew that). The most difficult part is to figure out the architecture. It helped me a lot, to get up to speed when I did the SPI driver.
Conclusion
Another sprint finished. I was so happy, but at the same time I knew I had a long way to reach my first milestone. I still have to access my SD card and add a FatFS module.