Using the programming port serial lines for general serial comms

[photomankc]

Hello all,

I'm a recent newb to the PICAXE world coming from the Arduino/Parallax Prop background. Part of the design for a robot I'm working involved using the PICAXE to handle some of my sensor work so the main controller can spend time doing high level work not dinking with polling sensors. One place I wanted to use it was monitoring about 8 IR proximity sensors and then allowing the main processor to querry the state via serial so rather than 8 lines it could use just two. My long term plan was to use I2C but I bought the 18M2 before I understood they can't do I2C slave mode. Anyway I wanted to see if I could make lemonade anyway with the 18M2 while I wait for the 20X2.

The idea is that it has 4 lines that act like a standard priority encoder so it outputs 0-7 binary on three lines plus an Attention line that indicates some input is active. In addition I want it to stream out data over a serial output when any sensor is tripped. This means you can get the full binary value not just the single highest bit and just 1 pin is really needed as long as you can live with the timing of serial. I have that working and I've used just about all the pins now. One pin is used to select either a 20ms or 50ms debounce cycle so I think I have one more left over besides the programming tx/rx pins.

For now, I have been using the sertxd to send the stream over the programming tx pin. Works fine. However, as I understand it that is inverted from the normal serial signal that most other devices would expect so that's not the ideal way to do go I think. I guess I can use that one last pin for the high speed serial setup but I was kind of hoping to think of a way to use that pin to allow for making it more programmable (debounce delay, debounce cycles, ect). I see a few places where I can use this for a number of tasks like buttons, PIR sensors, bump switches, and others so I'd like to keep it flexible.

As it stands now:
B.0 - B.7 are Inputs
C.0 - C.2 are the Priority Encoder outputs (0-7)
C.7 is the Attention output
C.5 is the 20/50ms selection input
C.3-C.4 are the programming pins
C.6 is open


So in summery:

Is the output from sertxd always inverted, can I change that in other than a hardware solution?


Even if not I think it may be worth it to add a hardware inverter because I could then keep the other open pin for use as a background serial recieve with hserin to allow programming it a bit and maybe also go from streaming the serial value to only sending it when requested.

Hope I didn't ramble too much here.

 

[Technical]

Welcome to the forum.

Depends on what you mean by 'inverted', but sertxd is always the signal a computer expects (idle low, active high). However on 18M2 that pin is also C.3, so you can just use 'serout' instead of 'sertxd' and choose baud/polarity as you wish.

 

[nick12ab]

Welcome to the PICAXE forum.

For now, I have been using the sertxd to send the stream over the programming tx pin. Works fine. However, as I understand it that is inverted from the normal serial signal that most other devices would expect so that's not the ideal way to do go I think...

Is the output from sertxd always inverted, can I change that in other than a hardware solution?

By non-inverted I'm assuming you mean Arduino-standard rather than PICAXE-standard - A resistor connection to the PC uses what you call "inverted".

If you use a PICAXE that allows you to use the serial out pin as a normal output (08M2, 14M2, 18M2, 20X2, 28X2, 40X2 and others, not 20M2) then you can use a serout command which allows you to select the polarity - use Nbaud for same polarity as sertxd or use Tbaud for opposite polarity (see link). The same can be done on the Serial In pin if it can be used as a normal input - use serin instead.

 

[photomankc]

Ah thank you folks I did not get that you could do the normal serial right over the top! As is often the case just after I pose the question I finally stumble on the answers in the data-sheets (doh). It's not going to be possible to both mantain the timing I want in the debounce routines and take incomming serial commands because the high-speed serial lines are right in the middle of the input group I need and I dont want to deal with fragmenting that over non-contiguous pins. The 18M2 version of this idea is going to have to remain fairly dumb.

The 20X2 should open up a lot of possibility since I will be able to send and execute commands to setup the timing, loops, and control some of the I/O.

 

[photomankc]

Welcome to the PICAXE forum.

By non-inverted I'm assuming you mean Arduino-standard rather than PICAXE-standard - A resistor connection to the PC uses what you call "inverted".

