We have used a robust set of UART communications routines for years on RX processors for machine to machine (m2m) communications.
In attempting to use the API routines from SSP to communicate with RX devices using these routines we discovered that our SSP based routines did not work well. The SSP would see noise characters as "Break" signals. Also the thread sleep issues created timing difficulties with our retry algorithms in the RX routines. We decided that we needed more control of the SCI module to have bullet proof communications between Synergy and RX devices.
Our protocol is very simple. A start character 0x7E followed by two bytes of total message length followed by the message and the last character has a simple 8 bit checksum. The example I have attached is for the receiver in the master slave relationship. You can infer how a master would work from the slave example. I have not needed a master on the Synergy yet. This method is very efficient. The receive ISR builds the message and checks the checksum. If a valid message is received it sends a semaphore to the waiting thread for processing. If noise characters arrive they are thrown out immediately. Also if a message is garbled the ISR routine will re-sync on the retries. We use three retires and it seems to always re-sync and get the message.
Notes:
- This example is NOT thread safe. We only use this in one thread. Any global variables are uint32_t types aligned so it is impossible for another thread to crash a read or write of this variable (poor mans mutex)
- The code in AppCom2.C and .h is derived from our RX code. The only changes are how registers are used and how interrupts are handled. The rest is directly from our RX code
- NOTE that the interrupts now require attention to both the peripheral and to the cmsis interface. I think this is clear in AppCom2.c
- There are several ways to accomplish the integration with SSP. In my case this is the only UART in the system so I do not include a communications framework in my project. If you need an SSP communications framework you will need to modify some SSP code to get your routines into the isr vector table. The issue is that the framework will define the ISR vectors for you even if you do not use them in the framework so you will have two definitions for the isr routines. I decided to keep it clean and not use any framework code for this code port from RX code to synergy.
Design Process:
- In SSP I create a thread to be used for this communications
- I do NOT use any SSP communications frameworks or API calls
- I use the ICU tab in the configurator to create interrupts for the SCI 2. This will add the ISR vectors to the cmsis interface and set up the ARM interrupt handling. I use the pre-defined isr names that are now added to the vector table in startup_s7G2.c
- I use the pin configurator to configure my pins for UART use
- Add AppCom2.c and .h to the src folder
- There is nothing else required in the configurator
Neat "Cheat" process:
- I did not want to study the hardware manual (that is so old school when you have synergy)
- I used the configurator to set up a communications framework and added my UART 2- 115200 baud, etc.
- Then I went to debug and started the program. After running I did a breakpoint
- Go to the "IO Registers" tab and look at the SCI 2 registers. I compared the values to the defaults in the hardware manual and any that were changed from default I copied to my init code in AppCom2.c. Basically let SSP show me how to set up all the SCI registers !!!
- Then I removed the framework from the project.
How it works:
- The init code in AppCom2 turns on the SCI module, then writes directly to SCI registers as needed.
- The init code also turns off all interrupts. All interrupts are controlled by "prepare to receive" and "SendBytes"
- All variable defines are in AppCom2.h.
- "Ser_2_PrepareToReceive( uint32_t isUseMsgProtocol )"
- Sets up the receiver and enables receive and error interrupts
- If isUseMsgProtocol == true:
- Tells the isr to robustly receive a message of unknown length in our protocol
- The isr throws out noise characters and will re-sync if garbage is received
- The caller should then set up a wait forever on the message received semaphore
- If isUseMsgProtocol == false
- Receive all characters and put them in the receive buffer a they come in
- Not a fifo buffer. Intended to be started each time you are looking for general input
- We use it to receive characters from a user via a terminal program when the board is in factory test mode
- gSer_2_RxCount can be monitored to see how many characters you have in the buffer at any time
- We also have a 1 ms timer running that increments gSer_2_MsSinceLastCharTicks each ms
- If a machine is sending a string not in the protocol you can monitor this variable to see if string is complete (poor mans mutex - this variable is thread safe)
- Ser_2_SendBytes( uint8_t *p2data, uint32_t numBytesToSend )
- Copies bytes to output buffer
- Sets up interrupts and starts the transmission
- It is not blocking
- You can monitor the global gSer_2_IsXmitFinished to see when the transmission is complete (poor mans mutex again)
- I think the isr routines are documented and I won't comment on them except that you should note how you must deal with both the SCI module registers and with the cmsis interrupt interface
Receiving messages and responding from the thread:
- Create the semaphore
- In while 1 loop:
- Prepare to receive with protocol = true
tx_semaphore_get(&g_process_received_message_semaphore, TX_WAIT_FOREVER); // wait for valid message
- When the semaphore returns you have a validated message
- Simply parse the message
- Build your response message
- Call SendBytes. In my case I use the blocking routine in the thread code which monitors gSer_2_IsXmitFinished to block until message is sent
- Then start all over again
I hope this code example helps any one who needs to port some special code to Synergy and needs to use peripheral modules in a way that SSP does not support at this time.
Steve Dillier
HighPoint Design
Irving, TX USA