serial communication and multitasking

V

Volhout

New Member
I am building a test circuit for optical links
I can generate test sequences controlled from a keyboard
The keyboard and the test sequences are executed using 7 tasks in a 20M2


25340

As an afterthought I was planning to add a serial port control of the tester. The debug port (serrxd/sertxd) looked to be suitable.
So I added the 8'th task. Since the serrxd command is blocking (not a real UART but software UART) I added a 20ms timeout.

start7:
serrxd [20,start7],b0
.... rest of the code

I am running into a problem. The other tasks do not work anymore as before. Is it possible the serrxd command changes the 20M2 clock to 4MHz, but does not switch it back to 32MHz to comply with the multitasking timing ?
Am I doing something wrong ? Is there a way to achieve what I envision ?

I must admit that I turn to the picaxe platform for my projects often because of the simple multitasking (08M2 / 18M2 / 20M2). Did I plan 1 bridge too far this time ?

Thank you in advance for your help.

Volhout
 
The way multi-tasking works is to execute one command from one task, then execute a command from another, and keep doing that .

What is likely happening is, whenever the SERRXD is executed, it waits for 20ms. This will slow every task to a crawl.

The easiest solution would be to use HSERIN so commands can be sent in the background and the SERRXD can be replaced with a check to see if anything has been received without a long wait. An alternative would be to have a second PICAXE which can be asked if it has received anything in a similar manner which can then pass over what it has received.
 
Hi Hippy,

Thank you for your fast response. You must be right about the 20ms timeout.
As the board is already designed, your suggestion to use hserin is going to be ugly (to put it mildly), as I have used up all pins.
But I may be able to free up pin B.6 (hserin pin) from the key matrix. The C.0 pin (hserout) is not going to be possible. So I can't send back an "OK" for every well received command.

Again, thanks,

Volhout

Too bad we could not map hserin to C.6. That pin is input only.... I need outputs, not inputs....
 
It might be possible to do what you want without any changes.

If the Download Serial In is disabled with DISCONNECT the sender can assert that to indicate it has data to send. The task can check that without having to block, only blocking to tell the sender to send its data and while waiting for it.

Depending on what that sender is you might need another PICAXE to bridge between it and the test board but quite possibly not, and probably not if using an AXE027 from a PC..
 
Hi Hippy,

Please explain a bit more.....
I can add a disconnect.
I can use a check for the binary input level but in 8 task multitasking environment that could take several ms before I actually see it.
If I start a serrxd immediately after, I am too late to detect the start bit (even at 300 baud the start bit is only 3ms)

I reworked one board, freed up the hserin pin (B.6 on the 20M2) and connected it to a TTL-232RG cable (FTDI chip, 3.3V output logic levels).
According the datasheet the 20M2 defaults to TTL (not smitt trigger), so these levers should be fine. Checked on a scope.

my code
start7:
b0=0xff
hserin b0
if b0<>0xff then
debug
end if
goto start7

However in debug I do not see the ascii characters I send. also tried using w0 in stead of b0. No change.
Looks like the most significant nibble all bits are 1.

Init is:

hsersetup B9600_32, %00001000 (leave the hserout pin GPIO).

I am a bit puzzled, since I have no idea what is going on. The levels at the B.6 pin are okay. The timing is correct.
I tried different baudrates (B9600_4, B1200_4) with the same 9600baud input, but could not get it to behave as I wanted.

Regards,

Volhout
 
Volhout said:
hsersetup B9600_32, %00001000
Click to expand...
Multi-tasking operates at 16MHz so it would be worth trying B9600_16.

I would have still expected something to be showing up even at the wrong baud rate. It might be worth trying to get it to work in a non-multitasking program with everything else stripped out first, perhaps using SERTXD rather than DEBUG.

It doesn't seem my DISCONNECT trick would work for a 20M2 as there is no 'pinX.Y' which reads that input. One could link Serial In to HSerIn but that would need inverting. That could be done using the on-chip DSM but would probably require pins already used.
 
I'll try the B9600-16 Tomorrow. I was stupid to think the 20M2 with 8 tasks would run at 32 MHz.

Thans for Your support.
 
hippy said:
I would have still expected something to be showing up even at the wrong baud rate
Click to expand...

Hippy,

From Volhout's comment in post #5 it sounds like he is getting something received by the hserin code but that is is corrupt, with all the high nibble bits are being '1's

Volhout said:
However in debug I do not see the ascii characters .... Looks like the most significant nibble all bits are 1.
Click to expand...

Volhout,

Can you confirm I've understood you correctly?
i.e That the start7 code in post #5 is working in that it is detecting that the contents of b0 have changed from 0xFF to something else, that you see the contents of b0 being changed in debug but the changed value of b0 that you see in debug is not the byte you sent and has all the high nibble bytes set to 1.

FYI, the hserin chip has hardware to do the transmit and receive in the background and the serial hardware has a 1 byte receive buffer.
The hserin command just reads the contents of that receive buffer, if a new byte exists.
This means that if you send 1 character it will be received into that buffer by the 20M2 serial hardware and provided that you do not send a 2nd character your program can take as long as it likes to get around to reading it.
If you do send a 2nd character before your program has issued the hserin command to read the 1st then the serial receive hardware considers this an error condition and you will lose characters. So while testing using hserin in your parallel 20M2 program I recommend you only send 1 character at a time until you get it working.
 
Hi Flenser, Hippy,

First of all, I was receiving data, but it looked to have no relation to the data sent. And this is because the baudrate was wrong, AND the fact that RS232 sends LSB first. I had set the baudrate to B9600_32, and when the 20M2 internally runs at 16MHz, you get gibberish... (B9600_32 running at 16MHz is actually 4800baud, so the bit time is double that of 9600 baud, resulting in level changes in the middle of a UART bit period, you can guess the result....very unreliable).

Anyway, with B9600_16 all works as expected.

I plan to add an inverter from serin pin to hserin pin (a 2N7002 and 10k pullup), use disconnect.
Then I can use the hserin command for reading data, and the sertxd command from returning the acknowledge.
Of coarse I have to run at 4800 baud, for the PC terminal program.

EDIT: this works
 
Last edited:
For others who plan to do similar, I have to add 1 note.

The serial communication has (according to the documentation) a 2 character buffer. That is not the case. It has a 1 character buffer and the input shift register. But as soon as the new character is shifted in, that is transferred to the 1 byte buffer, and overwrites anything that was there.

In the multitasking system I use, it occasionally happens that 2 characters send "back to back" at 4800 baud (character=10bits = 2ms), the first character is overwritten before basic is able to get it.

In case you use hserin and hserout you can play with the baudrate (i.e. 1200baud), and then you would be fast enough to get both characters (or any number of actually). But since I combine hserin with serout (and serout is fixed at 4800 baud) I have to add a small delay between the characters on the PC side.

If you are typing characters from a terminal program you are okay (no way you can type that fast), and even the key repeat of your PC will be sustained. But a simple 2 character string sent, may cause problems.

Volhout
 
You must log in or register to reply here.
Back
Top