Yes, in order to use my existing FTDI serial cabels (not PICAXE) I had to use FTPROG to check all the "invert" options for TX and RX to get it to program the PICAXE or talk to it at all. That is not needed for my other controllers so I assume also they would require inversion to talk to the PICAXE too? That's kind of confusing me honestly. I get in enough trouble reversing TX/RX between devices then you add inverted signals and my scattered brain ties itself in knots. Sorry if 'm being dense on this.

 

[Technical]

It is confusing.

FTDI chips (and other USB chips) are primarily designed to interface to MAX232 type chips to create a full USB adapter. The MAX232 type chips also invert the signal.

So, compared to a traditional real 9-way serial port, the default FTDI chip signal is inverted. Because FTDI inverts once and then MAX232 inverts again, so FTDI+MAX232 = same as a real serial port.

Because PICAXE does not use a MAX232 type chip you have to invert the FTDI from what it normally does. But you could argue this is actually 'un-inverting' it!

So rather than talk about 'inverted', which could mean anything, it is much more precise to talk about 'idle high' (Txxxx) or 'idle low' (Nxxxx).

 

[photomankc]

Thanks for setting me straight on that! I'll have to remember that when talking about it in the future.

 

[davehouston]

So rather than talk about 'inverted', which could mean anything, it is much more precise to talk about 'idle high' (Txxxx) or 'idle low' (Nxxxx).

I have to disagree strongly. I've programmed PICs and AVRs sporadically for 10-12 years using a few different languages and all are consistent in referring to RS232 signals as inverted - until now. An article in EETimes on Positive vs Negative Logic explains the conventions that are used almost universally, saying "Using the positive logic convention, the more positive potential is considered to represent True and the more negative potential is considered to represent False (hence, positive logic is also known as positive-true)." Other terms used are active high (positive logic) and active low (negative logic). Upending these time-honored conventions might leave folks wondering which way is up.

The signals to/from a PC serial port are inverted (i.e. active low) and, at least with original PCs, use RS232 voltage levels. You usually need both logic inversion and voltage conversion to interface them to PIC/PICAXE. MAX232 and equivalent chips do both, inverting the logic and converting the voltage levels. Most PIC hardware UARTs use positive (active high) logic and software UARTs can use either. Most PIC/AVR digital inut pins have clamping diodes to protect them from overvoltage so you can directly interface with higher voltages as long as you include a current limiting resistor to keep the current within the limits the chip can handle. (NOTE: There may be issues when interfacing higher voltages to pins with ADC capability.)

For PCs without serial ports, USB-to-RS232 cables/adapters provide the same inverted logic as a standard RS232 port. I'm totally new to PICAXE and unfamiliar with the various auxilliary hardware but, if the serial programming cable works with a standard PC serial port, it should also work with a USB-to-RS232 adapter. I've used similar Prolific PL2303 based adapters, without issues, under Windows/Linux/OSX. although I haven't tried them under W7 or the latest OSX version.

Another useful bit of hardware is an RS232-to-TTL converter which includes a MAX3232 IC. It inverts the logic and can convert to 5V or 3V3 voltage levels.

 

[hippy]

The signals to/from a PC serial port are inverted (i.e. active low)

If you put a scope or volt meter on 0V and TX from a PC 9-way D RS232C port you will read -V when nothing is being transmitted and read +V pulses when something is being transmitted.

And in that sense it is consistent with a definition of positive logic, active high, going to a higher potential when active.

Hence why Technical says ( and I agree ) that the use of inverted and non-inverted does get confusing to people who are not familiar with serial communications, even gets confusing to people who are familiar with serial communications.

 

[davehouston]

If you put a scope or volt meter on 0V and TX from a PC 9-way D RS232C port you will read -V when nothing is being transmitted and read +V pulses when something is being transmitted.

Ahhh! I see the problem. You folks really do not understand RS232 (which predates PCs by several years and where a '1' is -12V and a '0' is +12V; IOW NEGATIVE logic). Something is being transmitted when the apparently idle line reads -V, that's the STOP condition. There's an really good PIC-RS232 tutorial that might be helpful. While it uses ASM it's explanations are clear.

The EETimes article is from the POV of the 5V logic ICs and that's the POV usually taken in discussions about PICs and other embedded devices.

 

[Jeremy Harris]

