6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 9:01 pm

All times are UTC




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: To FIFO or not...
PostPosted: Tue Oct 19, 2021 1:26 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
I've been making some changes to my recent BIOS that supports the SC28L92 DUART. Deciphering the datasheet is always fun (or not) and that has yielded some surprises along the way. My initial coding was simply to get it working as a console, so I wasn't configuring for FIFO usage or coding to take advantage of them (FIFOs for Receive and Transmit). I'm now making some updates to use them and the results are somewhat interesting and unexpected.

The receive FIFO was easy enough to code for. As the A port is the console, the Watchdog feature needs to be enabled, otherwise no interrupts will occur until you enter enough data to meet the FIFO fill level configured. Easy enough... and there is some small performance gain when I download a file via Xmodem-CRC. It's not a huge performance gain, but enough to make it worthwhile coding for, which is only a few additional bytes of code. In this case, probably a 10-15% improvement.

The transmit FIFO on the other hand, while seemingly straightforward to code for, hasn't been any performance improvement... in fact, it's a massive performance hit. Without it, the actual data throughput is a solid 50% faster than with it. I'll admit that it could my coding, but I'm not quite sure yet. I'm out of town and using a Flash routine I wrote in the past few weeks to update the BIOS insitu. This also implies that if I flash code that doesn't work, the SBC is toast until I get back to my lair where I can reprogram the EEPROM.

I think I'm doing everything correctly (famous last words)... and the code functions, but until I get back home and use the Logic Analyzer to see what's really happening, I'm mostly guessing (albeit incorrectly so far) what's going on. Not sure if others have implemented the FIFO function for transmit and noticed an improvement or not, hence my post just to see what others might have experienced.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 2:24 am 
Offline

Joined: Wed Jun 23, 2021 8:02 am
Posts: 166
My suspicion would be you've set the TX FIFO trigger level so it only generates an interrupt when it's empty (MR0 bits 5,4 both zero). If you set it to generate an interrupt when the FIFO is half-empty, you should have plenty of time to refill it before the line goes idle.


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 2:29 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
floobydust wrote:
The receive FIFO was easy enough to code for. As the A port is the console, the Watchdog feature needs to be enabled, otherwise no interrupts will occur until you enter enough data to meet the FIFO fill level configured.

I recommend you enable the watchdog on both receivers. Otherwise, you will be assuming that input to channel B will always be in multiples of the RxD FIFO fill level required to generate an IRQ.

Quote:
Easy enough... and there is some small performance gain when I download a file via Xmodem-CRC. It's not a huge performance gain, but enough to make it worthwhile coding for, which is only a few additional bytes of code. In this case, probably a 10-15% improvement.

I wouldn't call 10-15 percent a "small performance gain," especially in exchange for a few extra bytes of code. If I could get a 10 percent gain in my SCSI driver I'd be getting an extra 75-or-so KB/second. :D

Quote:
The transmit FIFO on the other hand, while seemingly straightforward to code for, hasn't been any performance improvement... in fact, it's a massive performance hit. Without it, the actual data throughput is a solid 50% faster than with it. I'll admit that it could my coding, but I'm not quite sure yet.

A "massive performance hit" makes me suspect your code is the culprit. :shock:

When I enabled the TxD FIFOs on my POC V1.1 unit after I upgraded to the 28L92 and suitable modified the TxD part of the interrupt handler, I saw a major performance boost, mainly because the MPU was only being interrupted once per 16 datums transmitted instead of on each datum sent, this during a full console screen repaint. I know it works, and scoping the IRQ line while dumping a full screen of text to the console confirms it.

Can you attach both the foreground and IRQ transmit code to your next post so I can take a look? Also, it would be useful for me to see the values you are writing into the MR registers.

Lastly, I've mentioned this before but will reiterate in case you've forgotten. Your method of controlling the RxD and TxD queues is not as efficient as it could be. There is no reason to expend clock cycles maintaining a queue byte count, unless you intend to "manually" control CTS/RTS (which procedure is largely unnecessary with the NXP UARTs when driving most serial hardware). The queue pointers/indices can tell your driver what it needs to know: are the queues empty, not empty or full? Specific byte counts don't matter, only those three conditions.

