New UDC write command format WAS Re: [smartsockets]Where and what? B7971
> > Chris,With a binary fixed length command format, how do you ensure that only good packets are being acted on? With the display of the date, time and such, serial data errors are washed out because the data is continuously updated but UDC data once stored in EEPROM becomes the permanent representation of that data, errors or not. Using a bit-mapped command that writes the specific pattern to each display instead of an index pointing to a stored pattern would maintain the natural error tolerance of data redundancy and would only require as much memory in the master as the number of unique characters (This is what I do when I switch the SmartNixie modules to display in 7-segment Numitron format instead of 1-of-10 nixie format).
> > Changing the GUI to match whatever you come up with will be trivial.
> John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes per digit)
I suppose that the master could monitor the output from the last slave to compare it to the original data for error detection since the RS232 is simplex: There is no way for a master to know whether a slave is happy with its data.
--- In firstname.lastname@example.org, "John" <jpt@...> wrote:
There is no way for a master to know whether a slave is happy with its data.
No there isn't, but the user will be able to tell if they are happy with the results or not.I'm not trying to be ignorant but this isn't a safety critical application.
The eeprom write command is unlike the other display commands because it is likely that the programmer will write them one at a time and test them immediately afterwards, noticing any details at that time.
Also, any data errors will show up as general bad performance and the unit not working very well, if at all.
The eeprom write command still uses the '$B7' header , which is still checked as it arrives, and if those characters are received intact the write command is allowed to proceed. If there are data errors then all the other commands like $B7E, $B7M, etc will be affected too and the user will deal with those problems in their usual manner.
I could add a simple XOR-ing checksum with very little trouble, if it is generally felt that data reliability is an area of concern, but my own experience leads me to believe that if you can send ordinary $B7M commands and the display works properly then there is nothing wrong with the data transmission.