Ok, with the fear of getting geeky on you, I will introduce you to the communication protocol between the “QVGA Graphic Display Module” (Controller) and the amplifier. The circuit boards for the prototype Controller are on order and in fabrication process. It will probably be 10 days before I see blank boards.
The Controller must be able to communicate with the amp and the outside world. I have chosen to use a communication protocol that I have used for years called MODBUS. It was first introduced back in the late 70’s. I remember the Allen Bradley MODICON PLC and cut my first teeth writing a MODBUS interface. http://www.lammertbies.nl/comm/info/modbus.html . It is a scalable protocol that can be as small or large as you like. It is a very secure network used by millions.
Besides the Controller, we will have a PC dashboard available to control the amp using MODBUS. I am in the process of writing the interface in C that will run on the Controller. All that is needed for basic operation is a serial port operating under interrupts to send receive messages. The protocol establishes a Master-Slave relationship. In our case, the Controller is the Master and the Amp is the slave. The Master continually scans the data base of the Amp and duplicates it in the Master. Commands from the Controller are sent to the Amp for control. Data is sent in secure packets.
We need serial receive and transmit interrupt routines which I will describe next. We also use a timer to detect when a packet has been received. Rather than post C code that you would have to interpret, I will describe in pseudo code lingo that will be easier to follow.
We have to assign the pins of the UART (serial) to certain pins of the processor. We also have to provide initialization of the UART port. We are using UART #2 in the chip. Part of the initialization is setting the baud rate to be used. There is a bunch of very specific bit manipulations required in order for the UART to work.
Next we establish receive and transmit buffers.
The computer code structure has a foreground and background. In our case foreground are interrupt routines that happen in real-time. Background is reserved for tasks that we schedule according to their priorities and happen quickly as possible but not real-time.
In the foreground we have a clock running with 1ms ticks. From this basic timing we can schedule timers for various purposes. Important to us is a timer that will alert us when a packet has been received and a timeout has been completed. That tells us that we have a packet to process.
The UART receive interrupt captures each character that comes in to a RX Buffer. The job of the routine is to store the byte received into the next sequential location in the RX Buffer.
After a packet has been received, it is processed. The packet has communication safeguards so that a corrupt packet will not be acted upon. The Controller processes the packet and stores the data.
When the Controller wishes to send a command or some data there is a transmit packet created in the Controller. Once it is created, the data is sent using a UART transmit interrupt. Since interrupts are used, the Controller does not have to sit around wasting time and is busy doing other tasks. The transmit interrupt pulls the Controller off its task for a few microseconds while it starts sending the next byte out the serial port.
I am in the big middle of checking out all the code I just described and planning how the packets will be processed. This is a vital link to get working and will tie the Amp, Controller and PC dashboard together so all the application code can be written.
I hope I have not bored you with this report. I am in the trenches organizing and writing the application for the Amp and Controller.
73, K5OOR – Virgil