Measure And Testing
The first thing to do after the board has been built and PIC16F84A has been programmed is to check all tracks are ok. I suggest you check the tracks before soldering any component or socket. Don't forget to solder component wires on the bottom and on the top where appropriate. Look at the board picture:
Now let's power on the board.
- Starting on the top, simply connect board connector pin 1 to ground and pin 4 to 3.3 Volt. The Board should immediately power on and display 00
- Now disconnect pin 4 (Vcc) and connect pin 5 (SCK) and pin 3 (MOSI) to ground. Connect pin 4 to Vcc. The board will switch on and the self test starts. The counter should increment passing all available digits as seen in the table before.
- Now program the PIC32_DIY board with the hex file provided in 7S_Host_demo and connect 7SDevice board to PIC32_DIY as seen in section 4.
- Connect the PIC32_DIY USB connector to PC for powering both boards. In a while the PIC32 should start talking to 7SDevice displaying a running decimal counter. If all checks are met the board is now fully working.
Let do some measurements to see what's going on.
Here you find the waveform at the transistor collector endpoint. Here the timebase is set at 2msec for each division and vertical span is 1 volt per division so it is easy to check that 2n3904 is saturated (collector around 0.8 volt) for 8 msec (125 Hz) as we designed. When off the collector is at Vcc (around 3 Volt)
I also measured the current the 7SDevice drawn from PIC32 board. This value changes according how many segments are switched on at the same time.
The current range is between 32 and 46 mA at max. The pull-up SCK and MISO resistor are 1K in this prototype. Here is the SCK signal during demo.
Now I want to dig deeper into the signal flow with a protocol analyzer to see if what we designed has been accomplished and what are the timing. I captured all signal with the Ikalogic instrument. In this picture the signal logic is as seen from device so MISO is the data signal coming from the host while MOSI is the acknowledge bit from device to host.
This depicts the transmission of the two digits 0x01 and 0x10 that is 1A. SCK bit period is around 100 uSec and the total time for both digit transmissions is around 1.6 msec. As we designed for each bit received, the device writes a 0 to inform the host it is ready and writes a 1 to inform the host it received the host bit. So it is pretty uncommon in a SPI flow to see the MOSI (device output) signal resembling a clock while the protocol decoder correctly identifies a read 0 byte. This is because the host sample the device output at the same time it rises the clock high so since the SPI is full duplex for each transmitted bit there is a 0 read.
The long SCK pulse between each digit is because on reception of the 8th bit the device uses more clock cycles to update a variable and while the host lowers the clock line, it holds the MOSI line high signaling that it is not yet ready to accept another bit.
If we zoom this picture we can check the on going protocol we designed in part 1. Look this picture:
- At time M0 the host sets the clock down
- At time M1 the device sets MISO down answering "I'm ready"
- The host puts data on the MOSI line and at time M2 raises the clock signaling "Valid data out"
- The device needs time between M2 to M3 to process the bit and say "I got the bit"
- Immediately after the host lowers the clock to send another bit, but device is slower and responds in about 40 usec
As a final check we zoom the SCK to measure data.
Since there are no delays in the host and device implementation this is the max speed available. It depends on the device speed since the program clock is Fclock/4 (1 Mhz). Some instructions are executed in 1 usec while jump or other conditional instructions need two clock cycles. So two digits cannot be transferred faster than 1.646 msec that is 9.417 Khz. This update max rate however is faster than the human eye capability so everything works as designed.
This has been a long article. I thank everyone for having the patience to read through this paper. There are many things that can be improved or made better. This is not by far the best method available to do this task. So, feel free to change, modify or create a better and more reliable device. Should you have time there are some useful things to do, I'll give you some hints.
It would be nice if the host could send only a digit ... the right one or the left one ... without losing sync. Since the char set is only 22 there are 3 spare bits in each byte transferred. You could use a bit to inform the device what is the digit to be updated. You could also use the last 2 bits for adding a redundancy 2 bit check so if the host transmission is noisy and some bit is corrupted in transit the device will know and never update the digit by mistake. You could also implement I2C protocol with the same hardware ...
All files can be downloaded from here: https://github.com/fcapozzi/7SDevice
I hope you will enjoy reading and experimenting with this device as much as I did while writing this article. Should you want to ask something, you can write to me at f.capozzi[_at_]tin.it, you are welcome!
Thanks all, Fabio