SPI Question

[lanternfish]

This one is for the gurus out there who have used the hspi feature of the X1/X2 pixies.

I have read a few threads and datasheets on spi and can't seem to find an answer to the following question.

Q. What is the idle state for the SPI Data out line?

Any help will be much appreciated.

And no, I can't check for myself because my much loved (man cave) workspace is out of comission until we finish 'climbing the property ladder'. I mean, renovating.

 

[hippy]

HSPI Data Out (DO) idle state is usually undefined as it's relevant only when SCLK is asserted.

 

[lanternfish]

HSPI Data Out (DO) idle state is usually undefined as it's relevant only when SCLK is asserted.

Thanks for that Hippy. So, to idle high a pullup R will be the best option?!

This query is around a theoretical investigation into using a 28X2 as a DMX512 transmitter using SPI for the data out. I will add this idea to an existing DMX thread.

 

[hippy]

A pull-up high won't achieve anything if the DO is actively driven. Either it will just connect +V to +V at DO or be current drain from +V to DO 0V.

Looking at Figure 14-3 in the 18F14K22 (20X2) datasheet it's not clear if DO is tri-stated or not with CKE=1 or whether it's always output but undefined.

I'm not sure HSPI would be able to generate DMX-512 as that's standard serial. You'd have to split the single 8-but byte over two HSPI bytes to send the right number of bits and I'm not sure the timing would hold up. You could send six bits of DMX-512 data (0-63) using a single SPI byte and rely on the inter-byte gap to fill in the two msb and stop bit.

I presume HSERIAL is in use with something else otherwise that can be used.

 

[lanternfish]

A pull-up high won't achieve anything if the DO is actively driven. Either it will just connect +V to +V at DO or be current drain from +V to DO 0V.

Looking at Figure 14-3 in the 18F14K22 (20X2) datasheet it's not clear if DO is tri-stated or not with CKE=1 or whether it's always output but undefined.

I'm not sure HSPI would be able to generate DMX-512 as that's standard serial. You'd have to split the single 8-but byte over two HSPI bytes to send the right number of bits and I'm not sure the timing would hold up. You could send six bits of DMX-512 data (0-63) using a single SPI byte and rely on the inter-byte gap to fill in the two msb and stop bit.

I presume HSERIAL is in use with something else otherwise that can be used.

With DMX being 8 data bits and 2 stop bits I didn't think that hserial would do it. Therefore I thought that SPI may save a bit of bit banging. And using various pullup/down techniques to generate the Break and Mark Before/After Break 'bits'.

Also, using SPI 'slow' mode with X2 clocked at 16MHz.

Cheers

 

[hippy]

HSEROUT can effect two stop bits by ensuring bytes aren't sent until the previous has gone, the gap betwen the two bytes ( as long as it lasts one bit time ) will be seen as an extra stop bit.

With DMX-512 transmitting at 250kbps each bit is 4us and there should normally be that much time between executing one HSEROUT command and the next, especially if in a loop transmit.

It seems likely that two stop bits were chosen to give some extra time for bit-banged and hardware only 8N1 receivers to deal with data received during the second stop bit. On-chip UART's are often set up to receive as 8N1 even when receiving 8N2 ( they will receive either, many on-chip UART's don't have a concept of two stop bits, and why do extra initialisation work which is unnecessary if they do ), so although out of official spec 8N1 may well work.

 

[lanternfish]

..... With DMX-512 transmitting at 250kbps each bit is 52us and there should normally be that much time between executing one HSEROUT command and the next, especially if in a loop transmit. If not a "PAUSE 0" or something will ensure that.....

Hippy has corrected this. At 250kbps the bit time is 4us.

From what you have stated re HSEROUT inter-byte 'delay', this is essentially one bit period regardless of baud rate. Is this correct?

 

[lanternfish]

Had another look at the DMX spec and realised, which is what I think you are pointing out, that as the serial line idles high this can be utilised to create the second stop bit.
Brilliant!

And by a few little hardware/software tweaks based on Microchip AN1076, a DMX transmitter is feasible.

 

[hippy]

Here you go

