floobydust wrote:
I think I for one would like to see more of the actual equates for your variables, etc. (what memory locations are used, i.e., page zero or other RAM).
Good point. I'll try to remember to include my equates in the future. The memory usage is still in flux. I need to decide things like "Do I want to use the lower addresses of page zero for the BIOS and monitor and leave the upper addresses for the user, or vice versa?"
floobydust wrote:
Also, are you using the UART channel for a console or for basic data transfer? If the Receiver FIFO is setup to only interrupt when it's full, using it as a console doesn't work, as you need to fill up the FIFO with console data before an interrupt is generated, i.e., you're typing blind with no visible feedback (or activity) until you send 16 bytes over.
I am using the UART for a console. The SC28L92 has an Rx watchdog timer that takes care of this problem.
From the SC28L92 data sheet:
Quote:
When enabled, the watchdog timer will generate a receiver interrupt if the receiver FIFO has not been accessed within 64 bit times of the receiver 1x clock. The watchdog timer is used to alert the control processor that data is in the Rx FIFO that has not been read. This situation will occur when the byte count of the last part of a message is not large enough to generate an interrupt.
The watchdog timer presents itself as a receiver interrupt with the RxRDY bit set in SR and ISR.
It's a really useful feature.
floobydust wrote:
On the interrupt handler, you shouldn't need to reload the UART_ISR multiple times. Load it once, then use the BIT instruction to see if any interrupts are pending, then handle them via your priority. It's easier and somewhat quicker to use the BIT instruction to check and use BNE to handle the active interrupt. If it's not active, you just drop into the next BIT test until you run out, which becomes your ISR exit.
The interrupt handler only reloads the UART_ISR if the A register is used in the processing of an interrupt. For example, if the SC28L92 counter is not interrupting, we branch directly to the BIT test for the UART receiver without reloading UART_ISR. If the receiver is interrupting, we handle it. Since the A register is used during the processing of the receiver interrupt we need to reload UART_ISR to be able to check if the transmitter is also interrupting.
floobydust wrote:
Managing a 128 byte queue is still easy, just strip off the high order bit of the index. If you're using a 65C02, you can use the RMB7 instruction (if the variables are in page zero).
This is one of my weak spots. I know the basic 6502 instructions, but I need to become more comfortable with instructions like RMB7. I've seen it used in your code, and I have a basic understanding of what it does, but I need to learn when I should use it.
floobydust wrote:
As you're looking to handle the software break condition, I would suggest using a pre- and post-process routine to figure that out and use some RAM vectors to point to the actual ISR and Break handlers. This also allows you to insert other ISRs later with relative ease, plus you can prioritize them without making a lot of changes to your existing ISR(s).
I've seen examples of interrupt vectors in your code, and think I understand how they work, but I haven't gotten there in my code yet. They seem like a good thing, and I plan to incorporate them before I am done.
floobydust wrote:
Hope this qualifies as constructive
It's absolutely constructive! Thank you!
Shawn
Login
Register
FAQ
Search
