Good eye. This could only blow up during initial autobaud, right?
Correct, it is a rare, but possible combination, only on the Raw Baud step.
One of my pencil tests is to consider the P2 coming out of reset in any bit-slot, and with any number of stop bits.
See my post above about repeating autobaud loops, where you would send a pair of chars.
The AutoBaud filter rejects the second char, and waits until the correct phase Raw Baud char.
Then, the second char passes into RX, and sets one/two pin modes, and echoes, allowing the host to sense exactly when
the P2 has come out of reset.
Once we sync, there's no possibility of alignment problems, assuming the baud rate doesn't change too fast.
Agreed. With 0x55 the baud rate can do a quite large step-up (>10x), but step downs need to be < -15.79% decrements to track.
There is absolutely going to be a need for coordinating a reset pulse with data sending. First, you'd pulse reset, then, after ~50ms, you would send data. This is how the Prop1 works, too. There should be no occasion for those two things to get jumbled up.
Jmg, here is the current code. Do you see any improvements possible here? It works just fine, but could maybe be faster.
1) I think there is just enough time, to AutoBaud from a single char, inside the first interrupt ? On ">" and maybe on "@"
ie by some code order shuffling like
' Autobaud Raw ISR - detects initial single AutoBaud Char "> "
' Another valid command may be right behind this, so timing matters to enable RX, do RX side asap
'
' falls |--7---|
' $3E -> ..10011111001..10000001001..
' highs |-5-|
'
autobaud_raw_isr rdpin a0,#rx_tne '2 get fall-to-fall time (7x if $3E)
rdpin a1,#rx_ths '2 get high time (5x if $3E)
cmpr a0,limit wc '2 make sure both measurements are within limit
if_nc cmpr a1,limit wc '2
scl a0,norm0 '2 if they are within 1/35th of each other, $3E
if_nc cmpr a1,0 wc '2
scl a1,norm1 '2
if_nc cmpr a0,0 wc '2
if_c reti1 '2/4 if not $3E, exit
' Passes Baud Char ratio tests, so extract time information, and apply to RX
mul a0,baud0 '2 compute baud rate
setbyte a0,#7,#0 '2 set word size to 8 bits
wxpin a0,#rx_rcv '2 set receiver baud rate and word size
dirh #rx_rcv '2 enable receiver before next start bit
' Rx done first, now can complete other housekeeping ~ 28 SysCLKs, to start RX engine
' budgets: 2.5 bits, at 1.75Mbd is 28.57 SysCLKs
' ">" edges have just under 3 or 4 bits of timing margin, for 1 or 2 Stop Bits.
wrpin mtpe,#rx_f5e '2 change rx_tne mode to measure 0x55 falling edges
' etc
mov t0,a0 '2 save baud rate for transmitter
reti1 '4 exit
RX setup gets pushed up earlier, as far as possible, and any Capture Mode changes can run after the RxPin is enabled.
ie This looks to have margin at your 1.75Mbd & ">" to do this in a single Char.
2) If you test for a valid ">" before applying AutoBaud-trim, that is a quite narrower catch range, as you must be inside valid-baud limits.
In contrast a 0x55 test needs only pass the Highest Frequency test, which can be something over 10%, so you can tolerate much longer pauses / drift.
I get ~15% minus Baud Tolerance, and no imposed limit on Baud Increased.
The code is very similar to what you have above, just a SmartPin cell mode change to X=5 edges-Time-capture.
Total flight time is less in re-trim, which matters as the RxINT may have been late
' Receiver ISR - detects maintenance "U" chrs, does not RxBuffer a "U"
'
' Falls 1 2 3 4 5
' $55 -> ..10101010101 Capture for 5 edges,
'
rdpin a0,#rx_tne '2 get X=5 Cycles time
wrpin ??,#?? '2 opcode to re-arm the next PinCell X=5 capture, < 5 will read 0, >= 5 is dT
cmp a0,MaintTrim wz '2 MaintTrim is time for 5 edges * ~90%, next slowest is > 20% longer
' branch here, nz is RX, z is update Baud
' Need prompt Baud update, as 0x55 can be followed by valid RX, and RI may be late due to drift. Use 2 Stop bits for highest Baud rates.
Rx:
rdpin a1,#rx_rcv wc '2 get received chr
shr a1,#32-8 '2 shift to lsb justify
...
wrlut a1,head '2 enter chr into receiver buffer
incmod head,#lut_btop '2 increment buffer head
reti1 '4 exit
.baud mul a0,baud0 '2 autobaud chr, compute baud rate, based on 5=\_ = 8b times
setbyte a0,#7,#0 '2 set word size to 8 bits
wxpin a0,#rx_rcv '2 set receiver baud rate and word size
mov t0,a0 '2 save baud rate for transmitter
reti1 '4 exit
Tightest times look to be on drift slower, so maybe a Smart Pin X=5 mode can interrupt, which only occurs on 0x55, as RxInt re-arms the counter. (all other possible chars are 4 or less, so no int).
This buys 1.5 more bit times for the detects maintenance case, as the baud INT is from last data bit fall, not mid-stop bit
ie, it then codes something like this, which looks smaller and even faster on Rx-chars
' Maint ISR - detects maintenance "U" chrs, does not RxBuffer a "U"
'
' Falls 1 2 3 4 5
' $55 -> ..10101010101 Capture for 5 edges,
'
Maint_ISR: ' At start of last Data bit, 1.5 bit times before Mid-Stop
rdpin a0,#rx_t5f '2 get X=5 Cycles time
' no value test needed as the 5 edges within RIs is enough, every RI re-arms the X=5 capture.
.baud mul a0,baud0 '2 autobaud chr, compute baud rate, based on 5x
setbyte a0,#7,#0 '2 set word size to 8 bits
wxpin a0,#rx_rcv '2 set receiver baud rate and word size << Re-Prime RX needs to be ASAP, for late RI cases.
mov t0,a0 '2 save baud rate for transmitter
reti1 '4 exit
' Receiver ISR - Mid Stop Bit , any 0x55 is trapped above, this code can purely receive.
Rx_ISR:
wrpin ??,#?? '2 opcode to re-arm the next PinCell X=5 capture, < 5 will read 0, >= 5 is dT
rdpin a1,#rx_rcv wc '2 get received chr
shr a1,#32-8 '2 shift to lsb justify
...
wrlut a1,head '2 enter chr into receiver buffer
incmod head,#lut_btop '2 increment buffer head
reti1 '4 exit
This also shifts the catch range, now, any step Up in Baud (down in SysCLK), is fine, as 0x55 occurs before RI int.
Drifts down in Baud (Up in SysCLK) need to react & reset before the Start bit, and may get a bit tangled if Maint_ISR and RI drift into the same time-space.
If Maint_ISR completes before RI, (and I guess, removes it, by reset of Rx state machine via new Baud) then it needs only that Maint_ISR enters first.
The margin for that is ~ +15.79% in SysCLK
Jmg,
I've tried getting rid of the need for a 2nd initial baud chr, but we actually run out of time. Here's why: The pin toggling has to get noticed by the smart pin (2 clocks), after which it raises IN (2 clocks to cog), and then goes through the SE1 logic (2 clocks), after which an interrupt will be generated that needs an agreeable slot (no AUGS, ALTx, etc), that CALLD takes 4 clocks after a possible 1..3 clock wait, then you are in the ISR. Maybe 13 clocks have elapsed, already, beforehand.
I'd like to keep the autobaud scheme as it exists, now, because it's easy to explain and doesn't make strange use of any common characters.
Right now, I've got it running at 1.5Mbaud at 13.333MHz, which is a worst-case RC osc frequency. At 20MHz, it can handle 2Mbaud with some good margin. I think what I'll do is see about tweaking the RC osc design so that it always goes at least 20MHz, at worst process/voltage/temperature. If we can rely on 20MHz, we can always use 2Mbaud.
Anyway, this is now running over 10x faster than it was a few weeks ago, thanks to all your input, really. At 20Mhz, it's taking only 15ms to load and start running your own signature-verified SPI program. I'll need to see what the reset timer looks like on the test chip, but these times are WAY down from what they were, originally.
There is absolutely going to be a need for coordinating a reset pulse with data sending. First, you'd pulse reset, then, after ~50ms, you would send data. This is how the Prop1 works, too. There should be no occasion for those two things to get jumbled up.
I'm not sure Id use the wording 'jumbled up' - Data send always follows reset, the issue is around how quickly.
To get fastest possible boot, the host (which can be a Local MCU, in one-pin mode) ideally needs to know exactly when the P2 is ready.
With POR reset caps, the tolerances are large, and the delay variances are significant.
Many users will not know how to calculate the margins needed, where cheap caps vary with voltage and temperature.
Some LVD/reset generator parts stretch the reset pulse, giving more variance.
Smarter to have a design that can eliminate such guesses - you get reliable, portable One-Pin-MCU code.
The local MCU can do that, with a simple repeat AutoBaud-Raw, and Enquire/ModeSet character.
The current ROM can tolerate a Reset exit at any phase in the AutoBaud RAW char, and also the Enquire Chars, so you can know a proper Baud decision is made.
There is absolutely going to be a need for coordinating a reset pulse with data sending. First, you'd pulse reset, then, after ~50ms, you would send data. This is how the Prop1 works, too. There should be no occasion for those two things to get jumbled up.
I'm not sure Id use the wording 'jumbled up' - Data send always follows reset, the issue is around how quickly.
To get fastest possible boot, the host (which can be a Local MCU, in one-pin mode) ideally needs to know exactly when the P2 is ready.
With POR reset caps, the tolerances are large, and the delay variances are significant.
Many users will not know how to calculate the margins needed, where cheap caps vary with voltage and temperature.
Some LVD/reset generator parts stretch the reset pulse, giving more variance.
Smarter to have a design that can eliminate such guesses - you get reliable, portable One-Pin-MCU code.
The local MCU can do that, with a simple repeat AutoBaud-Raw, and Enquire/ModeSet character.
The current ROM can tolerate a Reset exit at any phase in the AutoBaud RAW char, and also the Enquire Chars, so you can know a proper Baud decision is made.
What if the one-pin host surrounds the ">" with $00 or $FF bytes so that the possibility of a false autobaud is eliminated? Would that work? This type of one-pin-ASAP scenario may need slightly different managing on the host side.
... and doesn't make strange use of any common characters.
I'm not following that comment ? Using 0x55 or "U" for AutoBaud is not a 'strange use', it is quite a common practice.
The reason is that single character has a unique digital signature, that is easy to detect, especially in a system that needs only to trim.
A SmartPin cell can detect this signature, and give a much wider correction range than present Rx-Based check.
On top of that benefit, it slashes the time, by moving Auto-trim outside the Rx interrupt - it can run only when actually needed.
That's more cycles for the SHA.
My MCU loader skips the "U" quite easily in the Base64 encode, and uses less tests (ie faster) that the original base64.
Here is the improved Base64 - a simpler "0" to "9" then "A" to "w" with "U" skipped.
EncP2_xU:
ANL A,#03FH ;strip > 0x3f
ADD A,#255-("9"-"0") ;
JNC _Le_9
ADD A,#255-("T"-"A") ;0 need to be "A"
JNC _Le_30 ; now 255 is "T"
INC A ; fix for nett "V" (skip U)
_Le_30:
ADD A,#0x1B ;fix for nett "A"
_Le_9:
ADD A,#"0"+10 ;0..9 -> "0".."9"
RET
Size_EncP2_xU EQU $-EncP2_xU ; 0x10 = 15 bytes minus RET
The original base64, (P2 web docs) needs 30 bytes, and cannot in-line. (so costs more in bytes and cycles)
... and doesn't make strange use of any common characters.
I'm not following that comment ? Using 0x55 or "U" for AutoBaud is not a 'strange use', it is quite a common practice.
The reason is that single character has a unique digital signature, that is easy to detect, especially in a system that needs only to trim.
A SmartPin cell can detect this signature, and give a much wider correction range than present Rx-Based check.
On top of that benefit, it slashes the time, by moving Auto-trim outside the Rx interrupt - it can run only when actually needed.
That's more cycles for the SHA.
My MCU loader skips the "U" quite easily in the Base64 encode, and uses less tests (ie faster) that the original base64.
In 15ms, an $F8-long program with an 8-long signature is loaded and verified.
I'm not understanding how "U" ($55 --> ..10101010101..) can be reliably recognized as a baud character. Do we look for H/L symmetry over a 5-rise (or fall, or both) period?
What if the one-pin host surrounds the ">" with $00 or $FF bytes so that the possibility of a false autobaud is eliminated? Would that work? This type of one-pin-ASAP scenario may need slightly different managing on the host side.
A one-Pin MCU has no problems avoiding a false autobaud.
I was thinking more of other larger systems, where users actually have no idea what inter-character spaces are being inserted.
At these higher baud speeds ( > 1MBd) it is common for some USB-UARTS to add extra stop bits
What if the one-pin host surrounds the ">" with $00 or $FF bytes so that the possibility of a false autobaud is eliminated? Would that work? This type of one-pin-ASAP scenario may need slightly different managing on the host side.
A one-Pin MCU has no problems avoiding a false autobaud.
I was thinking more of other larger systems, where users actually have no idea what inter-character spaces are being inserted.
At these higher baud speeds ( > 1MBd) it is common for some USB-UARTS to add extra stop bits
But if a 50ms wait is done before sending data, there would be no problem, right?
I'm not understanding how "U" ($55 --> ..10101010101..) can be reliably recognized as a baud character.
Do we look for H/L symmetry over a 5-rise (or fall, or both) period?
You use the Smart Pin x-periods timer mode, set for 5 periods.
This acts like a simple monostable in use
It is re-armed in the RI timeslot, and will Capture interrupt only when 5 edges occur before the next RI.
The capture reads the TIME of those 5 =\_ edges, to get good 8B precision.
There is only one single character that can meet that - the 0x55.
This is ideally suited to trim use, as the RI gives the frame info.
But if a 50ms wait is done before sending data, there would be no problem, right?
Where does 50ms come from ?
If a user has a reset pin that has a Voltage-reset generator (a common design) that will often stretch the reset pulse. Some use 160ms, it varies.
Other users use a larger CAP + Reset Pullup, to time their reset, Lots of variations again.
A Host pulsed Cap + transistor (as in P1) only tells you the start of reset, not when reset was finished.
In 15ms, an $F8-long program with an 8-long signature is loaded and verified.
Is that Base64, 2 stop bits ?
That suggests
(((0xF8*32+8*32)*11/8)/15m)*4/3 = 1.001244MBd, for Base64 (ignoring the preambles) - is that right ?
That 15ms is how long it takes to read the SPI flash and verify the signature. This happens before serial, of course. I was just pointing out that boot will be fast.
I'm not understanding how "U" ($55 --> ..10101010101..) can be reliably recognized as a baud character.
Do we look for H/L symmetry over a 5-rise (or fall, or both) period?
You use the Smart Pin x-periods timer mode, set for 5 periods.
This acts like a simple monostable in use
It is re-armed in the RI timeslot, and will Capture interrupt only when 5 edges occur before the next RI.
The capture reads the TIME of those 5 =\_ edges, to get good 8B precision.
There is only one single character that can meet that - the 0x55.
This is ideally suited to trim use, as the RI gives the frame info.
But if a 50ms wait is done before sending data, there would be no problem, right?
Where does 50ms come from ?
If a user has a reset pin that has a Voltage-reset generator (a common design) that will often stretch the reset pulse. Some use 160ms, it varies.
Other users use a larger CAP + Reset Pullup, to time their reset, Lots of variations again.
A Host pulsed Cap + transistor (as in P1) only tells you the start of reset, not when reset was finished.
I see what you are getting at now.
The Prop1 never worried about this, as it was assumed the RESn was not loaded with caps, or anything. Our rising edge was the boss.
That 15ms is how long it takes to read the SPI flash and verify the signature. This happens before serial, of course. I was just pointing out that boot will be fast.
Ah, ok
I'm trying to get a handle on the SHA time, as that will impose another ceiling on this.
Baud cannot go above the AutoBaud limit, which is now nice and high, but it also needs to be not too fast for SHA.
If SPI loading infers a SHA equivalent baud-rate of ~1.001244MBd (base64), the 2MBd will only be relevant for "HEX with spaces".
So, there is need for reliability at all initial bit offsets.
What do you recommend for an initial baud chr?
">" is tolerable, but "0", which is the tLL mirror, is more robust & tolerant of those nasty 'unknown variances' that can bite.
"0" has the exact same code, just a different tLL configure, instead of the tHH used for ">"
That does consume "0" in the base64 set, but in my case, that merely 'moves the table up one', so it stops at 'v' instead of 'w'
That 15ms is how long it takes to read the SPI flash and verify the signature. This happens before serial, of course. I was just pointing out that boot will be fast.
Ah, ok
I'm trying to get a handle on the SHA time, as that will impose another ceiling on this.
Baud cannot go above the AutoBaud limit, which is now nice and high, but it also needs to be not too fast for SHA.
If SPI loading infers a SHA equivalent baud-rate of ~1.001244MBd (base64), the 2MBd will only be relevant for "HEX with spaces".
What is "SHA"?
It's working for both Prop_Hex and Prop_Txt at 2MB.
Oh, wait... SHA-256 is "SHA". I do that AFTER the download, now, as it was a huge speed limiter.
Oh, wait... SHA-256 is "SHA". I do that AFTER the download, now, as it was a huge speed limiter.
Ahh.. I missed that change. I thought you were still doing it concurrently. Hence my focus on driving cycles out of RI code area, as that would buy SHA speed. If it is done later, the P2 merely spends longer doing nothing but wait during download...
Surely, doing it after can actually take longer overall, and it is the total time to start that matters here ?
Or, are you taking a page from Microsoft, and giving the illusion of speed with fast downloads, but actual user action, is longer.. ?
Oh, wait... SHA-256 is "SHA". I do that AFTER the download, now, as it was a huge speed limiter.
Ahh.. I missed that change. I thought you were still doing it concurrently. Hence my focus on driving cycles out of RI code area, as that would buy SHA speed. If it is done later, the P2 merely spends longer doing nothing but wait during download...
Surely, doing it after can actually take longer overall, and it is the total time to start that matters here ?
Or, are you taking a page from Microsoft, and giving the illusion of speed with fast downloads, but actual user action, is longer.. ?
The SHA-256/HMAC runs at 100KB/s, so a 512KB download would finish and then 5 seconds later, your program would run if everything was okay. This is only for signed downloads, anyway.
But if a 50ms wait is done before sending data, there would be no problem, right?
Where does 50ms come from ?
If a user has a reset pin that has a Voltage-reset generator (a common design) that will often stretch the reset pulse. Some use 160ms, it varies.
Other users use a larger CAP + Reset Pullup, to time their reset, Lots of variations again.
A Host pulsed Cap + transistor (as in P1) only tells you the start of reset, not when reset was finished.
I see what you are getting at now.
The Prop1 never worried about this, as it was assumed the RESn was not loaded with caps, or anything. Our rising edge was the boss.
In my MCU-Booter code, I repeat an AutoBaud-Raw character (can of course be any chosen value) and one other character (1 of 2) to check for awake. This tolerates widely variable reset delays, and needs much less explaining to users.
To support both One-pin and two pin modes, I assume that 1 of 2 character sets-pin-mode and elicits an echo.
Before looking for an echo, you first need to set Pin mode, so it makes sense to combine those operations for simplicity.
Not sure if your code does that yet ?
I've looked at "-" and "=" and "'" and "|" - the former are graphically nice, but they do push the edge-rate up, so technically are not as ideal.
My experience with concurrent download and SHA-256/HMAC was that 512Kbaud was the limit. Certainly during development, people are not going to want the time penalty associated with signing. You can go 4x faster without it.
The SHA-256/HMAC runs at 100KB/s, so a 512KB download would finish and then 5 seconds later, your program would run if everything was okay. This is only for signed downloads, anyway.
I thought all downloads had to be signed ? (even if 0), or is that optional, and faster SHA-Skip is possible ?
But if a 50ms wait is done before sending data, there would be no problem, right?
Where does 50ms come from ?
If a user has a reset pin that has a Voltage-reset generator (a common design) that will often stretch the reset pulse. Some use 160ms, it varies.
Other users use a larger CAP + Reset Pullup, to time their reset, Lots of variations again.
A Host pulsed Cap + transistor (as in P1) only tells you the start of reset, not when reset was finished.
I see what you are getting at now.
The Prop1 never worried about this, as it was assumed the RESn was not loaded with caps, or anything. Our rising edge was the boss.
In my MCU-Booter code, I repeat an AutoBaud-Raw character (can of course be any chosen value) and one other character (1 of 2) to check for awake. This tolerates widely variable reset delays, and needs much less explaining to users.
To support both One-pin and two pin modes, I assume that 1 of 2 character sets-pin-mode and elicits an echo.
Before looking for an echo, you first need to set Pin mode, so it makes sense to combine those operations for simplicity.
Not sure if your code does that yet ?
I've looked at "-" and "=" and "'" and "|" - the former are graphically nice, but they do push the edge-rate up, so technically are not as ideal.
There is no response until a chip is addressed through the proper INA/INB filters. This is necessary to allow multiple chips to share a set of serial lines. So, before you can get a response, you must do the Prop_Chk command, since it allows another command afterwards.
The SHA-256/HMAC runs at 100KB/s, so a 512KB download would finish and then 5 seconds later, your program would run if everything was okay. This is only for signed downloads, anyway.
I thought all downloads had to be signed ? (even if 0), or is that optional, and faster SHA-Skip is possible ?
It's necessary if the chip is keyed, but if the key is 0, you can sign your download, or not.
Certainly during development, people are not going to want the time penalty associated with signing. You can go 4x faster without it.
More Speed is always nice
- but I thought one driver behind my assuming it was SHA-always, was better security ?
ie If it can never be disabled, it cannot be spoofed ?
I've got to go to bed now, since I need to be up in the morning - just so you don't wonder why my messaging stopped. I'll be here for another five minutes, though, in case you want to write anything quickly.
There is no response until a chip is addressed through the proper INA/INB filters. This is necessary to allow multiple chips to share a set of serial lines. So, before you can get a response, you must do the Prop_Chk command, since it allows another command afterwards.
ok - So what is the smallest, repeating string(s) that needs to be sent, to AutoBaud-Raw, and then confirm P2 is out of reset, via a response in 1 or 2 pin modes ?
Certainly during development, people are not going to want the time penalty associated with signing. You can go 4x faster without it.
More Speed is always nice
- but I thought one driver behind my assuming it was SHA-always, was better security ?
ie If it can never be disabled, it cannot be spoofed ?
Another cog, yes, but we've got people using DE0-Nano's and BeMicro boards that only fit one cog, so I've made do with one cog for the loader. Plus, it leaves the door open to single-cog chip implementations. (I know, no point)
SHA is always required IF they chip is keyed (non-0 key value in its fuses). Then, you'd better know what that key is because the chip won't accept any unsigned downloads (or unsigned SPI code).
I've got to go to bed now, since I need to be up in the morning - just so you don't wonder why my messaging stopped. I'll be here for another five minutes, though, in case you want to write anything quickly.
Another cog, yes, but we've got people using DE0-Nano's and BeMicro boards that only fit one cog, so I've made do with one cog for the loader. Plus, it leaves the door open to single-cog chip implementations. (I know, no point)
Could perhaps the loader be smart enough to use 2, if >= 2 exist and 1 if only 1 exists ?
Comments
There is absolutely going to be a need for coordinating a reset pulse with data sending. First, you'd pulse reset, then, after ~50ms, you would send data. This is how the Prop1 works, too. There should be no occasion for those two things to get jumbled up.
Jmg,
I've tried getting rid of the need for a 2nd initial baud chr, but we actually run out of time. Here's why: The pin toggling has to get noticed by the smart pin (2 clocks), after which it raises IN (2 clocks to cog), and then goes through the SE1 logic (2 clocks), after which an interrupt will be generated that needs an agreeable slot (no AUGS, ALTx, etc), that CALLD takes 4 clocks after a possible 1..3 clock wait, then you are in the ISR. Maybe 13 clocks have elapsed, already, beforehand.
I'd like to keep the autobaud scheme as it exists, now, because it's easy to explain and doesn't make strange use of any common characters.
Right now, I've got it running at 1.5Mbaud at 13.333MHz, which is a worst-case RC osc frequency. At 20MHz, it can handle 2Mbaud with some good margin. I think what I'll do is see about tweaking the RC osc design so that it always goes at least 20MHz, at worst process/voltage/temperature. If we can rely on 20MHz, we can always use 2Mbaud.
Anyway, this is now running over 10x faster than it was a few weeks ago, thanks to all your input, really. At 20Mhz, it's taking only 15ms to load and start running your own signature-verified SPI program. I'll need to see what the reset timer looks like on the test chip, but these times are WAY down from what they were, originally.
I'm not sure Id use the wording 'jumbled up' - Data send always follows reset, the issue is around how quickly.
To get fastest possible boot, the host (which can be a Local MCU, in one-pin mode) ideally needs to know exactly when the P2 is ready.
With POR reset caps, the tolerances are large, and the delay variances are significant.
Many users will not know how to calculate the margins needed, where cheap caps vary with voltage and temperature.
Some LVD/reset generator parts stretch the reset pulse, giving more variance.
Smarter to have a design that can eliminate such guesses - you get reliable, portable One-Pin-MCU code.
The local MCU can do that, with a simple repeat AutoBaud-Raw, and Enquire/ModeSet character.
The current ROM can tolerate a Reset exit at any phase in the AutoBaud RAW char, and also the Enquire Chars, so you can know a proper Baud decision is made.
What if the one-pin host surrounds the ">" with $00 or $FF bytes so that the possibility of a false autobaud is eliminated? Would that work? This type of one-pin-ASAP scenario may need slightly different managing on the host side.
What size is loaded in that 15ms ?
I'm not following that comment ? Using 0x55 or "U" for AutoBaud is not a 'strange use', it is quite a common practice.
The reason is that single character has a unique digital signature, that is easy to detect, especially in a system that needs only to trim.
A SmartPin cell can detect this signature, and give a much wider correction range than present Rx-Based check.
On top of that benefit, it slashes the time, by moving Auto-trim outside the Rx interrupt - it can run only when actually needed.
That's more cycles for the SHA.
My MCU loader skips the "U" quite easily in the Base64 encode, and uses less tests (ie faster) that the original base64.
Here is the improved Base64 - a simpler "0" to "9" then "A" to "w" with "U" skipped.
EncP2_xU: ANL A,#03FH ;strip > 0x3f ADD A,#255-("9"-"0") ; JNC _Le_9 ADD A,#255-("T"-"A") ;0 need to be "A" JNC _Le_30 ; now 255 is "T" INC A ; fix for nett "V" (skip U) _Le_30: ADD A,#0x1B ;fix for nett "A" _Le_9: ADD A,#"0"+10 ;0..9 -> "0".."9" RET Size_EncP2_xU EQU $-EncP2_xU ; 0x10 = 15 bytes minus RETThe original base64, (P2 web docs) needs 30 bytes, and cannot in-line. (so costs more in bytes and cycles)In 15ms, an $F8-long program with an 8-long signature is loaded and verified.
I'm not understanding how "U" ($55 --> ..10101010101..) can be reliably recognized as a baud character. Do we look for H/L symmetry over a 5-rise (or fall, or both) period?
A one-Pin MCU has no problems avoiding a false autobaud.
I was thinking more of other larger systems, where users actually have no idea what inter-character spaces are being inserted.
At these higher baud speeds ( > 1MBd) it is common for some USB-UARTS to add extra stop bits
But if a 50ms wait is done before sending data, there would be no problem, right?
That suggests
(((0xF8*32+8*32)*11/8)/15m)*4/3 = 1.001244MBd, for Base64 (ignoring the preambles) - is that right ?
You use the Smart Pin x-periods timer mode, set for 5 periods.
This acts like a simple monostable in use
It is re-armed in the RI timeslot, and will Capture interrupt only when 5 edges occur before the next RI.
The capture reads the TIME of those 5 =\_ edges, to get good 8B precision.
There is only one single character that can meet that - the 0x55.
This is ideally suited to trim use, as the RI gives the frame info.
If a user has a reset pin that has a Voltage-reset generator (a common design) that will often stretch the reset pulse. Some use 160ms, it varies.
Other users use a larger CAP + Reset Pullup, to time their reset, Lots of variations again.
A Host pulsed Cap + transistor (as in P1) only tells you the start of reset, not when reset was finished.
That 15ms is how long it takes to read the SPI flash and verify the signature. This happens before serial, of course. I was just pointing out that boot will be fast.
Is "RI" receiver interrupt?
I see what you are getting at now.
The Prop1 never worried about this, as it was assumed the RESn was not loaded with caps, or anything. Our rising edge was the boss.
What do you recommend for an initial baud chr?
Yes.
Ah, ok
I'm trying to get a handle on the SHA time, as that will impose another ceiling on this.
Baud cannot go above the AutoBaud limit, which is now nice and high, but it also needs to be not too fast for SHA.
If SPI loading infers a SHA equivalent baud-rate of ~1.001244MBd (base64), the 2MBd will only be relevant for "HEX with spaces".
"0" has the exact same code, just a different tLL configure, instead of the tHH used for ">"
That does consume "0" in the base64 set, but in my case, that merely 'moves the table up one', so it stops at 'v' instead of 'w'
What is "SHA"?
It's working for both Prop_Hex and Prop_Txt at 2MB.
Oh, wait... SHA-256 is "SHA". I do that AFTER the download, now, as it was a huge speed limiter.
Surely, doing it after can actually take longer overall, and it is the total time to start that matters here ?
Or, are you taking a page from Microsoft, and giving the illusion of speed with fast downloads, but actual user action, is longer.. ?
The SHA-256/HMAC runs at 100KB/s, so a 512KB download would finish and then 5 seconds later, your program would run if everything was okay. This is only for signed downloads, anyway.
In my MCU-Booter code, I repeat an AutoBaud-Raw character (can of course be any chosen value) and one other character (1 of 2) to check for awake. This tolerates widely variable reset delays, and needs much less explaining to users.
To support both One-pin and two pin modes, I assume that 1 of 2 character sets-pin-mode and elicits an echo.
Before looking for an echo, you first need to set Pin mode, so it makes sense to combine those operations for simplicity.
Not sure if your code does that yet ?
I've looked at "-" and "=" and "'" and "|" - the former are graphically nice, but they do push the edge-rate up, so technically are not as ideal.
I thought all downloads had to be signed ? (even if 0), or is that optional, and faster SHA-Skip is possible ?
There is no response until a chip is addressed through the proper INA/INB filters. This is necessary to allow multiple chips to share a set of serial lines. So, before you can get a response, you must do the Prop_Chk command, since it allows another command afterwards.
It's necessary if the chip is keyed, but if the key is 0, you can sign your download, or not.
A thought here would be to use another COG for SHA
More Speed is always nice
- but I thought one driver behind my assuming it was SHA-always, was better security ?
ie If it can never be disabled, it cannot be spoofed ?
ok - So what is the smallest, repeating string(s) that needs to be sent, to AutoBaud-Raw, and then confirm P2 is out of reset, via a response in 1 or 2 pin modes ?
Another cog, yes, but we've got people using DE0-Nano's and BeMicro boards that only fit one cog, so I've made do with one cog for the loader. Plus, it leaves the door open to single-cog chip implementations. (I know, no point)
SHA is always required IF they chip is keyed (non-0 key value in its fuses). Then, you'd better know what that key is because the chip won't accept any unsigned downloads (or unsigned SPI code).
No, we are good now. Sleep is a priority