asm and serial ish

Ben Ogle

#1 ◈ 2024-11-11

Ok so lets say we have this code:

Code:
label_354a:     SUBB    A, #010h               ; 354A 0 258 ??? A610
                L       A, ACC                 ; 354C 1 258 ??? E506
                SLL     A                      ; 354E 1 258 ??? 53
                ADD     A, #logging_table      ; 354F 1 258 ??? 867035
                MOV     DP, A                  ; 3552 1 258 ??? 52
                LC      A, [DP]                ; 3553 1 258 ??? 92A8
                MOV     DP, A                  ; 3555 1 258 ??? 52
                LB      A, [DP]                ; 3556 0 258 ??? F2
                SJ      label_355b             ; 3557 0 258 ??? CB02
                                               ; 3559 from 353C (DD0,258,???)
                                               ; 3559 from 3541 (DD0,258,???)
label_3559:     LB      A, #055h               ; 3559 0 258 ??? 7755
                                               ; 355B from 3557 (DD0,258,???)
                                               ; 355B from 3537 (DD0,258,???)
                                               ; 355B from 3548 (DD0,258,???)
label_355b:     STB     A, STBUF               ; 355B 0 258 ??? D551


What it does is take a byte, look up the byte in the logging table and then store the byte into the stbuf (tx buffer).

My question is can I make a loop and continuously store things into the tx buffer? That way I could send everything at once and wouldnt have to fuck with sending then receiving, sending then receiving, etc. It should be faster, right? Plus it would be a real snapshot of the ecu's state. So, does the byte get transmitted as soon as it is stored into the STBUF register?

Ben

calvin

#2 ◈ 2024-11-11

Ben a byte is send when put in stbuf.
I was thinking the same. So the ecu sends a constant stream. I woud be better/faster i think

Ben Ogle

#3 ◈ 2024-11-11

Yeah, I've been meaning to test but I havent got around to it.

Ben

Ltdannear

#4 ◈ 2024-11-11

If you're going to do a constant stream you probably should consider doing it at an interval, to not bog down the processor. Use a timer if there's any extra to trigger a refresh. Also, you will need some sort of header or start indicator so you know the head from the tail

Ben Ogle

#5 ◈ 2024-11-11

Well, why a header when you will be looking for it after you send the command? i.e. you send the rpm command and it sends 2 bytes back. If you dont get 2 bytes then you discard.

I'm not saying stream as in constant stream all the time.

Ben

Kabuki

#6 ◈ 2024-11-11

More like, send in your group of request bytes and as each one is looked up, it is then stored in the buffer until all the requests are made, then the group of response bytes are all sent out together? That sound like a great idea. Then the datalogging program can update all of the values at once, which reduces screen writes, correct? I may understand this stuff yet! :lol:

blundar

#7 ◈ 2024-11-11

To answer your original question, the SBUF is just a RAM location - it's not a FIFO. If you store RPM_LO in the SBUF and then put RPM_HI in there before serial data is tranmitted (check RI/TI bits) then you overwrite the data in the buf. You'd need to implement circular buffers (not hard) if you wanted something of a more FIFO-like nature.

Circular buffers:
2x 16 byte buffers (RXD, TXD)
1x ISR pointer byte (2x 4bit nibbles) for RXD pointer, TXD pointer
RXD pointer determines where ECU puts next byte it receives
TXD pointer determines where ECU gets next byte to send
1x Userspace pointer byte (2x 4bit nibbles) for RXD process, TXD free
RXD process points to the the byte currently being used by the serial receive routine
TXD free points to the first free byte in the TXD buffer.
TXD free / TXD pointer operate independently so the code can "queue up" data to send.
RXD process / RXD pointer operate independently so the code can receive commands while still processing an existing command.

Hope that helps.
-D