Ahhh! I see the problem. You folks really do not understand RS232 (which predates PCs by several years and where a '1' is -12V and a '0' is +12V; IOW NEGATIVE logic). Something is being transmitted when the apparently idle line reads -V, that's the STOP condition. There's an really good PIC-RS232 tutorial that might be helpful. While it uses ASM it's explanations are clear.

The EETimes article is from the POV of the 5V logic ICs and that's the POV usually taken in discussions about PICs and other embedded devices.

I agree, but then I grew up dealing with RS232 when it was used to drive teleprinters, with just the correct logic sense you describe. Quite why some folks seem to think that RS232 should use positive logic by default I don't know, as it's always been a negative logic system, right from how ever many decades ago it was that it was first standardised.

 

[davehouston]

...it's always been a negative logic system, right from how ever many decades ago it was that it was first standardised.

It dates to 1962 as a standard.

And I go back nearly that far using it for teletype, etc. It was also used industrially with Programmable Logic Controllers.

 

[Jeremy Harris]

It dates to 1962 as a standard.

That's pretty good going, 50 years on and we're still using it every day. There can't be many electronic standards (outside the military) that have lasted as well.

 

[hippy]

Ahhh! I see the problem. You folks really do not understand RS232

You will find we have a pretty good grasp of RS232 ourselves, but it's the issue of confusion for others which forms the basis of our suggestions.

Reference to "idle low" and "idle high" signalling are not incorrect and have proven to be very useful in describing serial polarities to PICAXE ( and other ) users.

 

[Jeremy Harris]

Reference to "idle low" and "idle high" signalling are not incorrect and have proven to be very useful in describing serial polarities to PICAXE ( and other ) users.

I agree with this bit, but with the observation that idle high is the normal RS232 form, whilst idle low is inverted RS232. I think the use of the term inverted to describe idle low is spot-on, but accept that when we're talking about logic level serial comms it seems commonplace to incorrectly refer to idle high as being the inverted form, probably because people have become used to active high in the years since the RS232 standard was laid down. It's the same inversion in thinking that has occurred with power supplies, when I started out the negative rail was pretty much always the supply, with the ground being the positive supply, a convention that arose in the first ten or twenty years of the transistor era, when PNP transistors were the norm.

 

[davehouston]

You will find we have a pretty good grasp of RS232 ourselves

No - I find you're pretty clueless about this and many other aspects of PIC communications and that you feed the confusion rather than clarfying things. I've been evaluating PICAXE to see whether I want to support it on some hardware I designed to use PICs and AVRs. I've seen enough and will waste no more time on such a brain-dead (and dead-end) approach.

 

[SAborn]

If you designed hardware for pic or avr why would you even consider stepping back to a picaxe, its like saying you own a porsche but wonder if you should buy a volkswagen.

I would not say Hippy is clueless, his help and advice has helped many here, where other glorified experts are happy to attack one or two lines in a post, but offer little help to actual problem solving on the broader spectrum.

 

[papaof2]

I've seen enough and will waste no more time on such a brain-dead (and dead-end) approach.

Not to mention the other people's time that you have wasted.

Had you read and absorbed the intent of the PICAXEs (education, mostly pre-college) you might have understood the reason for simplified explanations of RS232-like serial communications.

By the way, is it still RS232 if the levels are 0 and +5 instead of +/- 12 or +/- 15, or is it just serial communications?

John
(With a lot more serial comms experience than I ever wanted: at one point I managed a nine state DataKit network with dozens of nodes and hundreds of serial terminals talking to UNIX boxes.)

 

[Technical]

For PCs without serial ports, USB-to-RS232 cables/adapters provide the same inverted logic as a standard RS232 port. I'm totally new to PICAXE and unfamiliar with the various auxilliary hardware but, if the serial programming cable works with a standard PC serial port, it should also work with a USB-to-RS232 adapter. I've used similar Prolific PL2303 based adapters, without issues, under Windows/Linux/OSX. although I haven't tried them under W7 or the latest OSX version.

We think this statement actually proves our point about why it is confusing for newcomers (those who do not understand the polarity issues). A prolific PL2303 universal adapter (USB-9way D) ALWAYS contains two chips - the prolific chip + a MAX232 equivalent. This signal is the same as a real COM port and so works as a real port would.

