Closed cmcgrath5035 closed 9 years ago
It's not a question of rate, it's a question of synchronous versus asynchronous. The Xmega silicon has a bug that it must disable all interrupts while EEPROM (or flash) writes occur. It takes about 20-30 ms to update a parameter in the EEPROM.
This means that if characters are being received while a writes are occurring the serial RX register can be overwritten and lose characters, So the best way to handle this is the treat parameter updates (i.e. anything requiring persistence) one-at-a-time. Send an update, then wait for a response before sending the next one. All persistence occurs before the response is sent.
Alternately, you can delay 30 - 50 ms or so between lines, but this is less reliable and ultimately slower. Parameters that are not changed from their persisted values are not written, so the responses are much faster than those that need to be written to EEPROM.
OK, very useful info. My planned strategy will be to parse a xxx.conf file, created from a $$ dump, one line at a time and send the one parameter, which may be adequate, or I'll implement the send and wait for response approach.
Does tinyG handle well a JSON command {"1":{"ma":0,"sa":1.800,"tr":36.540,"mi":8,"po":0,"pm":1}} ((grabbed this from a tgFX conf file)) Which might need to write 6 parameters, or should that approach be avoided? I assume it does, because the entire command it input before the write begin. I'll also assume it would be best to wait for a confirmation form this type of command in any case.
On 01/18/2015 05:44 PM, Alden Hart wrote:
It's not a question of rate, it's a question of synchronous versus asynchronous. The Xmega silicon has a bug that it must disable all interrupts while EEPROM (or flash) writes occur. It takes about 20-30 ms to update a parameter in the EEPROM.
This means that if characters are being received while a writes are occurring the serial RX register can be overwritten and lose characters, So the best way to handle this is the treat parameter updates (i.e. anything requiring persistence) one-at-a-time. Send an update, then wait for a response before sending the next one. All persistence occurs before the response is sent.
Alternately, you can delay 30 - 50 ms or so between lines, but this is less reliable and ultimately slower. Parameters that are not changed from their persisted values are not written, so the responses are much faster than those that need to be written to EEPROM.
— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/123#issuecomment-70430190.
Yes, it will handle {"1":{"ma":0,"sa":1.800,"tr":36.540,"mi":8,"po":0,"pm":1} as a single command with a single response. Wait for that response. This is an efficient way to do things.
You can also enter the command in relaxed JSON mode: {1:{ma:0,sa:1.800,tr:36.540,mi:8,po:0,pm:1}
see here: https://github.com/synthetos/TinyG/wiki/JSON-Operation#json-syntax-option---relaxed-or-strict
Thanks, should be all the info I was looking for, I'll close this issue
I'd recommend using JSON mode for all of it. Much easier in JavaScript than text mode.
I'll play with the JSON equivalent of $$ and give it a thought.
One overriding objective is human readability.. I stared at the config file a lot in the early days. JSON is, well, intimidating for most newcomers,, at least it was for me.
Perhaps I dump out both file.config and file.jconfig and auto detect content.....
On 01/19/2015 02:00 PM, Alden Hart wrote:
I'd recommend using JSON mode for all of it. Much easier in JavaScript than text mode.
— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/123#issuecomment-70543336.
Mike's comment(in issue 121) about EEPROM write delay prompts me to open this as a separate issue . I am fiddling with a fiddle widget enhancement over at CP to implement parameter backup and download , roughly following the scheme Riley implemented in tgFX. So do I have to be mindful of the rate at which I stream parameter updates to the Serial Port Console interface, or will normal buffer management and flow control manage the delivery and reliable setting of parameters? I certainly don't type that fast, so if you think I might be typing individual settings into the Serial Port Console too fast, I do think I need to worry about it. My objective is to provide at least a rudimentary capability such as tgFX did for tinyG, but more important a way to more easily manipulate tinyG2 parameters until persistent storage arrives. I plan to work in text , for example launch a $xjm=5000, but I believe SPJS will wrap that in JSON before it gets to tinyG anyway, just in case JSON vs text makes a difference.