Hey,

I'm doing a software serial routines for a 1Mhz 65xx device that needs to communicate at 57600 bit/s. But my receive code does not work.

57600 gives 17 cycles per bit.

Data comes in negated and it comes in on portb's D6. Protocol is
Startbit-Databits-Stopbit (8N1)
#cycle is a macro that inserts n cycles of code (not touching registers, flags may be touched) and .rept is a repeating macro.

Here's the code. Resulting byte should be in A. Bit sampling is always at 17 cycle interval (or so I believe)

Anyone can see where I've gone wrong?



Any hints would be appreciated.
Cheers

Can you give some samples, i.e.:

expect $41 but get $28

Try sending A,B,D,H which are $41,$42,$44,$48.

That will help decode the bit manipulation that's going on.

Daryl

Hi Daryl,

Thanks for reply. Here's the bytes.

sent: 0x41
rcvd: 0x00

sent: 0x42
rcvd: 0x80

sent: 0x44
rcvd: 0x00

sent: 0x48
rcvd: 0x80

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It looks to me as if
should be


-- Jeff

I make the two paths through the macro one cycle different.

Also, depending on exactly when the start bit starts, you could already be 3 to 7 cycles into the bit before you get to #cycle #25 and then another 3 or 4 cycles before the bit instruction in the macro tests the port again.

Lee.

Thanks for the replies...

Garth: There's no concern about jsr/rts because this does not even happen. I send the bytes through the terminal from the keyboard. One at a time.
So the routine waits for my byte forever, reads it bit by bit when it comes and exits. then again waits for the byte, I send the byte etc. This isn't real stream of bytes at the moment. Just one byte. then another.
Also I made sure bvc and bvs branches do not cross pages.
No interrupts as well.

DrJefyll: Did you count the loops right? bxx branches take 2 or 3 cycles depending on taken/not taken condition. #3 cycle seems right to me. But please elaborate,perhaps I'm missing something.

leeeeee: that's a good point. I'll try to account for that.

You could replace the bit setting code with a straight sequence, like

Might make the timing easier to calculate.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

These are all good points that've been made. There are a few details I'd like to clarify.
Regarding the instruction...I assume Absolute addressing mode is used -- that the IO port is not located in Zero Page. In other words the instruction consumes 4 cycles (not 3) -- is that right?

Also, I'm a little uncertain aboutAre you RORing the Accumulator or a memory location? If memory, is the addressing mode Absolute or Zero-Page? I will use the assumption it's the Accumulator. (I think Bitwise assumes it's memory, which also would work. (And I like his branch-less approach!)


As for timing with your original routine, I've marked below the cycle counts for both paths:
If you add up the totals you'll see they differ by one cycle -- hence my suggestion to change #cycle #3 to #cycle #2.


Following up on leeeeee's second point, I'd suggest thatbe changed toWaiting for the Start Bit is an uncertain business. By the time the code notices it's arrived, up to 6 cycles may already have elapsed. I don't know any perfect way to deal with that -- I would simply average that uncertainty for a "typical" figure of 3. Then add the final (successful) test for the Start Bit, which consumes 4~ for bit portb and 2~ for bvc readbyte. That brings us up to 9 cycles. Add #cycle #16 and you get 25 -- the 1.5 bit-times you wanted.

cheers,

Jeff

You could also leave out the eor #$40, and invert the byte at the end.

Thank you all...

Dr Jefyll: ror @ is accumulator. portb is absolute on non-zero page. your assumptions were ok. The missing cycle is also correct.
Thanks.

BTW, i've managed to do it with branchless approach as BitWise suggested, and used the Alert's tip. It works now for single bytes.
Now I need to throw it into a tight loop of reading N bytes.
But that's easier.



cheers

Shouldn't that be 7 cycles (the branch would have been taken on the previous pass)?

Thanks, Bogax. Yes, certainly each unsuccessful iteration takes 7 cycles total -- I don't have an issue with that. But for the maximum resulting delay I got six by thinking, "there's the bus cycle during which the port reads false -- and we count the six cycles it takes to loop around and try again." Silly me -- that's incorrect. The deadline or decision point is of infinitesimal duration; it doesn't occupy a complete bus cycle.

Therefore the time before the Start Bit is recognized ranges from virtually 0~ to virtually 7~, for a typical delay of 3.5. For our calculations we can round that up to 4~ or down to 3~. If we're being fussy, the choice to round up or down should be aimed at canceling whatever other fractional-cycle timing error we can identify. For example we're using 25~ to represent 1.5 bit-times, when in fact 1.5 * 17 = 25.5 cycles. Since 25.5 got rounded down to 25 (an error of -0.5), 3.5 should get rounded up to 4 (for a complementary error of +0.5).

-- Jeff

I would suggest the following changes ..


That will give you four extra cycles to do something with the byte once you have it.

Lee.

Following on Leeeeee's suggestion.

IFF bit 6 is the only thing changing on the port you might be able to
do this:



However it spreads the port read out over 6 cycles and reduces
the margin for jitter/misalignment