 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 : PICO high speed serial problem
  Page 2 of 2 |
|||||
| Author | Message | ||||
Turbo46 Guru  Joined: 24/12/2017 Location: AustraliaPosts: 1611 |
As Mick said, You can add a CRC to the message and just reject any messages that are corrupt. That is precisely the purpose of a CRC. See the MMB4W manual for an example. Bill Keep safe. Live long and prosper. |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
That isn't the problem, I think it is the baud rate. Increasing the CPU speed isn't a work-around, its a necessity at that speed. Then there is the USB system issue. What I understand from previous discussions this has nothing to do with sending data to the computer over USB. The USB system periodically does some "housekeeping" stuff that isn't under control of the firmware. It hogs a little processor time without regard to what your program is doing at that moment. I see it when receiving a data stream on a Count pin. Using CSub LOG** the Pico sometimes registers a rising edge later than when the pin actually went high. Typically the delay is 5 to 15µS but can be more or less. ** The current version is only for v5.08.00 firmware |
||||
| ElectroPI Newbie  Joined: 27/04/2012 Location: AustraliaPosts: 32 |
Do you have a link to the discussion on the USB system issue? |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2135 |
Have tried searching but but get everything except that. Someone who knows about the inner workings of the Pico may supply more info. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
Not related to USB, but in this post Peter explains a similar housekeeping task when you have an SD card connected. What DAC do you suggest Volhout P.S. I know of only 1 basic computer that does not have interrupt driven housekeeping. The ACORN ATOM. So regardless you will face issues like this. Edited 2024-06-21 16:42 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
The application uses 4 pico's, communication through serial in a multidrop configuration. 3 slaves, one master. Each slave pico sends 4*16 bit ADC values. That is 64 bits. Although calculating a CRC is fast, it changes the packet to 80 bits (unless you go for an 8 bit CRC). The receiving side will have to check the CRC on many small 64bit packets (from all 3 senders), and will become quite busy. I think you will exceed your 10 MMBasic instructions per ADC value easilly, bringing the speed of the system down fast. I think all the master pico should do is transfer the data to the PC. Let the PC remove the CRC's. It has more UMPH... Regards, Volhout Edited 2024-06-21 16:52 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| ElectroPI Newbie Joined: 27/04/2012 Location: AustraliaPosts: 32 |
Volhout, yes I saw that thread but didn't read it in detail. I will now. Phil, maybe a different forum discussing the PICO in more detail? regards |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3800 |
Sorry to ask... For the statements SETPIN GP1,GP0,COM1 OPEN "COM1:921600" AS #5 Is the serial I/O being done in hardware or is it software bitbang? John |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6783 |
Why receive from all three senders so fast? Read from one at once into the buffer. Now there is no processing time problem. Get the data from the buffer & CRC check it. Get it resent if necessary *then* signal the next transmitter to send. AFAIK The COM system uses the built-in UART hardware of the Pico. SETPIN "connects" the pins to it. When COM reads incoming data it puts it into the buffer in hardware - I don't think there is any intervention from the rest of the system. The actual receive process is, therefore, very fast but unfortunately there is no flow control. Because of this you *have* to devise your own error checking if you want any sort of reliability. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| ElectroPI Newbie Joined: 27/04/2012 Location: AustraliaPosts: 32 |
Hi Mick, I don't have much time to do very much. I'm triggering the 4 PICOs at 360Hz, converting each of their 4 analogue channels and then sending the ADC values to PICO#0. PICO#0 appends the data strings from the others to its own to create a 32 byte string which it then sends to the computer. 360Hz means I only have 2.8msec to do everything. When I overclock the PICOs to 378,000,000 everything works fine with no lost bytes now. I can even send at 460800 baud now with no loss of bytes or timing issues as long as I overclock the CPU. As I mentioned previously I have a few more questions regarding the ADCs, etc so I won't go into too much detail here, I'd rather raise a new topic and describe the setup there. With regards my next test with the 2 raspi PICOs - using an interrupt instead of LOC() to wait for 32 bytes in the receive buffer: PICO#1 - normal clock speed and sending 10 32-byte strings per second at 921600 baud, 1 stop bit. PICO#0 - normal clock speed, USB serial speed to TeraTerm is also 921600. This is the program: SETPIN GP1,GP0,COM1 OPEN "COM1:921600,256,PP,32" AS #5 DO LOOP SUB PP inp$=INPUT$(70,#5) IF LEN(inp$)<>32 THEN PRINT "A" END SUB So this prints a couple of 'A's at the start while the loops sync (as expected). Then there's nothing for quite a while before the next 'A' appears. And it keeps happening at random. So looks like there's no difference between using LOC() or an interrupt to wait for 32 bytes in the receive buffer. I haven't tried 2 stop bits with the interrupt or overclocking since the solution which seems to work in my original application is just to overclock the PICOs. Peter |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
I understand that nobody wants the solution to be something else but FWIW, the WeAct and DevEbox H7 boards could be worth looking at for the master. They are super quick and have something like 4 Com ports. I just received another 2 WeActs. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3800 |
Actually, good idea!! (But I'd also like to understand whether there is an actual problem with the Pico and/or MMBasic on the Pico.) John |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
Not convenient to set-up my multi-drop PicoMite rig, unfortunately or I would be replicating the task but with BIN2STR$ and STR2BIN; rock solid  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6783 |
Sounds like you could do with flash ADCs, not SAR ones. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
Make life easier..... Use ArmmiteH7 (an STM32H743), it has up to 36 x 16 bits ADC channels, and can do this all by himself, since it is much faster than a pico. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
Bingo!  |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
Build quality is first-rate and it has USB-C, SD-Card socket and a 0.96" TFT display (not sure if the display is supported?)  |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6783 |
Of course, if you want ADC speed *and* accuracy then the Pico isn't a good choice anyway. Because of the silicon errors it's effectively only about 9-bit resolution at best, no matter what the word length is. If you are using the switcher power supply that will also degrade the noise floor. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| ElectroPI Newbie Joined: 27/04/2012 Location: AustraliaPosts: 32 |
I'll check out the Armmite, looks interesting |
||||
| Page 2 of 2 |
|||||
 Print this page |
