Advanced Command Interface and functional improvments #136
Conversation
Added advancedcmd.c and advancedcmd.h. circbuffer.c: - Added circ_buf_flush(), circ_buf_peek(), and circ_buf_getAddr(). main.c: - Added advanced command interface and OpMode/OpThresh commands. nvstorage.h: - Modified eNVItem emun to include OP_MODE and MODE_THRESH. onewire.c: - Tighter focus on interrupt disable to prevent UART loss. sensor.c: - Added OpMode and OpModeThreshold features. sensor.h: - created new type OperationMode_t to define OpMode. serial.c: - Added uart_available(), uart_rxflush(), uart_chkAdvCmd(). - Modified ISR to empty UART Rx FIFO when called instead of pulling out one byte per call.
|
As nobody seems to care ... I actually don't see the point in implementing a binary protocol on top of the serial interface:
I just took over your improvements concerning the interrupt latencies in onewire.c and serial.c into my branch, thanks. You should have split these changes to separate commits (sorry I seem to be in criticizing mode ;-) ). |
|
I agree that a text-based protocol will be more than fast enough, but uploading custom profiles is very handy. If there's no interest of being backwards compatible with the shipping firmware then the profiles can be much more compact as well (only a ramp time and setpoint, then repeat) |
|
My current version may upload up to 4 custom profiles, I'm using 1byte values to represent temperature between 20 and 275°C. I'd like to stick with this kind of profile representation, because otherwise the edit via keyboard makes no sense any more. |
|
I agree that the text based protocol was more than adequate for the commands that were originally defined (almost all were 16 bytes or less). The motivation behind having a binary based protocol was to combat the data loss when sending a long command. I initially created a command following the sscanf() method with 48 %d variables to be filled. It worked about 20% of the time because of data loss. I figured that if the data was sent in binary with a tad of overhead, incomplete transfers could be detected and the tool sending the command could resend or something. Then... I focused on the cause of the data loss and discovered that the serial ISR and onewire code needed to be optimized and that was where bytes were getting dropped. Once I completed those changes, I never experienced data loss making the binary protocol a bit unnecessary. But, I still liked the CRC protection feature (especially for data transfer commands) and figured I would submit it in case others saw potential in it and had ideas of other commands that could benefit. It was intended to complement the already existing text based protocol. |
|
BTW I optimized the serial driver further. Using the IIR bits may not be reliable, it may hide potential transmit fifo interrupts if the receive buffer is full. The Linux driver for the 16550 has the same rational (I looked it up after reading that the UART is actually 16550 register compatible) and uses LSR instead. |
|
@radensb |
|
Although not addressed, please read the LICENSE file, in short it's GNU version 3 and obviously it's open source, you are sitting right in front of it. |
|
Soory, i mean this Windows Application:
|
|
I believe this is the GitHub repo for that project. |
I have added an advanced, binary serial command interface that incorporates CRC validation to support an EEprofile definition over UART feature. This is because the command to set an EE profile requires a relatively large amount of data to be sent and written to the EEPROM, thus verifying it is correct is important. Also included is an Operational Mode feature that allows users to select a reflow control mode via the standard serial interface.
Advanced Serial Command Interface:
The interface is designed for software tool usage that communicates with the oven via CRC verified binary commands. The format is defined as (in hex):
FF 55 <SIZE> <HCRC> <D1> <D2>...<Dn> <DCRC>Every entry is a byte. The first 4 bytes are the command header which easily fits in the UART hardware FIFO. It instructs the logic on how many bytes need to be buffered to process the advanced command (max of 255 bytes) and where the the Data CRC (DCRC) is. The SIZE is verified by the HCRC before continuing. Once the required amount of data is received, it is verified with the DCRC. If valid, the command is executed.
Currently, I have only implemented one command that uses this interface. The command is designed to update the CUSTOM#1 and CUSTOM#2 profiles in the EEPROM. The format is:
FF 55 62 4A EE <PROFILE> <Dh> <Dl> ... <DCRC>where,
0xFFand0x55are sync bytes0x62is the SIZE0x4Ais the HCRC defined as(0x100 - (sum_of_header_bytes & 0xFF))0xEEis the binary command for an EEprofile definition<PROFILE>is the custom profile number (0x01 or 0x02)<Dh>is the high byte of a profile temp point<Dl>is the low byte of a profile temp point<DCRC>is(0x100 - (sum_of_all_the_non_header_bytes & 0xFF))The EEprofile command expects 48 temperatures to define a profile (or 96 bytes as each temperature is represented at an unsigned 16-bit value).
EX:
FF 55 62 4A EE 02 00 32 00 32 00 32 00 3C 00 49 00 56 00 64 00 71 00 7E 00 8C 00 8F 00 93 00 96 00 9A 00 9D 00 A1 00 A4 00 A8 00 AB 00 AF 00 B3 00 B7 00 C3 00 CF 00 D7 00 CF 00 C3 00 B7 00 A8 00 9A 00 8C 00 7D 00 6F 00 61 00 52 00 44 00 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 87Some optimizations needed to be made with regards to ISR handling and availability to handle the length of this command properly.
Operational Modes:
There are three operational modes that are available and an operation mode temperature threshold setting that can be chosen via the standard serial interface.
Both the operating mode and threshold values are stored in the EEPROM and loaded on power up so they don't need to be set every time. The Help menu has been updated to reflect the new standard interface commands that control these settings.
Using the SPLIT mode has yielded great results in my tests. I set the threshold to 65C and used two identical boards on each side of the drawer.
As can be seen from the above example test, the ambient temperature is used until the threshold of 65 was reached, then it shifts to the average temp of my extra thermocouples and controls based on that. As a result, the surface of the PCB follows the profile very well, with the expected thermal lag. The red line is the average temp (the control) and the blue and orange are the PCB surface temperatures. The yellow circle highlights the transition from ambient control to PCB surface control.
