UART - Sending 3 bytes per start/stop bit sets.

[yyrkoon 250]

yep-

(Page 3, Device Pinout)

g2553_pinouts.png

See how (in the 20-pin variant) pin 9 says "P2.1/TA1.1" ... Timer_A1 CCR#1 is its alternate function (with P2SEL |= BIT1, P2SEL2 &= ~BIT1)

 

Also P2DIR needs configuring (P2DIR &= ~BIT1) to make it an input (CCI):

(page 51, Port 2 schematics)

g2553_port2cfgtable.png

As luck would have it. Wulf already designed the board with the two P1 TA.x pins in mind, Intentionally ? I don't know . . . but going back to what you mentioned either about TXD. From what I've read, one does not need this functionality for TXD. I'm not sure the person I read this from said why, but I figured since we have full control of TXD already ( not arbitrary like RXD per se ), one would not need this functionality. But hey . . . I'm newb . . . Seriously.

 

EDIT:

 

D'oh! Those were the hardware UART pins heh. SO looks like I need P1.5 for RXD.

[spirilis 1,265]

As luck would have it. Wulf already designed the board with the two P1 TA.x pins in mind, Intentionally ? I don't know . . . but going back to what you mentioned either about TXD. From what I've read, one does not need this functionality for TXD. I'm not sure the person I read this from said why, but I figured since we have full control of TXD already ( not arbitrary like RXD per se ), one would not need this functionality. But hey . . . I'm newb . . . Seriously.

yeah, I can imagine you don't need the timer for output, since the CPU can time its execution as needed based on interrupts or polling a timer and just manually flip the GPIO.

[yyrkoon 250]

So this is one case were Rei Vilo's Launchpad pic fails. But I use it almost exclusively for everything else.

[yyrkoon 250]

 

D'oh again ! I was looking in the MSP430x2xx Family use;s guide . . . About as terse reading as the beaglebone's am335x's TRM, but only 1/10th the size( in pages ).

 

So probably as everyone can see, I'm a bit flustered at the moment. I'm still a bit confused, and Wulf is trying ot finalize his schematic while I'm having to change stuff as I figure it out . . .and I'm still not 100% sure this whole deal will even work. It should, but I was also sure that talking directly from the beaglebone's uart to the DALI level converter was going to work too . . .

[yyrkoon 250]

So, I found an appnote from Microchip that has a very good explanation from a programmers standpoint. Honestly I could care less about the electrical characteristics . . . so long as I can figure out what I need to know. Link: http://ww1.microchip.com/downloads/en/AppNotes/01465A.pdf

 

Starting on page 4 it shows what a DALI packet should look like. Extended DALI, is exactly the same. Except the data byte would be 0x0h(always) with an additional third byte at the end.

 

I've up until now misunderstood the protocol. Which is why it would have been better to talk with an Engineer instead of a Designer. First it's Manchester encoding. Which means bit's are formed by rising or falling edge signals within a bit frame. Second, there are two stop bits at the end of transmission, not one. Which from a programmers standpoint is about the same thing. The signal just need to be high for two bit frames in a row is all. Instead of just one.

 

The rest I understood, as far as what each bit's purpose was. etc.

 

More on all this later . . . I need to work out in my head how and if this will change things. On the surface to me, this seems that because of the encoding, it's very close to, but deceptively different from standard UART. Encoding according to the appnote seems to fairly trivial. Decoding on the other hand seems a good bit more complex.

[LiviuM 43]

For Manchester decoding (not on micro controllers, on other equipment), I've measured the time distance between consecutive edges. If the distance is half of the bit length, the last bit is repeated, if the distance is the bit length, the last bit is inverted.

If you use in interrupt to detect the falling edge and to start a timer, and as you know the first (start) bit is a zero, detecting the next bits shouldn't be to difficult.

[yyrkoon 250]

Finally ! Python code "in the wild" that actually reads like a competent programmer wrote the code: https://github.com/edinburghhacklab/dali/blob/master/dali.ino#L59-L94

 

Timing is all done by hand, but that code is awesome for readability.

 

EDIT:

 

Err opps, that's an INO file, so C /C++( what I'm looking at looks mostly to be straight C )

[yyrkoon 250]

For Manchester decoding (not on micro controllers, on other equipment), I've measured the time distance between consecutive edges. If the distance is half of the bit length, the last bit is repeated, if the distance is the bit length, the last bit is inverted.

If you use in interrupt to detect the falling edge and to start a timer, and as you know the first (start) bit is a zero, detecting the next bits shouldn't be to difficult.

I get what you're saying, but at the same time I don't. E.G. What you're saying makes perfect sense to me in English, but working it out into code in my head . . . will take some doing

[LiviuM 43]

makes perfect sense to me in English

Strange, I was thinking the English is my week point...

What I tried to say is, if you look the diagram at page 4 in the Microchips AN, you'll see that every time the bit value changes (0->1 or 1->0) you don't have a transition at the end of bit, but if the bit repeats, you have a transition in the middle of the bit (the active one) and one transition at the end of bit.

But looking now to the same diagram, I see now that if you can detect the start edge (first H->L transition), there are maybe better criteria to decode the bits.

[yyrkoon 250]

For now, this project is on hold, and may not continue. After I've spent some time researching this protocol, we've come to the conclusion that there has to be a better way.