While maintaining a queue byte count probably doesn't perceptively affect the performance of the foreground parts of your serial I/O (SIO) driver, it definitely has a negative effect on the interrupt side. In driving an SIO port, time is of the essence and unnecessary software gyrations will work against you. The goal in driving TxD is to be able to fill the FIFO faster than the UART can empty it so transmitter interrupts are as infrequent as possible. This can only be accomplished if it is done during the servicing of a single TxD IRQ. It is possible, even at low Ø2 rates. The SIO driver in my POC V1.3 unit will run fine at 115.2 Kbps on all channels with a 1 MHz Ø2 clock without incurring receiver overruns or transmitter underruns during continuous reception or transmission (tested using a loopback adapter). You should be able to accomplish the same thing in your machine. Economy of code in your interrupt service routine is the key.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 2:45 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
kernelthread wrote:
My suspicion would be you've set the TX FIFO trigger level so it only generates an interrupt when it's empty (MR0 bits 5,4 both zero). If you set it to generate an interrupt when the FIFO is half-empty, you should have plenty of time to refill it before the line goes idle.


Yes, I looked at that... and tried all options, I setup the FIFO size 16 bytes, didn't help. I've been going thru the code and counting clock cycles. The code is more than quick enough at 8MHz to be able to fill up the FIFO before a single character can be transmitted at 115.2K baud.

I guess I should add some code fragments here:

First, this puts data in the 128 byte circular buffer.

Code:
;Data Output A routine: puts the data in the A Reg into the xmit buffer, data in
; A Reg is preserved on exit. Transmit is IRQ driven/buffered with a size of 128 bytes.
;
CHROUT          PHY                     ;Save Y Reg (3)
OUTCH           LDY     OCNT_A          ;Get data output count in buffer (3)
                BMI     OUTCH           ;Check against limit, loop back if full (2/3)
;
                LDY     OTAIL_A         ;Get the buffer tail pointer (3)
                STA     OBUF_A,Y        ;Place data in the buffer (5)
                INC     OTAIL_A         ;Increment Tail pointer (5)
                RMB7    OTAIL_A         ;Strip off bit 7, 128 bytes only (5)
                INC     OCNT_A          ;Increment data count (5)
;
                LDY     #%00000100      ;Get mask for xmit on (2)
                STY     UART_COMMAND_A  ;Turn on xmit (4)
;
                PLY                     ;Restore Y Reg (4)
                RTS                     ;Return to caller (6)
;


Second, this is the ISR routine that takes buffer data and puts it into the Xmit FIFO:

Code:
; To take advantage of the onboard FIFO, we test the TxRDY bit in the Status Register.
; If the bit is set, then there is more room in the FIFO. The ISR routine here will
; attempt to fill the FIFO from the Output Buffer. This saves processing time in the
; ISR itself.
;
UARTA_XMT       LDA     OCNT_A          ;Get output buffer count, any data to xmit? (3)
                BEQ     NODATA_A        ;If zero, no data left, turn off xmit (2/3)
;
UARTA_XMTLP     LDA     UART_STATUS_A   ;Get Status Register (4)
                BIT     #%00000100      ;Check TxRDY active (2)
                BEQ     REGEXT_A        ;If TxRDY not set, FIFO is full, exit ISR (2/3)
;
                LDY     OHEAD_A         ;Get the head pointer to buffer (3)
                LDA     OBUF_A,Y        ;Get the next data (5)
                STA     UART_TRANSMIT_A ;Send the data to 28L92 (4)
                INC     OHEAD_A         ;Increment head pointer (5)
                RMB7    OHEAD_A         ;Strip off bit 7, 128 bytes only (5)
                DEC     OCNT_A          ;Decrement output buffer count (5)
                BNE     UARTA_XMTLP     ;If more data, loop back to send it (2/3)
;
;No more buffer data to send, check SC28L92 TxEMT and disable transmit if empty.
; Note: If the TxEMT bit is set, then the FIFO is empty and all data has been sent.
;
NODATA_A        LDA     UART_STATUS_A   ;Get Status Register (4)
                BIT     #%00001000      ;Check TxEMT empty (2)
                BEQ     REGEXT_A        ;If TxEMT not set, more data exists (2/3)
;
                LDY     #%00001000      ;Else, get mask for xmit off (2)
                STY     UART_COMMAND_A  ;Turn off xmit (4)
                BRA     REGEXT_A        ;Exit IRQ handler (3)
;
BUFFUL_A        LDY     #%00000001      ;Get Mask for Buffer full (2)
                STY     UART_MISC       ;Save into 28L92 Misc. Register (4)
