 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 : UART problems - porting from PICAXE to MM2...
Page 1 of 2   |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
I am having a real head-scratching moment, trying to work out WHY code ported from a PICAXE to the MM2, will not work. Listening to the data burble on a scanner radio, the MM2 driven unit sounds like it is transmitting the data FASTER then the PICAXE is, even though the baud-rate is the same.  PICAXE CODE: '--------------------------------------- 'QUALIFIER AND MAIN MESSAGE SUB-ROUTINE: '--------------------------------------- address: high ENA 'Enable NTX2 module high TXD 'Make sure data pin in correct state pause 10 'Allow module to wake up - must not use nap, or module will not wake up. serout TXD,T2400,("UUUUUUUUUUUUUUU") 'Send 15 U characters(10101010) to sync data slicer in receiver serout TXD,T2400,("[1234]") 'Send qualifier serout TXD,T2400,("000 TESTUNIT_") 'Send address specific code return MM2 CODE snippet I am running, just till I can work out what is stopping it from working: I'm quite lost with this. Both the PICAXE and the MM2 are set for 2400 baud, both send the same data, and I made sure to wait at the end of the MM2 code till the output buffer is empty before closing the port and disabling the RF module. The unit based on the PICAXE chip ALWAYS decodes fine at the other end. The unit based on the MM2 chip NEVER decodes correctly at the other end. As I say, they SOUND different 'On-Air', which is suspicious. The PICAXE one is a nice clean burble of data. The MM2 one is just a short blip and it's over, so I think there is definitely some speed issue going on here. The PICAXE serout command is bit-banged, whereas the MM2 has a hardware UART, so I am wondering just how much latency there actually is in the PICAXE bit-banged serial - perhaps quite a lot? Does anyone have any ideas what I am doing wrong? Edited 2021-07-06 16:11 by Grogster Smoke makes things work. When the smoke gets out, it stops! |
||||
TassyJim Guru  Joined: 07/08/2011 Location: AustraliaPosts: 5878 |
This looks like the same problem you have had before. The picaxe is slow so change the MM code to 2 stop bits. This will slow the data down a bit. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
You remember my problems better then I do!  I will try that. Had totally forgotten that..... EDIT: You were SO right, Jim. Thank you so much.   All working perfectly now! Edited 2021-07-06 16:38 by Grogster Smoke makes things work. When the smoke gets out, it stops! |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1588 |
I believe that the transmission of the Picaxe is inverted compared to the Micromite? see here Bill Edit: try INVerting the serial. Edited 2021-07-06 16:43 by Turbo46 Keep safe. Live long and prosper. |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
Hi Bill.  Only sertxd is inverted. T2400 is standard non-inverted, which matches the MM2 UART. Jim was spot-on with his S2 suggestion, and it is decoding just fine at the other end now, so we're all good now. I am kicking myself for posting this thread really, as I should have remembered that from last time.....(needing the two stop-bits) Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
This problem is back.  I have moved from an older PICAXE 08, to an 08M2+ as I needed more space to add extra data filtering etc, and again the messages are garbled. I tried removing the S2 from the com port on the MM code and trying again thinking the 08M2+ might be quicker at processing data, but it makes no difference if I use S2 or not this time - the message is garbled with either setting. Does anyone have any suggestions? Jim - you seem to be the guru with PICAXE...  Smoke makes things work. When the smoke gets out, it stops! |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5878 |
Time to break out the CRO/logic analyzer and compare the new transmissions with the old. That will show the inter-byte timing. Jim VK7JH MMedit MMBasic Help |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
OK, I will setup my logic analyzer and capture both the PICAXE data output and the MM2 data output. I've just tested the PICAXE code with a PICAXE-based transmitter unit, and it works perfectly. It is just the MM2 transmission that refuses to decode at the PICAXE end of things. I'll post some images on this thread once I have had a chance to do the samples. Smoke makes things work. When the smoke gets out, it stops! |
||||
Justplayin Guru Joined: 31/01/2014 Location: United StatesPosts: 307 |
Hey Grogster... I see you are using the hardware based COM1 on the MM2. Have you tried the software based COM2 or CFuntion serial port to see if the timing is better for the PICAXE? --Curtis I am not a Mad Scientist... It makes me happy inventing new ways to take over the world!! |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3490 |
You use an RF link. Try wiring the picaxe to the mite directly. PicomiteVGA PETSCII ROBOTS |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2285 |
it could also be worth experimenting with different values of option clocktrim to ensure your mx170's internal clock isn't sitting at the limit of what the picaxe can decode. have the mx170 generate a 10khz tone using one of the PWM outputs, measure the output with a frequency counter and then adjust with option clocktrim if it is more than a smidgen off. i believe you can trim up to +/-31. i don't know how picky the picaxe's are over errors in the serial speed, but worth a crack. cheers, rob :-) |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
Hi there Good idea. I tried it, but it made no difference at all. Was hoping it might! I have captured the PICAXE data, I am now just doing the MM2 data then I will post images and SaelieLogic data files in a ZIP. Smoke makes things work. When the smoke gets out, it stops! |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 5705 |
I trust you are using direct wire-wire connection (or at least nothing in the way apart from passive stuff)? Have you tried the slowest possible baud rate and putting LEDs on the data pins? With the logic analyzer you could get both to send the same thing and compare the tx streams. Then try loopback on both, if they are both the same. That would rule out tx problems. If tx aren't both the same then you need to look at that. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
There is a difference now that I have both data captures. PICAXE output:  MM2 output: (this is with the S2 option on the COM port)  Here is a ZIP file with both of those images along with both SaleaeLogic data captures: PICAXE_MM2.zip There IS a distinct gap in the PICAXE data stream that is not there in the MM2 data stream. Seems there is about 1.4ms delay between each and every byte on the PICAXE, which is not the case with the MM2 output. This will simply be the PICAXE interpreter delay I think. Perhaps I could re-write the MM2 output so that it takes the string, and outputs it one byte at a time, followed by a 1ms pause or something. I might experiment along those lines. If any member has a SaleaeLogic, I would appreciate you looking at the captured data and letting me know any thoughts you might have. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
I have a working solution.....standby.... Smoke makes things work. When the smoke gets out, it stops! |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
It is now working. Putting a pause between bytes using the hardware UART did not work, as the output buffer just joined them all together again - as you would expect for a hardware UART buffer when you think about it. Borrowing from Justplayin's suggestion, I used the bit-banged serial Cfunction, and output the bytes one at a time. I don't even need a delay in that situation, as the natural FOR/NEXT interpreter delay introduces just enough of a pause between bytes, that the PICAXE decodes the message perfectly. My new testing code that is working:  ....and ZIP file of logic data, if anyone is interested: Data captures.zip Smoke makes things work. When the smoke gets out, it stops! |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3490 |
The same would have worked on the HW UART. Do not feed it a string, but a character at a time, and add delays in between. Or you just may be saved by adding 2 stop bits and parity(you throw away, but it is another bit delay) Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
I did try that(FOR/NEXT to the H/W UART), but it did NOT work, and the logic analyzer showed that the actual output from the UART buffer had ignored the delay I tried to introduce that way, and essentially stapled all the bytes together again into one continuous stream, totally ignoring any introduced delays between the bytes. I can understand that, when you think about how a data buffer works.  By its very nature, the buffer - is a buffer, and is designed to collect the data together before sending it out the UART, so that method did not work. But I did try it. Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
The firmware will pass the character to the UART (and the UART will immediately start transmitting it) the moment the program sends it to the COM port. The firmware will only buffer the character if the UART is already busy transmitting a previous character. Perhaps you did not have a big enough delay. At 2400 baud it will take 4.2ms for the byte to be clocked out by the UART so, if your delay was less than that, the firmware will be forced to buffer any subsequent characters. You need a pause greater than 4.2ms. For example, if your pause was 6ms, that would cause a delay of 1.8ms after the last bit left the UART. Geoff Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9041 |
Oh, OK, looks like I was wrong on that one then - sorry Volhout.  I will try going back to the h/w UART and adding a bit more delay and then seeing what that does. I was only using 1ms, thinking that would put a 1ms delay between the bytes. You learn something new everyday. Smoke makes things work. When the smoke gets out, it stops! |
||||
| Page 1 of 2 |
|||||
 Print this page |