However the original poster was not actually talking about this type of universal converter cable at all - he was talking about a raw FTDi chip cable (ie a cable that only contains the one chip). This is a USB to TTL and does *not* contain a MAX232 - the raw FTDI signal is output as the TTL signal.

The default signals coming out of these two different types of cables would be the opposite of each other. This is where the confusion arises with beginners - is my cable a true COM port emulator or not? Is the signal the same as a real COM port or not? Experienced engineers can argue all day about the correct terminology - but beginners simply want to know which signal/setting is correct and what signal they should see on their multimeters....

The signals to/from a PC serial port are inverted (i.e. active low) and,

Anyone who has ever used the FTDI cable setup tool will know that one of the options is to 'invert tx/rx' signals. It uses the word invert to mean 'swap over the polarity'. That is why the term 'invert' is confusing for FTDI cable users - invert does not mean a certain condition in the MProg cable setup tool, it means make it the opposite. See why people may get confused by that word? If you do select that 'Invert TXD' checkbox and program your FTDI cable, your cable will now be active high, not active low....so is that inverted or not....

 

[Goeytex]

No - I find you're pretty clueless about this and many other aspects of PIC communications and that you feed the confusion rather than clarfying things. I've been evaluating PICAXE to see whether I want to support it on some hardware I designed to use PICs and AVRs. I've seen enough and will waste no more time on such a brain-dead (and dead-end) approach.

@davehouston

Your misunderstanding of the terms used here and your insistence upon only defining things in your terms does not make someone clueless.
When I am here I call an IC pin a "leg". When I am talking with my EE buddies a pin is still a pin. It's not that hard really ......

 

[Jeremy Harris]

To be fair, all davehouston has done is point out the correct way of referring to RS232, which is idle high as the normal form and idle low as the inverted form (which doesn't officially exist in the standard, AFAIK). Sure language got a little warm, but the guy had a good point - the RS232 standard uses negative logic (and also defines the other aspects of serial comms we now use, like specifying the number of bits, the use of start and stop bits, the use of parity etc).

We've got sloppy, and frequently now refer to RS232 (incorrectly) as being positive logic (i.e. idle low), when we should at least have the decency to recognise that true RS232 is a negative logic standard (idle high). The terminology change seems inevitable, given the evolution of technology, but perhaps we should really (if we're being pedantic) make a point of not adding to the confusion by using terms like "inverted" when referring to serial comms. To do so invites confusion, for many will assume (correctly, as I would) that inverted is idle low.

 

[photomankc]

Wow.... I poked a sore spot somehow! Nice first post eh?

I've got a couple other questions as I have more or less settled what I can do with serial on the 18M2. One weirdness I ran into is that my loop and code seem to run wildly different periods even when the same inout is triggered. My 20ms loop is only a very rough 20ms sometimes 10 sometimes closer to 30. I understand some jitter and I am not looking to hit it on the nose but I'm a little shocked that the scope is showing +/- 10ms of variation in the time between an input falling low and the time the ATTN signal is raised high.

Testing the same input line should result in the same path through the code each time. The serial port should take the same amount of time to transmit the byte. Instead it seems like the more loops it runs the more wildly the delay can fluctuate. I've attached the code if anyone can see something stupid I'm doing in there?

I also wondered if there is a way to access a PIN in an if statement by name like "if PROG1_IN = 1" rather than "if pinC.5 = 1". The compiler will not allow the symbol name in most any assignment or test condition that I can see and trying to do math with it resulted in unexpected results. Seems the lable really is a number not an indirect reference to the pin so trying to use it in assingments results in getting that number not the pins state.

Code attached

 

[SAborn]

Inverted just means what was high is inverted to low and what was low is inverted to high, so whats to be confused about inverted data, if its inverted than its the opersite of what it was originally, who cares if it is idle low or high, its been inverted.

There seems to be one argument for what is true rs232 and another for what is inverted data.
To be honest the bickering of correct terminology has made this thread so confusing for picaxe use its a joke.

For picaxe use if the serial line to the programming port is held idle high then nothing would work with the programming cable attached, as the picaxe would keep expecting a program download.

 

