idle state of serial out pin

[womai]

I don't have access to a Picaxe the next few days (4th of July weekend...) to try it out myself, so I hope somebody else can answer this:

What is the idle state of the serial out pin (the one that gets driven by sertxd)? I assume it's low, correct?

The reason I am asking, I have a project where I am running short by just one output pin, so I thought I could (ab-)use the serial out pin. It would go to a counter reset, so I could do the reset by sending an arbitrary byte through sertxd (I don't care if this makes the output toggles a few times, as long as i toggles at least once from low to high and then back to low, and then stays there). At the moment that's on a 40X1, but later I'll use a 40X2 (when available).

I remember the there was a way on some Picaxe (the 18X?) to use the serial out pin as a regular output by using poke commands, but can't find that anywhere. Can somebody point me to the respective information? (Hippy?)

Thanks in advance,

Wolfgang

 

[hippy]

Yes, SERTXD idles low. The data bits are inverted so you can send a pulse of varying length SERTXD(value) will give ...

$FF - 1 bit
$FE - 2
$FC - 3
$F8 - 4
$F0 - 5
$E0 - 6
$C0 - 7
$80 - 8
$00 - 9

I'd have to check what the POKE would be for a 40X1

 

[womai]

Hi Hippy,

fast and concise as ever Thanks!

Toggling the pin with sertxd seems the best approach to me, because that should work independent of the specific Picaxe, while I assume poke may need different parameters for e.g. 40X1 vs. 08M.

Wolfgang

 

[nfk]

If you are using sertxd to communicate with a device that requires idle high, in normal circumstances would it be sufficient to invert the output?

 

[womai]

Yes, that's all which is needed. If your receiver wants CMOS or TTL levels (e.g. another Picaxe), you can use a standard 7404 or similar CMOS logic inverter. For true RS-232 levels (e.g. to communicate with a PC), i.e. +/-12V, you should go with a Maxim MAX232 or similar, which does both inversion and level conversion.

Wolfgang

 

[tiscando]

idling:

In the manual, it says that an inverted serial signal idles low, and a true signal idles high. When I have tested this in the programming editor's simulator and picaxe vsm, the serial pins idle low with a true signal and high with an inverted signal.

 

[Technical]

Nxxx baud rates idle low, with pulses going high.
Txxx baud rates idle high, with pulses going low

sertxd and serrxd are equivalent to N4800

 

[hippy]

The idea of "true" and "inverted" serial lines is something I've never got to grips with, along with "mark" and "space". I guess it all made sense in the dark ages of current-loop teletypes when you wouldn't be allowed near a PICAXE without a white lab coat, had to smoke a pipe, and the closest women were allowed to a computer was the punch-card machine.

The way I remember PICAXE baud rate selection is ...

"N" for "Normal. Idles 0V on the physical wire into the PC.

"T" for "The other one", "This won't work" when connected to the PC.

 

[Technical]

'T' is what you would traditionally feed into a MAX232 type chip to then connect to the computers serial port. But the MAX232 also inverts the signal, so the T signal won't work if you connect it directly to a computer serial port with a 10k/22k type arrangement. N is the inverse of T, so will work with the 10k/22k but not with a MAX232.

So
- for MAX232 type hardware use Txxx
- for 10k/22k type resistor setups use Nxxx

 

[leftyretro]

The idea of "true" and "inverted" serial lines is something I've never got to grips with, along with "mark" and "space". I guess it all made sense in the dark ages of current-loop teletypes when you wouldn't be allowed near a PICAXE without a white lab coat, had to smoke a pipe, and the closest women were allowed to a computer was the punch-card machine.

The way I remember PICAXE baud rate selection is ...

"N" for "Normal. Idles 0V on the physical wire into the PC.

"T" for "The other one", "This won't work" when connected to the PC.

Having started many decades ago with military teletype, I am aware how unintuitive it all can be. The old 20ma current loop was designed so the idle state was when current was activily flowing (on) keeping the machine's signal input magnet latched on. The first transition was the 'start bit' which opened the loop for 0 current. There after 'on' bit's were with current flowing and 'off bit's were with no current flowing, following at the end with a active on stop bit which remained steady on if there were no further characters being sent.

Back then the 5 bit baudot code (32 combinations) was used which required a pair of shift codes (letters/figures) to be able to handle all 26 uppercase letters and numbers and a few puntuation characters. There was also a 60ma current loop standard and also a bidirectional current loop standard that used +/- 20ma to encode the mark and space states.

Then RS-232 added more obsurity when they defined a 'on bit' or steady state mark condition of -3 to -30 volt state and a space (or zero bit) as a + 3 to +30 volt state. Of course they then went ahead and inverted that logic by defining the control signals (DSR, CTS, etc) opposite using a positive voltage as the active on condition and a negitive voltage as the off or zero condition. And of course there is the obscure definition of the signal receive and signal transmit terms that are easy to get confused unless you explicitly know which end of the cable is for the DCE end or the DTE end. Both ends transmit to each other but one sends on the rec signal and one sends on the tx signal! It's no wonder that simple serial links can be such a pain for new commers to get funtioning, and we haven't even touched on baud rate matching, parity bits, etc that can screw up the channel

That's why I've become a I2C fan for short communications circuits. While it does require software/firmware 'overhead' it takes away a lot of the hardware mystery and doesn't carry the burden of decades of legacy standards.

Lefty

 

[hippy]

One thing that surprises me is that others don't take advantage of the two-resistor interface on their product offerings. Okay it's not "RS232C compliant" but then again a lot of laptops aren't either. There are arguments for using a proper on-chip UART but not so much when it comes to downloading code; it just adds to the cost and real estate having to provide an inverter. A common excuse I've heard is that it won't work at high-speed or over long distances, but I've had it working at 115,200 ( not using a PICAXE ) and most people tend not to download to a chip half a mile away.

 

[tiscando]

I am having a real confusion of the idle state of a true signal and an inverted signal. in the code below, the 'high' command sets the true serial pins to '1', their supposed idle state, and as the program goes through the array of serout commands, in both the programming editor and picaxe vsm, after every inverted 'n' serial command leaves the pin high after it, rather than low, and after every true 't' serial command leaves the pin low after it, rather than high.
This poses a real problem with the serial LCD in the vsm simulator (see the attachment). the code I wrote below should output 32 from all the pins in different baud rates, and write to the serial lcd " qwertyqwerty".

when I run exactly this code below on the 28x1, the lcd shows " qwerty qpA r@A " instead, and if I put a 'pause 1' command after every 'gosub sendbyte', I then get " qwerty q w e r t y " (obviously with spaces between the letters)

now, If I put a 'low' command after every inverted 'n' serout command, and a 'high' command after every true 't' serout command, the serout n and low command would seem to output (data, 255) or something like that, rather than (data), so it doesn't fix the problem, and the lcd would show " █qwerty█qö7e0=7y█" with bars over the 7s or something like that, and with pauses after every 'gosub sendbyte': " █qwerty█q█w█e█r█t█y█" or something like that.

Can anyone fix this?

high 2,3,6,7'set the true serial pins to 1 (their supposed idle state)
setfreq m8
main:
pause 1000
serout 0,n1200_8,(32)
serout 1,n2400_8,(32)
serout 2,t1200_8,(32)
serout 3,t2400_8,(32)
serout 4,n4800_8,(32)
serout 5,n9600_8,(32)
serout 6,t4800_8,(32)
serout 7,t9600_8,(32)
pause 500
serout 7,t9600_8,("qwerty")
pause 1000
b2="q"
gosub sendbyte
b2="w"
gosub sendbyte
b2="e"
gosub sendbyte
b2="r"
gosub sendbyte
b2="t"
gosub sendbyte
b2="y"
gosub sendbyte
end

sendbyte:
serout 7,t9600_8,(b2)
return

 

[hippy]

in both the programming editor and picaxe vsm, after every inverted 'n' serial command leaves the pin high after it, rather than low, and after every true 't' serial command leaves the pin low after it, rather than high.

I've never observed that behaviour on any physical PICAXE I've used. Nxxxx baud rates leave the pin low after outputting, Txxxx leave them high.

The problem may well be with the PICAXE Simulator and/or VSM.

 

[moxhamj]

I agree with hippy - try it on a real chip. N leaves it low and T leaves it high. Also can you pls explain with the code what the high 2,3,6,7 is doing - if you want the pins to be low.

 

[tiscando]

N leaves it low and T leaves it high. Also can you pl(ea)s(e) explain with the code what the high 2,3,6,7 is doing - if you want the pins to be low.

I used pins 0,1,4, and 5 for transmitting inverted 'n' serial so they should be idle low. pins 2,3,6, and 7 are for transmitting true 't' serial so they should be or idle high. that is why I have included 'high 2,3,6,7' in the start of the program.

Hippy, this is a problem to both the programming editor and picaxe vsm.

 

[hippy]

this is a problem to both the programming editor and ...

You mean in the simulator ?

I guess you do, I just tried this for an 18X ...

Do
SerOut 7,T4800,("U")
High 7
Loop

The leg only 'goes green' after the High not after the SerOut. Using N4800 and Low 7 it goes green after SerOut whe it shouldn't. Looks like behaviour for handling SerOut baud rates has been inverted so should be easy enough to fix -- and I think it proves the case that "Normal", "True", "Inverted" is darn complicated to get right

So that's agreed then; there's a bug in the Simulator and it appears a similar bug in VSM.

 

[tiscando]

You mean in the simulator ?

yes, I mean the programming editor's simulator.
Both designers of PE and VSM probably have got mixed up with the idle state of the picaxe pins after serial data is sent from the pins. it really causes a problem with the axe033 lcd in vsm. edit: for PE's simulator, on a serout command, I would suggest the relevant virtual pin on the simulation controller's picaxe drawing to rename "ser?" where ?=pin number, and for an 'N' signal, flash high(light) and idle low(dark), whereas for a 'T' signal, flash low(dark) and idle high(light).

 

[Technical]

We'll look into these simulation issues.