Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 ROM code - Page 17 — Parallax Forums

Prop2 ROM code

11314151719

Comments

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    edited 2016-10-27 09:21
    jmg wrote: »
    cgracey wrote: »
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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.


  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    Here's the ROM code, if anyone wants to see it. I think it may actually be DONE!

  • jmgjmg Posts: 15,140
    edited 2016-10-27 09:34
    cgracey wrote: »
    At 20Mhz, it's taking only 15ms to load and start running your own signature-verified SPI program.

    What size is loaded in that 15ms ?
    cgracey wrote: »
    ... 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)

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    At 20Mhz, it's taking only 15ms to load and start running your own signature-verified SPI program.

    What size is loaded in that 15ms ?
    cgracey wrote: »
    ... 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?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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?
  • jmgjmg Posts: 15,140
    cgracey wrote: »

    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 ?

    cgracey wrote: »
    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.



  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »

    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.
    cgracey wrote: »
    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.

    Is "RI" receiver interrupt?
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.

  • cgraceycgracey Posts: 14,133
    So, there is need for reliability at all initial bit offsets.

    What do you recommend for an initial baud chr?
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Is "RI" receiver interrupt?

    Yes.
    cgracey wrote: »
    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".

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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'

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    Is "RI" receiver interrupt?

    Yes.
    cgracey wrote: »
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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.. ? ;)

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    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.


  • cgraceycgracey Posts: 14,133
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?

  • cgraceycgracey Posts: 14,133
    edited 2016-10-27 10:27
    jmg wrote: »
    cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    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.
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    My experience with concurrent download and SHA-256/HMAC was that 512Kbaud was the limit.
    ok, so that's roughly 50% of CPU cycles used for each of Serial and SHA.

    A thought here would be to use another COG for SHA :)

    cgracey wrote: »
    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 ?
  • cgraceycgracey Posts: 14,133
    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.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?
  • cgraceycgracey Posts: 14,133
    edited 2016-10-27 10:34
    jmg wrote: »
    cgracey wrote: »
    My experience with concurrent download and SHA-256/HMAC was that 512Kbaud was the limit.
    ok, so that's roughly 50% of CPU cycles used for each of Serial and SHA.

    A thought here would be to use another COG for SHA :)

    cgracey wrote: »
    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).
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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.

    No, we are good now. Sleep is a priority :)


  • jmgjmg Posts: 15,140
    cgracey wrote: »
    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 ?

Sign In or Register to comment.