As best as I can tell this is "USITT DMX-512 1990/8us" compatible and performs well in comparison to any assembler program doing the same; loop time of just over 25ms for 512 bytes compared to best achievable of just under 23ms, and that can be improved upon if need be. It's almost as fast as the commercial products I worked on which generated DMX-512.

By good fortune, the inter-byte gap when sending two @ptrinc in a single HSEROUT command works out at just over 8us, so there's the two stop bits sorted

Modifying this for "USITT DMX-512 1986/4us" ( which has a fixed width "mark after break" of 4us, not greater than 8us as per 1990/8us ) would be a challenge in software but could be done with some simple logic circuitry.

Enjoy.

 

[hippy]

And who'd have thunk it ... 9 bit transmission ...

#Picaxe 20X2
#No_Table

Symbol TXSTA = $AC
Symbol TX9 = bit6
Symbol TX9D = bit0

HserSetup B9600_8, %110

PeekSfr TXSTA, b0
TX9 = 1 ' Enable 9 bit TX
TX9D = 0 ' Set 9th bit level
PokeSfr TXSTA, b0

Do
HSerOut 0, ( "U", "U", "U" )
Pause 1000
Loop

 

[hippy]

And knock me darn wiv a feather ... 9-bit receive ...

#Picaxe 20X2
#No_Table
#Terminal 9600

Symbol TXSTA = $AC
Symbol TX9 = bit6
Symbol TX9D = bit0

Symbol RCSTA = $AB
Symbol RC9 = bit6
Symbol RC9D = bit0

HserSetup B9600_8, %111

PeekSfr TXSTA, b0
TX9 = 1
PokeSfr TXSTA, b0

PeekSfr RCSTA, b0
RC9 = 1
PokeSfr RCSTA, b0

SetIntFlags %00100000, %00100000

Do
For b13 = 0 to 1
PeekSfr TXSTA, b0
TX9D = b13
PokeSfr TXSTA, b0
HSerOut 0, ( "U" )
Pause 1000
Next
Loop