[Technical]

"if PROG1_IN = 1" rather than "if pinC.5 = 1"

just keep the terms the same and it will compile:

symbol PROG1_IN = pinC.5
if PROG1_IN = 1 then...

 

[Paix]

I'm tending to think that the evaluation was a beast like the unicorn or badly thought out from the onset, given the stated origin.

Strange that one so pedantic and supposedly learned mentioned the "Stop" condition. Rather than a holding Mark condition; the opposite being the Spacing or Space condition. That said, it is very easy to become disoriented when talking about signaling levels, whether RS232 or the 80-0-80V that preceded and lived along side them.

Keeping it simple attempts to avoid confusion and therefore has my vote. Not many young students have the experience to appreciate some of the subtleties that have come to us from our technological legacy systems and the need to interoperate with them in the past, if not currently.

I also agree with GoeyTex. It takes a bit of getting used to "legs and pins", but it works and saves head scratching for many.

 

[Jeremy Harris]

For picaxe use if the serial line to the programming port is held idle high then nothing would work with the programming cable attached, as the picaxe would keep expecting a program download.

True, as the Picaxe uses inverted, logic level, RS232 as its normal protocol. The world of serial comms is, however, much bigger than just the Picaxe, and the agreed international standard is idle high, which is the point that davehouston was correctly, if a little robustly, making.

It's taking this thread off track though, as the point has really been made that the Picaxe (along with a few other logic level serial comms devices) uses a non-standard, inverted, RS232 protocol as its normal serial comms format.

 

[srnet]

as the point has really been made that the Picaxe (along with a few other logic level serial comms devices) uses a non-standard, inverted, RS232 protocol as its normal serial comms format.

'Standards' and RS232, should not, in my experience, be in the same sentance.

 

[KeithRB]

Is the PicAxe the DCE or DTE? 8^)

Is now the time to bring up current loops?

 

[srnet]

Is now the time to bring up current loops?

Only if they are 20ma 'standard' current loops.

 

[photomankc]

"if PROG1_IN = 1" rather than "if pinC.5 = 1"

just keep the terms the same and it will compile:

symbol PROG1_IN = pinC.5
if PROG1_IN = 1 then...

Well....

I see there is some dependence on how you define them

PROG1_IN = C.5 will not work with the if statements but generally all the other commands seem to like this notation
PROG1_IN = pinC.5 will work in the if statements but then all the other commands like high, low, serout, complain about needing PORT.PIN notation.

 

[Goeytex]

We've got sloppy, and frequently now refer to RS232 (incorrectly) as being positive logic (i.e. idle low), when we should at least have the decency to recognise that true RS232 is a negative logic standard (idle high)....

Jeremy,

I have not seen anyone here refer to "RS232" as positive logic (idle low) where a high state is a data 1...(particularly Hippy and Technical) That I think, is being incorrectly inferred by some RS232 "experts" , when what is being referred to is simply the state of the serial data line. It seems to be a case of equivocation, where "serial" is being equivocated with "RS232" which of course will lead to erroneous conclusions, like for example, that someone is "clueless", or that "you folks don't understand RS232."

As I read the thread I also noticed that "inverted" in regards to a data signal (regardless of polarity) was being equivocated with inverted logic which also led to a fallacious conclusion.

Fairness is reading the black part of the page (the ink) and not the white parts ( between the lines), and actually attempting to understand what is being said as opposed to equivocating terms and building a strawman argument with ad hominem attacks to prove oneself "right".

 

[Technical]

PROG1_IN = C.5 will not work with the if statements but generally all the other commands seem to like this notation
PROG1_IN = pinC.5 will work in the if statements but then all the other commands like high, low, serout, complain about needing PORT.PIN notation.

Correct. When you refer to a pin number (e.g. commands such serout or serin) you use the pin number C.x - 'do this action on a particular pin'

However in if...then you are doing something different - you are reading the pin variable, the state of the pin, which is either a 0 or a 1. Because this is a variable rather than a constant (see how it syntax colour codes) you use pinC.x, the name of the variable that contain either 0 or 1.