;
REGEXT_A        LDA     UART_STATUS_A   ;Get current Status Register A (4)
                STA     UART_SRT_A      ;Save 28L92 Status Register for later use (3)
                JMP     (IRQRTVEC0)     ;Return to Exit/ROM IRQ handler (6)
;


The code being loaded in the registers:

Code:
;Data commands are sent in reverse order from list. This list is the default initialization for
; the DUART as configured for use as a Console connected to either ExtraPutty(WIN) or Serial(OSX)
; The data here is copied to page $03 and is used to configure the DUART during boot up. The soft
; data can be changed and the core INIT_28L92 routine can be called to reconfigure the DUART.
; NOTE: the register offset data is not kept in soft config memory as the initialization
; sequence should not be changed!
;
; Both serial ports are configured at startup!
; - Port A is used as the console.
; - Port B is in idle mode.
;
INIT_DUART       ;Start of DUART Initialization Data
                .DB     %00000011       ;Enable OP0/1 for RTS control Port A/B
                .DB     %00001010       ;Disable Receiver/Disable Transmitter B
                .DB     %00001001       ;Enable Receiver/Disable Transmitter A
                .DB     %00001111       ;Interrupt Mask Register setup
                .DB     %11100000       ;Aux Register setup for Counter/Timer
                .DB     %01001000       ;Counter/Timer Upper Preset
                .DB     %00000000       ;Counter/Timer Lower Preset
                .DB     %11001100       ;Baud Rate clock for Rcv/Xmt - 115.2K B
                .DB     %11001100       ;Baud Rate clock for Rcv/Xmt - 115.2K A
                .DB     %00110000       ;Reset Transmitter B
                .DB     %00100000       ;Reset Receiver B
                .DB     %00110000       ;Reset Transmitter A
                .DB     %00100000       ;Reset Receiver A
                .DB     %00000000       ;Interrupt Mask Register setup
                .DB     %11110000       ;Command Register A - disable Power Down
INIT_DUART_E    ;End of DUART Initialization Data
;
                .DB     $FF             ;Spare byte for offset to MR data
;
;Mode Register Data is defined separately. Using the loop routine above to send this data to
; the DUART does not work properly. See the description of the problem using Indexed addressing
; to load the DUART registers above. This data is also kept in soft config memory in page $03.
; Note that this data is also in reverse order for loading into MRs!
;
MR2_DAT_A       .DB     %00010111       ;Mode Register 2 data
MR1_DAT_A       .DB     %11010011       ;Mode Register 1 Data
MR0_DAT_A       .DB     %11001001       ;Mode Register 0 Data
;
MR2_DAT_B       .DB     %00010111       ;Mode Register 2 data
MR1_DAT_B       .DB     %11010011       ;Mode Register 1 Data
MR0_DAT_B       .DB     %11000001       ;Mode Register 0 Data
;


So, the config is setup with the FIFOs setup got 16 bytes, fill levels at the maximum for Receiver and Transmit. Watchdog is also setup for Receive, which doesn't appear to be an issue. It's just that transmit has the performance hit. Port B isn't being used at this point, but is in the configuration data and BIOS routines to support it.

Sad to say, but much my coding lately is done during consumption of a bottle of Rioja ;-) It helps drown out background noise.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 2:46 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
kernelthread wrote:
My suspicion would be you've set the TX FIFO trigger level so it only generates an interrupt when it's empty (MR0 bits 5,4 both zero). If you set it to generate an interrupt when the FIFO is half-empty, you should have plenty of time to refill it before the line goes idle.

I'd agree, except I run TxD on my POC units with MR0 5,4 set to zero and the FIFO size set to 16. Scoping IRQ during continuous output to the console screen (which is paced by automatic CTS/RTS flow control) demonstrates that my setup is incurring one TxD IRQ per 16 bytes transmitted. I'm able to make this determination because I have channel IRQs individually brought out so I can watch one at a time, and also so the UART part of the ISR can determine which channels are interrupting and whether said interrupts are receive or transmit.

As I said in my previous post, the goal on the interrupt side is to be able to fill the TxD FIFO faster than the UART can empty it during the servicing of a single TxD IRQ. If that can be done then TxD IRQs will only come at 16 byte intervals, assuming that is the effective FIFO size that has been set. I should note that at reset, the 28L92's FIFOs are set to 8 to make them backward compatible with the older 26C92. That feature makes it possible to replace the C92 with the L92 and not have to tinker with the driver. It is a non-optimum setup, however.

