7SDevice part5

Measure And Testing
The first thing to do after the board has been built and 16f84a has been programmed is to check all tracks are ok. I suggest you to check tracks before soldering any component or socket. Don't forget to solder component wires on bottom and on top where appropriate. Look at the board picture.



Now let power on the board.


 * Starting from 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 switch on and the self test starts. The counter should increment passing all available digit as seen in the table before.

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.
 * 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.



Let do some measures 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.



Protocol Analysis
Now i want to dig deep in 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.



Here is depicted the transmission of two digit 0x01 and 0x10 that is 1A. SCK bit period is around 100 uSec and the total time for both digit transmission is around 1.6 msec. As we designed for each bit received, the device write a 0 to inform the host she is ready and write a 1 to inform the host she got 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 identify a read 0 byte. This is because the host sample the device output at the same time he rise 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 8th bit the device use more clock cycles to update a variable and while the host lower the clock line she hold the MOSI line high signaling that is not yet ready to accept an other bit.

If we zoom this picture we can check the on going protocol we designed in part 1. Look this picture




 * At time M0 host set clock down
 * At time M1 device set MISO down answering "i'm ready"
 * Host put data on MOSI line and at time M2 rise clock signaling "Valid data out"
 * Device need time between M2 to M3 to process the bit and say "I got the bit"
 * Immediately after the host lower the clock to send an other bit but device is slower and respond in about 40 usec

As a final check we zoom the SCK to measure data.



Since there are not delays in the host and device implementation this is the max speed available. It depends on device slowness since program clock is Fclock/4 (1 Mhz). Some instruction are executed in 1 usec while jump or other conditional instruction 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 then the human eye capability so everything works as designed.

= Conclusion =

Has been a long article. I thanks all 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 will be nice if the host could send only a digit .. the right one or the left one .. without loosing sync. Since the char set is only 22 there are 3 spare bit 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 bit 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 it and never update digit by mistake. You can also implement I2C protocol with the same hardware ...

= File archives =

All file can be downloaded here

I hope you will enjoy reading and experimenting with this device as much as i did while writing down this article. Should you want to ask something write me back at f.capozzi[_at_]tin.it, you are welcome.

Thanks all, Fabio

= All parts of this article =
 * Part 1 - Goals and constraints
 * Part 2 - Hardware design
 * Part 3 - Protocol Handshaking simulation
 * Part 4 - Software
 * Part 5 - Measure and testing