As to your other issue, take the first case of a single loop (loops = 1). You read the inputs once (within the loop) and then do a pause. Now consider when the input changes (something you cannot control, and so will vary). If it changes just before the pinsB read, it will be almost immediately noticed. But what if it happens just after the loop, before the 'pause' command - you have to wait the entire pause time, do the other two subs, loop around back to the for..next loop and only then will the input change be noticed by the next pinsB read. So there can be a big variation in processing time dependent on where you currently are within your program when the input actually changes.

 

[Jeremy Harris]

Jeremy,

I have not seen anyone here refer to "RS232" as positive logic (idle low) where a high state is a data 1...(particularly Hippy and Technical) That I think, is being incorrectly inferred by some RS232 "experts" , when what is being referred to is simply the state of the serial data line. It seems to be a case of equivocation, where "serial" is being equivocated with "RS232" which of course will lead to erroneous conclusions, like for example, that someone is "clueless", or that "you folks don't understand RS232."

As I read the thread I also noticed that "inverted" in regards to a data signal (regardless of polarity) was being equivocated with inverted logic which also led to a fallacious conclusion.

Fairness is reading the black part of the page (the ink) and not the white parts ( between the lines), and actually attempting to understand what is being said as opposed to equivocating terms and building a strawman argument with ad hominem attacks to prove oneself "right".

Look, I'm not going to get into a pointless argument over this, and I would also point out that I didn't, and haven't, made any disparaging remarks to, or about, anyone.

All I have done is point out (quite reasonably, IMHO) that the serial comms protocol that we use is based on the very old RS232 standard, is often referred to as RS232 (here and elsewhere) and, apart from using 0 V and +5 V (rather than -12 V and +12 V) is essentially identical to RS232 in terms of data format. It is simply wrong to say that idle high is the "inverted" form of serial comms, again IMHO, but perfectly OK if we define protocols as being "idle high" or "idle low", rather than "normal" or "inverted".

 

[photomankc]

As to your other issue, take the first case of a single loop (loops = 1). You read the inputs once (within the loop) and then do a pause. Now consider when the input changes (something you cannot control, and so will vary). If it changes just before the pinsB read, it will be almost immediately noticed. But what if it happens just after the loop, before the 'pause' command - you have to wait the entire pause time, do the other two subs, loop around back to the for..next loop and only then will the input change be noticed by the next pinsB read. So there can be a big variation in processing time dependent on where you currently are within your program when the input actually changes.

Yep, I was idealizing the conditions in my head. No way around that. The longer the loop the more likely the input can change.... even in the middle of an exiting loop which would obviously add a significant delay until it can complete and come around again and get all the way through the next loops in the same state. So all I can really quantify is the minimum delay time for a single loop though it could at times be very close to double that. Thanks I was mentally placing the trigger at the start of the loop each time but that perfectly describes the scope timing.

 

[Goeytex]

Look, I'm not going to get into a pointless argument over this, and I would also point out that I didn't, and haven't, made any disparaging remarks to, or about, anyone.

I was referring to Mr Houston.

 

[photomankc]

Yep, I was idealizing the conditions in my head. No way around that. The longer the loop the more likely the input can change.... even in the middle of an exiting loop which would obviously add a significant delay until it can complete and come around again and get all the way through the next loops in the same state. So all I can really quantify is the minimum delay time for a single loop though it could at times be very close to double that. Thanks I was mentally placing the trigger at the start of the loop each time but that perfectly describes the scope timing.

Ok so I sat and thought tonight. Didn't really care for the up to 100% additional delay depending on where the loop happened to be. What will this device spend the vast majority of its time doing? Waiting for any pin to go low. Why spend all that time looping through code that we aren't using unless an input is triggered? So just before the debounce loop is entered I placed this:

 	Hold: 	
 	let temp = pinsB
 	if pinsB = 255 and pinC.7 = 0 then goto Hold

This has made it 100% better. The times are now much more predictable within a fraction of a millisecond. The hold code doesn't execute till all the inputs are back to quiet states so it would not impact the potential wild delays if more than one input becomes active but my robot would spend the vast majority of life with no sensor ever tripped so this should work great. Thanks for helping me talk it out. Feel like I have a decent design for if I decide not to muck with I2C for this function.