That means you can match a FT232H/F2232H which do 12MBd and down in Async, with P2 SysCLK of 36 or 48MHz (and also support 60MHz, 72MHz, 84MHz, 96MHz ..)
Some SPI parts allows SysCLK/2 in master mode ?
Is there some reason /2 cannot be supported in Sync, Master ?
RaspPi speeds are somewhat vague and a moving target.
I've found mention of UART 32MBd max, but also mentions that 4MBd is not continual for Txmit via OS.
That suggests small burst speeds above 4MHz could be ok, if you match with the FIFO sizes.
There seems to be a typo in the data, that then morphed into someone's code and finally someone else actually tested it, and found they meant /2N not 2^N.....
Last post suggests this fix was applied ~Aug 2015
I think that gives
SPI Baud = 250MHz/2N , N >= 1
/2 for 125MHz may be notional, given tsu, th, but /4?, /6, /8, /10, /12, /14, /16 .. etc would be useful.
* For the sync and async modes, I see that WSWORD is used to set baud rate. Is this internally scaled, or are we limited to 64K baud?
* For the async modes, are they hardwired to "no parity" and "1 stop bit"?
* For the sync modes, do you need to set baud for RX modes?
* For the sync and async modes, I see that WSWORD is used to set baud rate. Is this internally scaled, or are we limited to 64K baud?
* For the async modes, are they hardwired to "no parity" and "1 stop bit"?
* For the sync modes, do you need to set baud for RX modes?
Good questions.
I think Baud is a divider, so the limit is from /3 to /2^16, and yes that will impose a baud limit, but a lower limit of 1220 Baud at 80MHz (assuming no prescaler).
That may be an issue, but someone could use interrupts for very low baud needs ?
Legacy UARTS can manage 5,6,7,8,9 Data and 1,1.5,2 stop bits and parity choices.
Some of those may seem rare, but MCUs do still support them, so the P2 needs to as well.
With a field for Data length (1..32? ) you can cover many of those, leaving just parity.
There are also UART Error flags to manage, not mentioned yet, and many UARTS have FIFOs that are 12b wide so every RxByte has the error tags applied per-incoming-byte.
Sync is going to be more naturally Master or Slave in SPI uses, and MCUs often spec /2 on SPI Master mode, and some have /4 or /10, or somewhere in between, lower limit on Slave mode.
RaspPi (on paper) can support from 125MHz down in the SPI divider. (250MHz/2N)
* For the sync and async modes, I see that WSWORD is used to set baud rate. Is this internally scaled, or are we limited to 64K baud?
* For the async modes, are they hardwired to "no parity" and "1 stop bit"?
* For the sync modes, do you need to set baud for RX modes?
Good questions.
I think Baud is a divider, so the limit is from /3 to /2^16, and yes that will impose a baud limit, but a lower limit of 1220 Baud at 80MHz (assuming no prescaler).
That may be an issue, but someone could use interrupts for very low baud needs ?
Legacy UARTS can manage 5,6,7,8,9 Data and 1,1.5,2 stop bits and parity choices.
Some of those may seem rare, but MCUs do still support them, so the P2 needs to as well.
With a field for Data length (1..32? ) you can cover many of those, leaving just parity.
There are also UART Error flags to manage, not mentioned yet, and many UARTS have FIFOs that are 12b wide so every RxByte has the error tags applied per-incoming-byte.
Sync is going to be more naturally Master or Slave in SPI uses, and MCUs often spec /2 on SPI Master mode, and some have /4 or /10, or somewhere in between, lower limit on Slave mode.
RaspPi (on paper) can support from 125MHz down in the SPI divider. (250MHz/2N)
I don't want to implement low-level error detection. I don't think that's the place for it. It's better done at a higher level in software via checksums and such, where a macro response can be made, instead of needing to deal with low-level errors which complicate things that need to be most efficient.
I don't want to implement low-level error detection. I don't think that's the place for it. It's better done at a higher level in software via checksums and such, where a macro response can be made, instead of needing to deal with low-level errors which complicate things that need to be most efficient.
Of course, but many systems are already designed, and some would consider
Slower baud rates can be done via bit-banging as can anything that does not fit the basics.
Err actually no - Slower Baud rates I agree with, and have already mentioned, but for other features, it is easy to say "can be done via bit-banging", but you cannot implement low level stuff in SW, without taking a massive speed or power penalty.
That's the whole point of adding this serial HW in the first place! - to reach places where that old "can be done via bit-banging" fails.
Parity is just another bit, there is already settable number of bits, so no biggie there.
Reading up on break detect it seems this is a stream of continuous START bits - the opposite of the normal pause gap - which is a continuous stream of STOP bits. I've never heard of it being intentionally used but something probably should indicate this break condition anyway. I imagine an unplugged cable looks like a break condition, hence the name I guess.
Break was used many moons ago, for precisely its name - to break out of a loop of code.
But again, not that important as we can check for it.
For instance, if we can set the number of bits, then we can just check the value passed. Provided we can stream the bits, including start and stop bits, we can test for all sorts of errors/parity/etc.
That is what general purpose means - we can basically do in software any setting/checking provided we can stream a number of bits in/out. The hardware is just providing the mechanism to stream the bits into bytes/words/etc and we do the protocol/error (byte, parity, or whatever) on the byte+ basis where we have more time to do it.
That is what general purpose means - we can basically do in software any setting/checking provided we can stream a number of bits in/out. The hardware is just providing the mechanism to stream the bits into bytes/words/etc and we do the protocol/error (byte, parity, or whatever) on the byte+ basis where we have more time to do it.
Yup, I am all for HW doing the bit level stuff, and SW doing slower stuff, but note your SW layer here, relies on having that bit passed from the hardware layer, or it fails to work, which proves my point.
ergo, the HW itself, must provide enough support to collect that Stop/Break bit.
I don't think it is necessary to support all these different modes even if some MCUs do that does not dictate what is actually required and used. 9-bit addressing mode is useful but easily handled at the software level.
I'd like to see I2C start and start conditions detected though.
Break detection has nothing to do with line breaks but the equivalent at the UART level is seeing an active low that persists which is easily detected as receiving multiple nulls with framing errors as there are no stop bits. However the thing is I use break as it is baud-rate independent to gain attention, usually to reset the system even if the application isn't listening to serial (built into the driver). So I use it with my Tachyon console in case my code fails to return back to the console etc but also in RS485 and other networked systems as a way of resetting remote devices. It's a really useful feature to have at the hardware level and easy to implement. Please include it. I just count multiple frame-error nulls as a break which is more than good enough.
I'd like to see I2C start and start conditions detected though.
Yes, i2c Start and Stop are useful, but if doing those, it would be natural to include clock-stretch ability too.
Logic for all 3 is very simple.
I've seen some low end MCUs manage Bytes in Sync mode, and ACK / Start / Stop in SW.
So, keeping things at 8N1 and 32N1 for the moment, could the C or Z flag be set to the sampled value for the stop bit? Since the pins pass data back over a 3-bit channel, this will conveniently work for both 8N1 and 32N1 with no increase in clock cycles. It's not a lot, but it will make it easy to catch the common issues (framing error and break).
Chip, do you have an idea of how much logic/flops that first pass took?
I'm implementing it now, trying to nail down how many flops each function requires, so that I can make a common set of flops to do it all. This is to cut back on clocking power, mainly.
So, keeping things at 8N1 and 32N1 for the moment, could the C or Z flag be set to the sampled value for the stop bit? Since the pins pass data back over a 3-bit channel, this will conveniently work for both 8N1 and 32N1 with no increase in clock cycles. It's not a lot, but it will make it easy to catch the common issues (framing error and break).
That's a good idea. I'll see when we get there. Please remind me later if you don't see anything.
So, keeping things at 8N1 and 32N1 for the moment, could the C or Z flag be set to the sampled value for the stop bit?
Good idea, using both would allow BYTE level Data operations, and the flags would capture extra bits, like this :
AP = Address/Parity bit, = 9th bit on 8b UART models -> C bit
SV = Stop Bit value, sampled mid-stop. -> Z bit (Framing error/ break)
Control field would be [BitOrder][AP_Enable][Length4:0]
(BitOrder covers SPI or UART bit order, MSB or LSB first. AP is always just before STOP bit.)
When AP_Enable is set, the C bit carries the Length+1 value, in both directions.
Z could always reflect Stop Bit Rx value ?
For Break Tx, is that best done via Length ?
eg For the LIN example mentioned, that would be something like a length of 22b, and a single value of
0x002AA000, to send both the Break and Sync fields.
After that completes, normal 8b Length is used.
BYTE transfers can support Address/Parity, and that applies to all sizes, meaning 32b sends could append a 33rd AP bit.
So, keeping things at 8N1 and 32N1 for the moment, could the C or Z flag be set to the sampled value for the stop bit?
Good idea, using both would allow BYTE level Data operations, and the flags would capture extra bits, like this :
AP = Address/Parity bit, = 9th bit on 8b UART models -> C bit
SV = Stop Bit value, sampled mid-stop. -> Z bit (Framing error/ break)
Control field would be [BitOrder][AP_Enable][Length4:0]
(BitOrder covers SPI or UART bit order, MSB or LSB first. AP is always just before STOP bit.)
When AP_Enable is set, the C bit carries the Length+1 value, in both directions.
Z could always reflect Stop Bit Rx value ?
For Break Tx, is that best done via Length ?
eg For the LIN example mentioned, that would be something like a length of 22b, and a single value of
0x002AA000, to send both the Break and Sync fields.
After that completes, normal 8b Length is used.
BYTE transfers can support Address/Parity, and that applies to all sizes, meaning 32b sends could append a 33rd AP bit.
The only issue I see is that this would increase the read time, as now you've pushed into the next 3-bit block. I'm guessing this would increase RSxxxx by only 1 clock cycle, though. It may be worth the trade-off.
The only issue I see is that this would increase the read time, as now you've pushed into the next 3-bit block. I'm guessing this would increase RSxxxx by only 1 clock cycle, though. It may be worth the trade-off.
True, but the min Baud divisor is /3 (practical is more like /6) so there will be 30/33/60/66 sysclks to move the byte at the highest possible Baud speeds.
In theory a transport bottleneck could occur at lowest bit settings, but even there considering a DualSPI/JTAG send of TMS.TDO is usually actually a small set of bits-pairs, and with a full Length control, would send as a set, not one-pair-at-a-time.
Comments
number of clocks per bit. Valid bauds start at 3.
Fbd = SysCLK/N, N >= 3
It is good to avoid any /16 these days.
That means you can match a FT232H/F2232H which do 12MBd and down in Async, with P2 SysCLK of 36 or 48MHz (and also support 60MHz, 72MHz, 84MHz, 96MHz ..)
Some SPI parts allows SysCLK/2 in master mode ?
Is there some reason /2 cannot be supported in Sync, Master ?
RaspPi speeds are somewhat vague and a moving target.
I've found mention of UART 32MBd max, but also mentions that 4MBd is not continual for Txmit via OS.
That suggests small burst speeds above 4MHz could be ok, if you match with the FIFO sizes.
https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=43442&p=347073
There seems to be a typo in the data, that then morphed into someone's code and finally someone else actually tested it, and found they meant /2N not 2^N.....
Last post suggests this fix was applied ~Aug 2015
I think that gives
SPI Baud = 250MHz/2N , N >= 1
/2 for 125MHz may be notional, given tsu, th, but /4?, /6, /8, /10, /12, /14, /16 .. etc would be useful.
It's on the first page of this thread.
Doh! Thanks...
* For the sync and async modes, I see that WSWORD is used to set baud rate. Is this internally scaled, or are we limited to 64K baud?
* For the async modes, are they hardwired to "no parity" and "1 stop bit"?
* For the sync modes, do you need to set baud for RX modes?
I think Baud is a divider, so the limit is from /3 to /2^16, and yes that will impose a baud limit, but a lower limit of 1220 Baud at 80MHz (assuming no prescaler).
That may be an issue, but someone could use interrupts for very low baud needs ?
Legacy UARTS can manage 5,6,7,8,9 Data and 1,1.5,2 stop bits and parity choices.
Some of those may seem rare, but MCUs do still support them, so the P2 needs to as well.
With a field for Data length (1..32? ) you can cover many of those, leaving just parity.
There are also UART Error flags to manage, not mentioned yet, and many UARTS have FIFOs that are 12b wide so every RxByte has the error tags applied per-incoming-byte.
Sync is going to be more naturally Master or Slave in SPI uses, and MCUs often spec /2 on SPI Master mode, and some have /4 or /10, or somewhere in between, lower limit on Slave mode.
RaspPi (on paper) can support from 125MHz down in the SPI divider. (250MHz/2N)
I don't want to implement low-level error detection. I don't think that's the place for it. It's better done at a higher level in software via checksums and such, where a macro response can be made, instead of needing to deal with low-level errors which complicate things that need to be most efficient.
Of course, but many systems are already designed, and some would consider
* Parity
* Break detect
* 9 Bit UARTS (often address bit)
Not really error detection layers, but more a feature they simply need to talk to the other equipment.
Slower baud rates can be done via bit-banging as can anything that does not fit the basics.
Remember, there was none of this in P1.
Err actually no - Slower Baud rates I agree with, and have already mentioned, but for other features, it is easy to say "can be done via bit-banging", but you cannot implement low level stuff in SW, without taking a massive speed or power penalty.
That's the whole point of adding this serial HW in the first place! - to reach places where that old "can be done via bit-banging" fails.
Reading up on break detect it seems this is a stream of continuous START bits - the opposite of the normal pause gap - which is a continuous stream of STOP bits. I've never heard of it being intentionally used but something probably should indicate this break condition anyway. I imagine an unplugged cable looks like a break condition, hence the name I guess.
Has that been confirmed ? What range of bits ? (1-32?)
LIN.
But again, not that important as we can check for it.
For instance, if we can set the number of bits, then we can just check the value passed. Provided we can stream the bits, including start and stop bits, we can test for all sorts of errors/parity/etc.
That is what general purpose means - we can basically do in software any setting/checking provided we can stream a number of bits in/out. The hardware is just providing the mechanism to stream the bits into bytes/words/etc and we do the protocol/error (byte, parity, or whatever) on the byte+ basis where we have more time to do it.
Yup, I am all for HW doing the bit level stuff, and SW doing slower stuff, but note your SW layer here, relies on having that bit passed from the hardware layer, or it fails to work, which proves my point.
ergo, the HW itself, must provide enough support to collect that Stop/Break bit.
I'd like to see I2C start and start conditions detected though.
Break detection has nothing to do with line breaks but the equivalent at the UART level is seeing an active low that persists which is easily detected as receiving multiple nulls with framing errors as there are no stop bits. However the thing is I use break as it is baud-rate independent to gain attention, usually to reset the system even if the application isn't listening to serial (built into the driver). So I use it with my Tachyon console in case my code fails to return back to the console etc but also in RS485 and other networked systems as a way of resetting remote devices. It's a really useful feature to have at the hardware level and easy to implement. Please include it. I just count multiple frame-error nulls as a break which is more than good enough.
Yup, just needs the HW to allow for that 9th bit to make it thru to the SW layer.
Yes, i2c Start and Stop are useful, but if doing those, it would be natural to include clock-stretch ability too.
Logic for all 3 is very simple.
I've seen some low end MCUs manage Bytes in Sync mode, and ACK / Start / Stop in SW.
I'm implementing it now, trying to nail down how many flops each function requires, so that I can make a common set of flops to do it all. This is to cut back on clocking power, mainly.
That's a good idea. I'll see when we get there. Please remind me later if you don't see anything.
Good idea, using both would allow BYTE level Data operations, and the flags would capture extra bits, like this :
AP = Address/Parity bit, = 9th bit on 8b UART models -> C bit
SV = Stop Bit value, sampled mid-stop. -> Z bit (Framing error/ break)
Control field would be [BitOrder][AP_Enable][Length4:0]
(BitOrder covers SPI or UART bit order, MSB or LSB first. AP is always just before STOP bit.)
When AP_Enable is set, the C bit carries the Length+1 value, in both directions.
Z could always reflect Stop Bit Rx value ?
For Break Tx, is that best done via Length ?
eg For the LIN example mentioned, that would be something like a length of 22b, and a single value of
0x002AA000, to send both the Break and Sync fields.
After that completes, normal 8b Length is used.
BYTE transfers can support Address/Parity, and that applies to all sizes, meaning 32b sends could append a 33rd AP bit.
The only issue I see is that this would increase the read time, as now you've pushed into the next 3-bit block. I'm guessing this would increase RSxxxx by only 1 clock cycle, though. It may be worth the trade-off.
True, but the min Baud divisor is /3 (practical is more like /6) so there will be 30/33/60/66 sysclks to move the byte at the highest possible Baud speeds.
In theory a transport bottleneck could occur at lowest bit settings, but even there considering a DualSPI/JTAG send of TMS.TDO is usually actually a small set of bits-pairs, and with a full Length control, would send as a set, not one-pair-at-a-time.