I suspect flooby's TxD woes are related to how the interrupt handler is structured.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 2:58 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
floobydust wrote:
Sad to say, but much my coding lately is done during consumption of a bottle of Rioja ;-) It helps drown out background noise.

I will take a look at this later on and see what's what. I know it works.

BTW, are you using wait-states in your system for I/O accesses?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 3:08 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
BigDumbDinosaur wrote:
floobydust wrote:
Sad to say, but much my coding lately is done during consumption of a bottle of Rioja ;-) It helps drown out background noise.

I will take a look at this later on and see what's what. I know it works.

BTW, are you using wait-states in your system for I/O accesses?


Thanks! No wait states for I/O access. Glue logic is an ATF22LV10C. CPU clock is 8MHz. Schematic is posted here: viewtopic.php?f=4&t=6825#p87706

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Tue Oct 19, 2021 8:37 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
floobydust wrote:
BigDumbDinosaur wrote:
floobydust wrote:
Sad to say, but much my coding lately is done during consumption of a bottle of Rioja ;-) It helps drown out background noise.

I will take a look at this later on and see what's what. I know it works.

BTW, are you using wait-states in your system for I/O accesses?


Thanks! No wait states for I/O access. Glue logic is an ATF22LV10C. CPU clock is 8MHz. Schematic is posted here: viewtopic.php?f=4&t=6825#p87706

Couple things pertaining to the foreground part of the driver in no particular order:

  1. OCNT_A and all references to it are unnecessary.

    At the risk of being annoying with asking this question, why are you keeping track of the byte count in the queue? Comparing the head and tail indices is all that is required to determine if there is room in the queue. The amount of room itself is irrelevant because your foreground only processes one datum at a time (which is also true for your interrupt handler). All the foreground has to know is whether there is room in the queue and if so, where to put the next datum.

  2. Your handling of the transmitter is inefficient.

    For every datum that is transmitted, your foreground code is telling the UART to enable the transmitter without actually knowing if that is necessary. It would be more efficient to maintain status somewhere, e.g., zero page, and write to the UART's channel command register only if status says the transmitter is off-line.

    While the data sheet says enabling the transmitter when it is already is enabled is effectively a no-op (obviously), that doesn't mean the UART doesn't take time to react to the write. I mention this because any write to the command register will briefly stop whatever the UART is doing with the affected channel as it processes whatever might have been changed by the write (NXP doesn't say how long, but I have reason to believe it's for three X1 clock edges). With your current code, a full repaint of an 80 × 24 text display will cause 1920 such brief stoppages in rapid succession, which is probably not ideal. :D

    I recommend you set up a semaphore on zero page to indicate the state of the transmitter. If bit 7 is set, the transmitter has been shut down. If clear, the transmitter is running and should be generating TxEMT interrupts if it runs out of data. It's an easy test with BIT or TRB—the latter is a two-for-one atomic instruction that is tailor-made for controlling bit fields, as well as twiddling chip register bits (I use TRB and TSB a lot in my code). When you get around to using the DUART's other channel you can assign bit 6 of your semaphore for the channel-B transmitter.

  3. You have a logic booby-trap in your code.

    By way of explanation, in your system, the only reasons the queue would be full are the transmitter isn't running or IRQs are not being processed. Either case will deadlock your machine. Disregarding the IRQ angle, in your foreground you keep polling for queue space if the queue is full but your loop doesn't check to see if the transmitter is enabled. If it's not enabled it won't interrupt so it can be fed, the queue will stay full and the MPU will get stuck in the mud waiting for something that will never happen.

    Rather than me edit your code to address that problem, just look at the foreground code I use in my POC unit and copy/borrow/steal as appropriate. As you read it, consider that it is written to handle any of the SIO channels in the machine, and uses a direct (zero) page pointer array to select the appropriate UART channel and queue pointers. Also note that the datum to be transmitted gets picked up from the stack. However, the basic principles will work with the 65C02.

    Code:
    ;sioput: WRITE DATUM TO SELECTED SIO CHANNEL
    ;
    ;   ———————————————————————————————————————————————————————————————————————
    ;   Synopsis: This service writes the datum loaded into .A to a serial I/O
    ;             (SIO) channel.  See the invocation example for details.
    ;
    ;             This service will block if the transmitter queue (TxQ) for
    ;             the selected channel is full.
    ;   ———————————————————————————————————————————————————————————————————————
    ;   Invocation example: sep #%00110000
    ;                       lda #datum
    ;                       ldx #chan              ;SIO channel, 0-n
    ;                       cop #ksioput
    ;                       bcc okay               ;datum accepted
    ;
    ;                       bcs error              ;non-existent channel
    ;
    ;   Exit registers: .A: entry value ¹
    ;                   .B: entry value
    ;                   .X: entry value
    ;                   .Y: entry value
    ;                   DB: entry value
    ;                   DP: entry value
    ;                   PB: entry value
    ;                   SR: NVmxDIZC
    ;                       ||||||||
    ;                       |||||||+———> 0: datum gotten
    ;                       |||||||      1: invalid channel
    ;                       +++++++————> entry value
    ;
    ;   Notes: 1) E_SIOCH if a non-existent channel is selected.
    ;
    ;          2) SIO channel $00 is the console channel.
    ;   ———————————————————————————————————————————————————————————————————————
    ;
    sioput   lda api_xrx,s         ;get channel index
             cmp #n_nxpchn         ;valid channel?
             bcs sionodef          ;no
    ;
             asl                   ;word-align index
             sep #m_setx           ;8-bit index
             tax                   ;pointer index
             lda sioputtx,x        ;TxQ 'put' pointer LSB
             inc                   ;bump it
    ;
    .main    cmp siogettx,x        ;TxQ 'get' pointer LSB
             beq .txqfull          ;TxQ full
    ;
             tay                   ;hold new 'put' pointer LSB
             lda api_arx,s         ;get datum &...
             sta (sioputtx,x)      ;put in TxQ
             sty sioputtx,x        ;update 'put' pointer LSB
             lda siotstab,x        ;transmitter status mask
             trb siotxst           ;transmitter running?
             bne .enabltx          ;no
    ;
             clc                   ;yes
             rts
    ;
    ;
    ;   manage transmitter...
    ;
    .enabltx lda #nxpcrtxe         ;enable TxD command
             sta (siocr,x)         ;enable transmitter
             clc
             rts
    ;
    ;
    ;   block for TxQ space...
    ;
    .txqfull tay                   ;protect 'put' pointer LSB
             lda siotstab,x        ;transmitter status mask
             trb siotxst           ;transmitter running?
             beq .0000010          ;apparently
    ;
             jsr .enabltx          ;wake up transmitter
    ;
    .0000010 tya                   ;get back 'put' pointer
             wai                   ;sleep for a while &...
             bra .main             ;try again

    Notice how the "block for TxQ space" code includes a call to the "manage transmitter" code to make sure the transmitter is on-line. I put the WAI in there so the "block for TxQ space" routine doesn't beat the system to death while the UART is busy, especially if the remote station has told the UART to stop sending because the remote is full-up with data.

