Starting work on smart pins

13»

Comments

  • jmg wrote: »
    cgracey wrote: »
    I've got the initial modes planned out. They fit neatly into 5 bits.

    What is the Baud Rate formula for Sync/Async ?

    number of clocks per bit. Valid bauds start at 3.
  • jmgjmg Posts: 14,540
    cgracey wrote: »
    jmg wrote: »
    What is the Baud Rate formula for Sync/Async ?

    number of clocks per bit. Valid bauds start at 3.
    Cool, So it's simply a /N eqn ?

    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.
  • jmgjmg Posts: 14,540
    edited 2015-12-09 - 00:28:43
    To illustrate just how much of a moving target RaspPi is, this thread covers SPI Speeds.

    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.
  • Can the %FFFFCIOHHHLLL details also be provided? That looks like the layout from P2-Hot, but I can't seem to find that table anywhere...
  • Seairth wrote: »
    Can the %FFFFCIOHHHLLL details also be provided? That looks like the layout from P2-Hot, but I can't seem to find that table anywhere...

    It's on the first page of this thread.
  • cgracey wrote: »
    Seairth wrote: »
    Can the %FFFFCIOHHHLLL details also be provided? That looks like the layout from P2-Hot, but I can't seem to find that table anywhere...

    It's on the first page of this thread.

    Doh! Thanks... :lol:
  • A couple questions:

    * 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?
  • jmgjmg Posts: 14,540
    Seairth wrote: »
    A couple questions:

    * 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)


  • cgraceycgracey Posts: 13,125
    edited 2015-12-09 - 19:31:50
    jmg wrote: »
    Seairth wrote: »
    A couple questions:

    * 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.
  • jmgjmg Posts: 14,540
    edited 2015-12-09 - 20:16:07
    cgracey wrote: »
    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.

  • Simple is good.
    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.
  • jmgjmg Posts: 14,540
    Cluso99 wrote: »
    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.


  • evanhevanh Posts: 10,088
    edited 2015-12-09 - 20:56:07
    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.
  • jmgjmg Posts: 14,540
    evanh wrote: »
    Parity is just another bit, there is already settable number of bits, so no biggie there.

    Has that been confirmed ? What range of bits ? (1-32?)

  • evanh wrote: »
    I've never heard of it being intentionally used ...

    LIN.
  • It was up to 32 bits in the Prop2-Hot design. Don't get too wound up over every detail to moment you think of it.
  • 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.
  • jmgjmg Posts: 14,540
    Cluso99 wrote: »
    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.

  • Chip, do you have an idea of how much logic/flops that first pass took?
  • Peter JakackiPeter Jakacki Posts: 9,826
    edited 2015-12-10 - 00:54:02
    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.
  • jmgjmg Posts: 14,540
    .. 9-bit addressing mode is useful but easily handled at the software level.

    Yup, just needs the HW to allow for that 9th bit to make it thru to the SW layer.
    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).
  • Tubular wrote: »
    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.
  • Seairth wrote: »
    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.
  • jmgjmg Posts: 14,540
    Seairth wrote: »
    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.

  • jmg wrote: »
    Seairth wrote: »
    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.
  • jmgjmg Posts: 14,540
    Seairth wrote: »
    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.

Sign In or Register to comment.