 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 : Picomite COM1
| Author | Message | ||||
| BishopXXL Newbie  Joined: 13/01/2019 Location: GermanyPosts: 34 |
Hi@all sorry for my very bad English ;) I use this Version of : PicoMite MMBasic Version 5.07.04b1 My wish is to output a text on the serial interface. Later I would like to realize a fast communication with the PC at the USB port. I noticed that something is wrong at the end of the bitstream. It looks like 2 bytes are always missing and an error occurs because the last character is recognized as NULL. The delay at the end I get away with a pull down I've tried. Is it me or is there a microbug in the firmware. BTW it is a great job from everyone involved - a big thank you! SetPin GP13, GP12, Com1 Open "COM1:115200" As #1 Print #1,Chr$(2); Print #1,Chr$(2); Print #1,"Digit"; Print #1, "!"; Print #1,Chr$(3); Print #1,Chr$(3); Print #1, "!"; Close #1  |
||||
CaptainBoing Guru  Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
Hello, welcome to the forum. Your English is fine and a lot better than my German  yes that is odd. the Tx line is normally/should be left in a "marking" state; that slow tail off will leave the Tx line in a bad state for the next line. I don't know whether that is the effect of closing the channel (try again without the Close#1) but it doesn't sound right. It makes sense that if the pin is defined as a serial Tx it should adhere to the standards until re-assigned regardless of whether the channel is open or closed. Also; try putting DO:LOOP at the end of your prog just in case it is something to do with the interpretter returning to immediate mode. I suspect the NUL is just your analyser doing its best to make sense of the incorrect state and not a "real" character - the very slow fall doesn't match the rest of the data edges . Edited 2022-02-02 20:39 by CaptainBoing |
||||
| BishopXXL Newbie Joined: 13/01/2019 Location: GermanyPosts: 34 |
Hi, Captain B. thanks for your reply. I can live with the delay. The much bigger problem is that the last two characters are missing there. The "ETX" and the "!" to the end. For completeness here are mine: OPTION SYSTEM SPI GP18,GP19,GP16 OPTION SYSTEM I2C GP0,GP1 OPTION COLOURCODE ON OPTION DISPLAY 40, 140 OPTION SDCARD GP22 OPTION RTC AUTO ENABLE Thank you ! |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
serial comms are "slow" and I wander if the close and/or then the end of your prog are somehow abandoning the send. Things to try: * Remove the close#1 * Put a pause in before the close#1 * put the prog in a loop at the end rather than allowing it to implicitly end . |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Closing the serial port will put it into undefined or high Z state. Use a pullup to hold it high and you have to redefine the pins before trying to use the port again. VK7JH MMedit |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
That certainly matches what OP is seeing Jim, good call I guess I have never seen this problem because I don't think I have ever used Close#n - open the serial port and leave it like that  Edited 2022-02-02 20:49 by CaptainBoing |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
Hi all, This was discussed before, I proposed to release the IO pins with a new Setpin command, but keep them connected to the UART at "Close". Peters comment was that that was not his intention. His response was that you need to have a pullup to "idle" state anyway, otherwise the lines are not defined BEFORE you open the UART. So if you add a pullup, the system is well defined before AND after UART communication. In your case the IO lines are immediately released (the "close") before the UART has transmitted all buffered content. Since you have no idea how much is in the UART buffer, it may be hard to do anything to guarantee all is sent. Maybe it is better to check if all is sent before closing the COM  Regards, Volhout P.S. This thread confirms that others may have a problem with this software implementation. Maybe is this thread changes Peters intention, although he is very occupied with MMB4W at the moment. Edited 2022-02-02 21:17 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2640 |
Could the missing characters at the end be the result of the port closing before the transmit buffer is empty? A short pause before closing should fix that, along with the pullup previously mentioned. PAUSE 0.2 'mS should be enough to send 2 bytes at 115200 baud. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
@phill, fixed time won't do it. There could be more in the transmit buffer. See previous post: use LOF(), as described in appendix A of the user manual Volhout Edited 2022-02-02 21:52 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| BishopXXL Newbie Joined: 13/01/2019 Location: GermanyPosts: 34 |
Hello, that was the right hint, I used a pullup and the lof() and it works. THX everyone ----//---------- Datei$ = "" Datei$ = Mid$(Time$,1,2) + Mid$(Time$,4,2) + Mid$(Time$,7,2) SetPin GP13, GP12, Com1 Open "COM1:115200" As #1 Do B=B+1 Messen() Print #1,Chr$(2); Print #1,Chr$(2); For i = 1 To 1024 digit = messwert(i) * 1241 Print #1,digit, Next i Print #1,Chr$(3); Print #1,Chr$(3); Do : Loop Until Lof(#1) = 256 Loop Until b = 2 Close #1 --//--- |
||||
| CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
... or don't close the serial... only really need to if you are going to redefine the pin for something else later on |
||||
| BishopXXL Newbie Joined: 13/01/2019 Location: GermanyPosts: 34 |
Yes, you're right ! |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
I had the same problem earlier. It was necessary to wait until LOF was 256 and then add a pause a bit longer than the transmit time of the last character. Geoff fixed it so that MMBasic will wait until the last character has been sent before closing the port. I don't know if this has carried through to the Pico. From the Micromite change log: Bill Keep safe. Live long and prosper. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