Turning to your IRQ handler:

  1. The following bit of code is unnecessary:

    Code:
    NODATA_A        LDA     UART_STATUS_A   ;Get Status Register (4)
                    BIT     #%00001000      ;Check TxEMT empty (2)
                    BEQ     REGEXT_A        ;If TxEMT not set, more data exists (2/3)

    As soon as you know the queue is empty you can tell the UART to disable the transmitter and then you can move on to something else. Here's what the data sheet has to say about it:

      If the transmitter is disabled it continues operating until the character currently being transmitted and any characters in the Tx FIFO, including parity and stop bits, have been transmitted. New data cannot be loaded to the Tx FIFO when the transmitter is disabled

    In simple terms, telling the UART to disable the transmitter will cause it to immediately cease interrupting, but won't actually shut it down until the last datum in the FIFO has been fully shifted out onto the wire. You don't need to "baby-sit" the transmitter—it "knows" when to take a nap when you tell it to do so. :D

    Again, I'll post some code from my SIO interrupt handler so you can compare notes. What you are looking at is the inner loop that is run for each channel whose transmitter has interrupted. As with the foreground, reference is made to a direct page pointer array to select the appropriate UART channel and queue pointers, a necessary feature to allow one piece of code to service as many channels are are configured into the system. The X-register is the index that corresponds to the channel being processed (.X progresses 0-2-4-6... etc.).

    Code:
    ;   start of TxD FIFO processing loop...
    ;
    .0000020 lda siogettx,x        ;TxQ queue 'get' pointer
             cmp sioputtx,x        ;queue 'put' pointer
             beq .0000030          ;nothing to transmit, so shut 'er down
    ;
             lda (siosr,x)         ;get channel status
             bit #nxptxdr          ;TxD FIFO full?
             beq .0000040          ;yes, done for now with this channel...
    ;
    ;   ———————————————————————————————————————————————————————————————
    ;   The above branch exits this loop & selects the next channel for
    ;   processing if the FIFO has no more room.  When the FIFO empties
    ;   the transmitter will interrupt & say "feed me!"
    ;   ———————————————————————————————————————————————————————————————
    ;
             lda (siogettx,x)      ;read from queue &...
             sta (siofif,x)        ;write to TxD FIFO
             inc siogettx,x        ;adjust queue index &...
             bra .0000020          ;go back for next datum
    ;
    ;   ...end of THR processing loop
    ;
    .0000030 lda #nxpcrtxd         ;disable...
             sta (siocr,x)         ;transmitter
             lda siotstab,x        ;tell foreground...
             tsb siotxst           ;about it

    Incidentally, I am running 256 byte queues, starting with POC V1.3.

    Note the semaphore (SIOTXST) that tells the foreground when the transmitter is off-line. Since there are four transmitters in the system, the semaphore is actually a bit field. SIOTSTAB is an array of masks that are used to manipulate the semaphore bit that corresponds to the transmitter being processed (this arrangement can handle up to eight channels). I use a static array instead of computing the mask, since doing the latter on every interrupt is wasteful—the masks aren't going to be different on each trip through the ISR.

  2. Not sure I understand the point of the following:

    Code:
    REGEXT_A        LDA     UART_STATUS_A   ;Get current Status Register A (4)
                    STA     UART_SRT_A      ;Save 28L92 Status Register for later use (3)
                    JMP     (IRQRTVEC0)     ;Return to Exit/ROM IRQ handler (6)

    Aside from consuming valuable clock cycles, saving a copy of the status register is usually of limited value. It is constantly changing, so its value from a programmatic standpoint exists only when read and immediately acted upon.