Interrupt: ' Loop TX back into RX ( C.0 to B.6 )
Do
PeekSfr RCSTA, b0
SerTxd( #b13, 9, "Got = ",@ptrInc, 9, "Bit 9 = ", #RC9D, CR, LF )
Loop Until ptr = hSerPtr
hSerFlag = 0
SetIntFlags %00100000, %00100000
Pause 1000
Return

Note this only works when the interrupt is serviced before the next byte is received as RC9D is not buffered, you can only get the RC9D of the last byte received. If not checking parity or the 9th bit then it doesn't matter. Being able to set 9-bit receive avoids potential timing/framing errors with back-to-back data sent with 9-bits/Parity., so it's not all entirely pointless.

 

[lanternfish]

And who'd have thunk it ... 9 bit transmission ...

So a DMX transmitter is totally feasible with an X2 part.

Next step, DMX receiver(s).Anyone got any thoughts? Can we check for USART overflow/error to test break condition?

 

[lanternfish]

@12

You are on a roll.

Have you ever thought of writing a book/manual for Picaxes?

 

[hippy]

And this may require Dr_Acula to reach for the defribulator ... automatic filtering on incoming packets !

#Picaxe 20X2
#No_Table
#Terminal 9600

Symbol TXSTA = $AC
Symbol TX9   = bit6
Symbol TX9D  = bit0

Symbol RCSTA = $AB
Symbol RC9   = bit6
Symbol ADDEN = bit3
Symbol RC9D  = bit0

HserSetup B9600_8, %111

PeekSfr TXSTA, b0
TX9  = 1 
PokeSfr TXSTA, b0

PeekSfr RCSTA, b0
RC9  = 1 
PokeSfr RCSTA, b0

PeekSfr RCSTA, b0
ADDEN = 1
PokeSfr RCSTA, b0

SetIntFlags %00100000, %00100000

Do

  ' To Slave # 1

    PeekSfr TXSTA, b0
    TX9D = 1
    PokeSfr TXSTA, b0
    HSerOut 0, ( "1" )
    Pause 1000
    PeekSfr TXSTA, b0
    TX9D = 0
    PokeSfr TXSTA, b0
    HSerOut 0, ( "A", "B" , "C" )
    Pause 1000

    ' To Slave # 2

    PeekSfr TXSTA, b0
    TX9D = 1
    PokeSfr TXSTA, b0
    HSerOut 0, ( "2" )
    Pause 1000
    PeekSfr TXSTA, b0
    TX9D = 0
    PokeSfr TXSTA, b0
    HSerOut 0, ( "D", "E" , "F" )
    Pause 1000

Loop

Interrupt:
  Do
    SerTxd( "Got = ",@ptr , CR, LF )
    If @ptrinc = "1" Then ' Or "2"
      PeekSfr RCSTA, b0
      ADDEN = 0
      PokeSfr RCSTA, b0
      b3 = 3
    Else 
      b3 = b3 Min 1 - 1
      If b3 = 0 Then
        PeekSfr RCSTA, b0
        ADDEN = 1
        PokeSfr RCSTA, b0
      End If
    End If
  Loop Until ptr = hSerPtr
  hSerFlag = 0
  SetIntFlags %00100000, %00100000
  Pause 1000
  Return

 

[hippy]

So a DMX transmitter is totally feasible with an X2 part

Near totally; 1990/8us definitely. 1986/4us needs more thinking about.


Next step, DMX receiver(s).Anyone got any thoughts? Can we check for USART overflow/error to test break condition?

Not the best way in my experience ( but that was with Motorola 68B03 on-chip UART ). In previous employment we used a hardware timer and gating to flag break and to deliver an absolutely clean serial signal to the UART. Overflow etc meant the link was faulty, period.

The problem is the speed; 44us after the start of the break you've only got 52us left to reset the scratchpad pointer and be ready for the next byte, and that's the best case, and it's advisable to look for a longer break to verify it. "Ain't gonna happen", as they say.


Have you ever thought of writing a book/manual for Picaxes?

The difference with books and manuals is that you have to explain everything, can't just throw it out there and hope it's useful. It needs to be tested on every PICAXE which supports it, ideally at every speed, minutiae has to be explained such as polarities for HSERSETUP, which pins are which, how to connect a MAX232, or a 20K/10K, and what if interfacing to 3V3, or running at 3V3 and interfacing to 5V, and on and on. Oh, and some pictures and circuit diagrams.

Also it was fast when I got going but a good couple of hours checking things, verifying them. I dread to think how many more hours full descriptions would take.

I'm not shirking my duty - this is all work done in my own time for the love of hacking and to satisfy a spark of 'what if' - and it's really only proof of concept rather than necessarily useful. As Edison quipped, "10 percent inspiration and 90 percent perspiration", I actually reckon it's 20:80, 10% conceptualising, 10% proving and 80% documenting. If only I had an infinite number of monkeys with an infinite minus one number of typewriters. There has to be one too few typewriters because I'm not making the tea

 

[lanternfish]

Have you ever thought of writing a book/manual for Picaxes?[/i]

The difference with books and manuals is that you have to explain everything, can't just throw it out there and hope it's useful. It needs to be tested on every PICAXE which supports it, ideally at every speed, minutiae has to be explained such as polarities for HSERSETUP, which pins are which, how to connect a MAX232, or a 20K/10K, and what if interfacing to 3V3, or running at 3V3 and interfacing to 5V, and on and on. Oh, and some pictures and circuit diagrams.

Of course, we could all read the Microchip datasheets more fully/often, trawl the interweb and discuss our findings here

Also it was fast when I got going but a good couple of hours checking things, verifying them. I dread to think how many more hours full descriptions would take.

I've noticed that. No sooner is a question asked than you have breadboarded a circuit, tested it and provided a working solution. Amazing!

I'm not shirking my duty - this is all work done in my own time for the love of hacking and to satisfy a spark of 'what if' - and it's really only proof of concept rather than necessarily useful. As Edison quipped, "10 percent inspiration and 90 percent perspiration", I actually reckon it's 20:80, 10% conceptualising, 10% proving and 80% documenting.

I seem to fall in the 1st 10% mostly, a bit more in the second 10%, and b...r all in the remaining 80%

If only I had an infinite number of monkeys with an infinite minus one number of typewriters. There has to be one too few typewriters because I'm not making the tea

Thanks for your comments. Even though it sounds like SPI is probably a bit of a dead end for DMX, this discussion has given me more ideas to pursue

That is of course, when I get my workspace back.