 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : How to put pauses in a COM port?
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Hi everyone. I have a serial stream I need to send using a MM170 chip, to a PICAXE based receiver unit. The 170 is too fast for the PICAXE and seems to be confusing the receiver, as all I get are garbled comms. Both are 2400 baud. Works perfectly with the PICAXE chip driving the RF module, but as soon as you put the MM on it, the message is garbled. Looking at the data stream with a logic analyser, I can see that the PICAXE is adding some native pauses in the datastream, as it build it based on what inputs it is getting. These delays are in the area of 4-6ms, but are just idle-high nothings in the data stream. THIS MATCHES WITH THE PICAXE RECEIVER, as it WAITS for the prescribed data before doing anything else, so you send the qualifier, and then the bytes. The PICAXE receiver sits there and waits for the qualifier, then inputs the data bytes. That all takes a few ms of time, and by that time, the MM170 has streamed the data past the point that the PICAXE is ready for it. I am having a HUGE amount of difficulty trying to replicate these delays in the MM, as the serial output buffer simply won't let me insert any delays in the data, and EVERYTHING is streamed out of the buffer one byte after another. The PICAXE receiver is missing data in other words, and when the it looks at the data stream again, it is in the middle of a byte(as sent from the MM), and all you then end up with is rubbish. Is there any way to insert pauses into the serial going OUT of the MM? The next thing I will try, is closing the serial port, waiting 5ms or so, and then reopening it to send the next bit of data. I can't think of anything other then that. I can change the design so that it uses an SOIC 08M PICAXE instead of the SSOP MM170, but I liked the idea of using the MM.  I may well do exactly that, as at least I know it will then work, as you have compatible chip types at both ends of the link.Does anyone have any clever suggestions? Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
The method that has worked for some is to configure the MM with 2 stop bits. That gives the required delay without you doing anything more. Edit : only works for COM1 Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Hey, I think you are on to something there, Jim!  A test resulted in PERFECT reception on the PICAXE receiver, if I changed the COM port command to: "COM1:2400,S2" I will now try the original code and see what happens, but this is a good sign.  EDIT: Yep, it now works fine with the original code set to S2. Before, all I was getting was gobbledegook. Thanks Jim - nice thinking.  Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Another possibility is to use the CFunction SerialOut function included in the Micromite firmware zip. That is not buffered so you could send one character, pause for a few mSec, etc. Come to think of it, you could do that with the normal serial comms. Send one character, pause 6mS, send the next, etc. At 2400 baud it takes 4mS for one character to clear the buffer so that would put 2mS between characters. Geoff Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Another good idea. Thanks. Never actually thought of doing it one character at a time in a loop - should have thought of that, but didn't.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5911 |
I forget who did the 'nice thinking', all I did was the 'nice remembering' The problem was solved here some time ago. Geoff: I think it would be a good addition to the micromite manual. Jim VK7JH MMedit MMBasic Help |
||||
Bill.b Senior Member  Joined: 25/06/2011 Location: AustraliaPosts: 225 |
Are you using N2400 or T2400 baud rate in the picaxe or invert the comms in the 170 program. I have communicated with a picaxe OK with T2400. This program sends text messages to a 14m2 (AXE134) OLED display. [code] OPEN "COM1:2400, INV, S2" as #1 pause 30 Print #1,chr$(254) + chr$(1); pause 30 Print #1,chr$(254) + chr$(128); ' or 192 for line 2 Print #1,"Hello world "; Print #1,chr$(254) + chr$(192); ' Print #1,"What a great Day"; Print #1,chr$(254) + chr$(148); ' Print #1,"to be alive"; [/code] Bill In the interests of the environment, this post has been constructed entirely from recycled electrons. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Both are T comms. I note you are also using the S2 option though, Bill.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Bill.b Senior Member Joined: 25/06/2011 Location: AustraliaPosts: 225 |
The comms on sample above is N2400 for the 14m2 (Standard for the picaxe AXE 133 OLED driver). Bill In the interests of the environment, this post has been constructed entirely from recycled electrons. |
||||
 Print this page |
