type and emit

[panorama]

Do these commands wait unti l there is no data in the uart, or do they put the data in the out buffer? I have a TXBUFFER assigned, but not sure if type and emit uses it.
The funny thing is that my program doesn't mess up, even though I should be over-running the buffer. I think it is because emit and type wait for room, but I would like confirmation this.

[RMDumse]

If you enable a TXBUFFER you turn on the interrupts for that channel, and if you output characters and there is room in the buffer, you return immediately from the EMIT, TYPE or TX call. If however, there isn't room, you go into a PCC loop, and don't come back until there is room.

So, this is kind of clever design on our part, if I may say so, that the program doesn't overrun, it just slows down. But! If you want to maintain rigourous real time operation, ensure there is room in the buffer before calling the output routine.

This has the same sense at the receive routines, you should first make sure there is a character available before calling KEY or RX, because if there isn't a character there, you will hang waiting for one.

From the manual:

TX might also wait, if a previous character hadn’t finished transmitting. But at least this wait won’t be indefinite: you know that the transmitter will send the character in a short time, and so you’ll have to wait at most one character period. But this might also be a problem in IsoMax code, so you can check to see if the transmitter can accept a character with
port TX? check to see if transmitter is ready for a character
TX? will instantly return a true (non-zero) value if the transmitter can accept a character now. It will return a zero value if the transmitter is busy, that is, if the transmitter is still sending the last character and can’t accept a new one yet.

[panorama]

Thanks,
I am checking the data with HyperTerminal, and noticed that sometimes a character is missing from the end of a string. I hope that is not a bug in your code, but in Hyperterminal, although it seems to happen only if the value is <0.
0 ( MAKE SINGLE TO DOUBLE
<# #S #> TYPE ( FORMAT, SEND TO PORT 0
So that with -5, for example, I just get the - sign.

[RMDumse]

Not a bug in the code, but a bug in you usage. The FORTH formating commands are special for handling negative numbers. You should look up SIGN et al.

[panorama]

Sorry, here is the real code:

DUP 0 < IF 2D EMIT ABS THEN ( IF NEG, OUTPUT SIGN & TAKE ABS
0 ( MAKE SINGLE TO DOUBLE
<# #S #> TYPE ( FORMAT, SEND TO PORT 0

For some reason, SIGN doesn't work for me. Maybe old ISOMAX.

Anyway, back to the question. How come I occasionally (0.001%)get only the sign, and no value? It looks like a possible txbuffer problem? By the way, the Plugapod with this problem is not that recent (maybe a year old). Haven't tried with a new one yet.

[RMDumse]

Use this for an example.

: D.R ( d \ n -- )
>R SWAP OVER DABS <# #S SIGN #> R> OVER - SPACES TYPE
; EEWORD

I don't think there is anything wrong with TX-BUFFER. I think you are using the <# #S #> wrong.

[panorama]

Thanks, looks like D.R does what I want. Just to check though, I don't know the length, so I just put 1. Is that safe in all cases? Seems to be from my testing, but want to make sure. I don't want any leading zeros or spaces.

I also noticed that I had an extra DUP in my code. This should have caused massive problems, but didn't. Does the stack get cleaned up when it returns to the scheduler?

Tim

[RMDumse]

The .R part means right justified. So the parameter is how many places you want to fit for a field. I'm not sure what the response would be if the number was larger than the field.