One other thing to consider is running the 28L92 on 3.3 volts may slow it down in subtle ways. It's hard to tell for sure from looking at the data sheet, although there are separate timing specs for 3.3 and 5 volts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Sun Oct 24, 2021 3:39 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
First, thanks to kernelthread and BDD for responding on this thread... always appreciated.

Oddly, I ended up out of pocket this past week... tying up loose ends in GA on Tuesday, driving back to FL on Wednesday, consulting gig on Thursday and finding a leaky kitchen faucet and replacing the kitchen sink/faucet on Friday. Today (Saturday) was just "Coming Back to Life" and tomorrow is F1 (US Gran Prix).

So... I'll be looking at BDD's code more closely and then re-examining mine. I would say that the existing routines will run the 28L92 very fast without the FIFO being utilized... so there's some odd things at play here. I also looked at cycle counts for all routines and it certainly should be running much faster, so perhaps the UART operates differently internally when using the FIFO depth. I'll be looking into that over the next few days.

Once I get a better handle on things, I'll post again with findings.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Sun Oct 24, 2021 3:52 am 
Offline

Joined: Mon Feb 15, 2021 2:11 am
Posts: 100
floobydust wrote:
Oddly, I ended up out of pocket this past week... tying up loose ends in GA on Tuesday, driving back to FL on Wednesday, consulting gig on Thursday and finding a leaky kitchen faucet and replacing the kitchen sink/faucet on Friday. Today (Saturday) was just "Coming Back to Life" and tomorrow is F1 (US Gran Prix).



I sympathize on the leaky kitchen faucet front. Yesterday night mine started leaking, and the only thing that stopped the leaking was shutting off the valve on the hot water line to the faucet. My wife and I will likely be faucet shopping tomorrow.

Good luck with your serial comms programming.


Top
 Profile  
Reply with quote  
 Post subject: Re: To FIFO or not...
PostPosted: Sun Oct 24, 2021 4:12 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Sean wrote:
floobydust wrote:
Oddly, I ended up out of pocket this past week... tying up loose ends in GA on Tuesday, driving back to FL on Wednesday, consulting gig on Thursday and finding a leaky kitchen faucet and replacing the kitchen sink/faucet on Friday. Today (Saturday) was just "Coming Back to Life" and tomorrow is F1 (US Gran Prix).

I sympathize on the leaky kitchen faucet front. Yesterday night mine started leaking, and the only thing that stopped the leaking was shutting off the valve on the hot water line to the faucet. My wife and I will likely be faucet shopping tomorrow.

Good luck with your serial comms programming.

Funny coincidence. My water softener is giving me some grief. :shock:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: