I need another pair of eyes...

mikesb · Post by **mikesb** » Mon Jul 17, 2006 10:02 am

to look here:

http://www.bgsoflex.com/megasquirt.asm

and here:

http://www.bgsoflex.com/megasquirt.h

No matter how long I stare at (and test in my emulator) the IN_SCI_TX section, it sends one byte too many - there's always a junk byte sent at the end.

For example, the A command sends the real time variables:

Code: Select all

; RAM Variables - Ordered List for RS232 realtime download - delivered in one pack
secl:	ds	1	; low seconds - from 0 to 255, then rollover
squirt: ds      1       ; Event variable bit field for Injector Firing
engine: ds      1       ; Variable bit-field to hold engine current status
baro:	ds	1	; Barometer ADC Raw Reading - KPa (0 - 255)
map:	ds	1	; Manifold Absolute Pressure ADC Raw Reading - KPa (0 - 255)
mat:	ds	1	; Manifold Air Temp ADC Raw Reading - counts (0 - 255)
clt:	ds	1	; Coolant Temperature ADC Raw Reading - counts (0 - 255)
tps:	ds	1	; Throttle Position Sensor ADC Raw Reading - counts, represents 0 - 5 volts
batt:	ds	1	; Battery Voltage ADC Raw Reading - counts
ego:    ds      1       ; Exhaust Gas Oxygen ADC Raw Reading - counts
egocorr:ds      1       ; Oxygen Sensor Correction
aircor: ds      1       ; Air Density Correction lookup - percent
warmcor:ds      1       ; Total Warmup Correction - percent
rpm:    ds      1       ; Computed engine RPM - rpm/100
pw:     ds      1       ; injector squirt time in 1/10 millesec (0 to 25.5 millisec) - applied
tpsaccel:ds     1       ; Acceleration enrichment - percent
barocor:ds      1       ; Barometer Lookup Correction - percent
gammae: ds      1       ; Total Gamma Enrichments - percent
vecurr: ds      1       ; Current VE value from lookup table - percent
bspot1: ds      1       ; Blank Spot 1
bspot2: ds      1       ; Blank Spot 2
bspot3: ds      1       ; Blank Spot 3

I count 22 bytes, hex $16.

But in the transmit code I see:

Code: Select all

MODE_A
        clr     txcnt                   ; Send back all real-time variables
        lda     #$01
        sta     txmode
        lda     #$17
        sta     txgoal
        bset    TE,SCC2                 ; Enable Transmit
        bset    SCTIE,SCC2              ; Enable transmit interrupt
        bra     DONE_RCV

and the transmit code, which sends $17 bytes

Code: Select all

IN_SCI_TX:
        pshh
        lda     SCS1    ; Clear the SCRF bit by reading this register
        clrh
        lda     txcnt
        tax
        lda     txmode
	cmp	#$05
	beq	IN_Q_MODE
        cmp     #$01
        bne     IN_V_MODE
IN_A_OR_C_MODE:
        lda     secl,X
        bra     CONT_TX
IN_V_MODE
        lda     ve,x
	bra	CONT_TX
IN_Q_MODE
	lda	REVNUM,X

CONT_TX:
        sta     SCDR
        lda     txcnt
        inca
        sta     txcnt
        cmp     txgoal
        bne     DONE_XFER

        clr     txcnt
        clr     txgoal
        clr     txmode

        bclr    TE,SCC2                 ; Disable Transmit
        bclr    SCTIE,SCC2              ; Disable transmit interrupt

DONE_XFER
        pulh
        rti

No matter how I stare and try this, I get an extra byte. Same is true for all of the transmissions MSNS, we seem to be sending N+1 instead of N - 'S' and 'T', and even 'R' for example.

What am I missing?

mikesb · Post by **mikesb** » Mon Jul 17, 2006 10:50 am

Yes, I'm sure it is the classic problem - what I'm trying to figure out is whether it's mine or that code

...

There's a "clr TXCNT" to start, which means the count starts from 0. The check:

Code: Select all

        sta     SCDR 
        lda     txcnt 
        inca 
        sta     txcnt 
        cmp     txgoal 
        bne     DONE_XFER

increments and checks AFTER the byte is sent, so a count of 1 means 1 byte is sent, a count of 2 for 2 bytes, all the way up to $17, right? So 23T instead of 22T bytes are sent. I've stared at this for long time and I still get the same answer

...

mikesb · Post by **mikesb** » Mon Jul 17, 2006 11:34 am

Hmm, I think I get it now. It looks like the code causes & uses an extra interrupt to turn off the transmitter after the last character to be transmitted is transfered into the shift buffer.

Is there a reason to turn off transmitter with the TE bit? Why not simply disable interrupts after the last character (N instead of N+1) and leave the transmitter to idle? It would save one interrupt request.

mikesb · Post by **mikesb** » Tue Jul 18, 2006 9:38 am

Thanks Mike - it helped to have a chat about it. It's definitely what's going on, I added a delay in the emulator and it sends the right amount of data by using the SCIM TE flag to clip the last character.

Post by **jsmcortina** » Tue Jul 18, 2006 9:54 am

It is the off by one issue.
After sending the data, the code increments the byte and then compares to the target value so the $17 piece of data is never seen, you get the one previous.

I'd have to refresh myself on the code to give a more full answer, but last time I studied it, I was happy that it was working in a sensible manner.

James

mikesb · Post by **mikesb** » Tue Jul 18, 2006 10:27 am

Have a look when you get a chance Jim, let me know what you find. I've convinced myself it's an off by one issue in the original megasquirt code (it's still there in the last version of msns I've looked at), but I'd appreciate hearing your view.

I'm pretty sure N+1 characters are loaded in the transmitter, but the transmitter is disabled befpre the extra one is sent so it comes out right. What's there works, though it's different than what I would have done. Instead I'd turn off transmitter interrupts after loading the last (Nth) character but leave the transmitter itself enabled. It's possible if the transmit speed was high enough (like in my emulator or maybe over high speed USB) that N+1 characters could be sent.