Tcfovflo

[ngkdc]

What would cause TCFOVFLO to start incrementing ... but only after a program has been loaded and the IsoPod reset?

When I load the code, save to RAM and execute, TCFOVFLO stays at zero. If I reset the Isopod, and then manually restart the program, TCFOVFLO starts climbing.

Thanks,

Rick

[RMDumse]

TCFOVFLO is incremented when the SCHEDULE-RUNS is still running when the next SCHEDULE-RUN time comes up.

Either you're running to often, running too long, or most likely, you've got a program counter capture loop in the MACHINE-CHAIN wasting time.

[ngkdc]

I found most of my delay time is in sending characters out the SCI1 port. I'm running the port at 19,200 baud and will be sending a maximum of 100 characters (80 displayed characters, 20 position and format characters typically). I'm updating this display once a second. I am using the TX buffer you discussed with me earlier ... but don't see any difference whether I use a TX buffer or not.

I STRONGLY suspect the problem is in my lack of FORTH experience and product understanding. Every issue to date has shown that to be the case!

I'm about 85-90% complete on this conversion, and I can't say enough good about the Isopod or NMI! Once the lid is off the project, I'll share the end-product details.

Again, thank you for all the helpful, timely support. Thanks also for your patience with me while I get up to speed. The good news is that when I get this project done, the next three are going to be very easy, because I'll be using the 'pod in them as well, and most of the code is ready to "borrow"!

Rick

[RMDumse]

... but don't see any difference whether I use a TX buffer or not

This just doesn't seem right. Try disposing of the characters by using DROP instead of TX in your program. Then see if TCFOVFLO is going up or not. Of course the display won't show anything, but you should still be interactive on the system channel to check TCFOVFLO, I think.

Perhaps you need to make a larger buffer? How many did we assign? Since you need 100 characters, say, go double, plus the four locations required for pointers, so try 204.

If you are only sending 100 chars every second, above 1200 baud, I'd think you should be fine, and not waiting on TX at all.

[ngkdc]

Good morning Randy,



Try disposing of the characters by using DROP instead of TX in your program. Then see if TCFOVFLO is going up or not.

I did ... TCFOVFLO still climbs. Of course, after looking again at the code, I've figured out why ... I'm using a DO LOOP to pump characters one at a time from my message buffer to SCI1.

Perhaps you need to make a larger buffer? How many did we assign? Since you need 100 characters, say, go double, plus the four locations required for pointers, so try 204.

I was at 84 characters, bumped to 204. No change. I then looked, and discovered that the buffer wasn't ever doing anything ... I copied a text string into the buffer, ran the program (which sends a lot of text out SCI1), and neither the output buffer or input buffer for SCI1 showed any activity. SCI0 buffers showed plenty of activity ... I could see the last text sent to and from the Isopod.

This begs the question ... what am I doing wrong? If I could, I'd simply use CMOVE> to transfer my text string to the SCI1 buffer and forget it. Problem is ... it doesn't work.

My program (currently) is sending data out SCI1 once a second; checking SCI1 for input, and processing if any; waiting for input on SCI0, processing any input commands; and will be monitoring 8 analog inputs, converting them, displaying the results on SCI1, answering polled requests on SCI0; and controlling two PWM channels.

I really need to keep from overrunning my 50,000 cycle count, as one of the jobs occuring in a machine executed once a second is to update a seconds-counter (again, if there's a better way, I'm eager to hear). I wouldn't notice the cycle count overrun, except my clock is losing 1 minute per hour right now!

With my SCI1 TX part of the code replaced with a DROP, I'm seeing TCFMAX of 4956, but TCFOVFLO is still increasing. I'm guessing TXFMAX right now is really 70492.

So, the loop has to go, and I'd like to understand better how to use the transmit buffer for SCI1. According to the documentation, I should be able to determine the number of buffer characters available with SCI1 TX? ... and even with a buffer length of 204, I get a response of 1 (same thing with SCI0 which has an 84 character buffer).

In a previous project (with a different processor), creating a transmit buffer took all the handling away ... all I needed to do was write a message to the buffer, and the system handled checking for and transmitting any text. Is there any way this can be done in the Isopod?

Thanks,

Rick

[RMDumse]

SCI1 TX? should return the buffer size if you've has enabled
the transmitter buffer. If you are getting a result of 1, then the buffer has not been correctly initialized. The command should be

address size SCI1 TXBUFFER

After you does that, SCI1 TX? should return size-4.

Can you post or email your SCI1 code, or at least the initialization sections of it?

As far as moving in a block of text and jimmying the buffer... It would be best not to write code that directly manipulates the four "overhead" words in the buffer...because they are likely to change. Besides, the word TX is written in machine code and should be quite fast at filling the buffer.

[ngkdc]

Good morning Randy,

Here's my initialization code:


DECIMAL



VARIABLE BUFFER1 203 ALLOT
BUFFER1 204 SCI1 TXBUFFER EEWORD

VARIABLE BUFFER2 83 ALLOT
BUFFER2 84 SCI0 TXBUFFER EEWORD

VARIABLE BUFFER3 83 ALLOT
BUFFER3 84 SCI0 RXBUFFER EEWORD

VARIABLE BUFFER4 19 ALLOT
BUFFER4 20 SCI1 RXBUFFER EEWORD


and here's what's returned:

SCI1 TX? . 1 OK
SCI0 TX? . 1 OK

I had thought I'd found the problem in the DO LOOP portion of my code that sends strings to SCI1, but I find the problem even with sending a single character to the serial port ( such as 88 SCI1 TX ).

Thanks,

Rick

[ngkdc]

An additional note ... per your recommendation, I changed my code so a machine was checking for characters in a buffer ready to transmit, and if there was a character, to send it. This also caused TCFOVFLO to increment.

What caused me initial confusion, was when I changed from 9600 baud to 19,200 baud on SCI1, the apparent cycle overflow (for lack of a better term) dropped ... TCFOVFLO didn't increase as fast, but still increased.

I then changed to CPUHALFSPEED, and increased SCI1 baud rate to 38,400 ... with no apparent change in the TCFOVFLO increment rate (I realize cycles are cycles ... I was trying to eliminate the serial transmission time ... and my display's maximum baud rate is 19,200).

Thanks,

Rick

[RMDumse]

Here's a real mystery. Look what happens when I download what you've sent me.

IsoMax V0.6
OK
DECIMAL OK
OK
OK
OK
VARIABLE BUFFER1 203 ALLOT OK
BUFFER1 204 SCI1 TXBUFFER EEWORD OK
OK
VARIABLE BUFFER2 83 ALLOT OK
BUFFER2 84 SCI0 TXBUFFER EEWORD OK
OK
VARIABLE BUFFER3 83 ALLOT OK
BUFFER3 84 SCI0 RXBUFFER EEWORD OK
OK
VARIABLE BUFFER4 19 ALLOT OK
BUFFER4 20 SCI1 RXBUFFER EEWORD OK
OK
SCI1 TX? . 200 OK
SCI0 TX? . 80 OK

So what we see doesn't tally at all with what you report.

Did you download just this much? or only with the rest of your program? Pls chk.

Did you update your kernel? Can you reload it again incase it was somehow corrupted?

[ngkdc]

Loading just what I sent you works correctly. I'll e-mail you my complete listing.

Thanks,

Rick