![]() |
Forum Index : Microcontroller and PC projects : Fastest reliable tick timer interrupt rate
![]() ![]() |
|||||
Author | Message | ||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5090 |
In a single CPU application you need to prioritize tasks. In MMBAsic the priority is determined by the interpreter, and it is finalizing the current statement (appart from some internal housekeeping). When this decoding needs to have priority then you have 3 options a/ offload the task to another chip (hardware or software). You could do this with a 74HCT123 (only pass pulses between 20-50ms). But still you would suffer from a "CLS" on the LCD (*) b/ make sure you have no higher priority (read: slow commands) stuff blocking operation. Maybe that involves not writing to LCD while capturing pulses. Or it might force you to split LCD commands into multiple short commands that finish in 2ms. Sounds maybe stupid, but replacing the CLS with 240 black line writes may solve the issue. Slower, but interruptable. Or ... offload the tasks to another chip. c/ Don't use MMBasic. It is easy to develop in, but you cannot change what it does in the interpreter. Using C in Arduino you have more influence, and you can give the pulse inputs top priority. You see by the number of responses, that people are enthusiast to help. Maybe explaining a bit about the pulse source brings additional idea's. Volhout (*)= a CLS takes 81 ms. If you have two completely valid pulses of 20ms, that are 40ms apart, the 2 pulses fall into one "dead period" of 81ms. Even if an interrupt is set, only one of the pulses will be processed, and you missed a pulse. Edited 2022-01-04 00:05 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Tinine Guru ![]() Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
It just works ![]() I followed their advice and used HTTRACK to copy their entire site. Just another secret weapon for me that everyone is oblivious to. ![]() |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
Might be that nobody uses it because they can't find the "free" firmware that existed at one point. ![]() http://www.bypic.co.uk doesn't exist anymore and the firmware was at http://www.bypic.co.uk/index.php/ByPic_Firmware Since it was made free (see http://www.bypic.byvac.com/index.php/Products and http://www.byvac.com/forum/read.php?1,809) I don't think there are any issues to distributing it. Anyone want to upload it/supporting documentation? Also, since no longer developed, what about bugs/issues? Edited 2022-01-04 00:58 by flasherror |
||||
Tinine Guru ![]() Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
The site disappeared but.... This suddenly showed up....don't know what "gpeasy" is though. Please let me know if it works and not some weird cache-thingy on my system. Note: Go to Downloads on the menu bar for the firmware because the link in the opening paragraph doesn't work. I would be happy to help get you going....I have pretty much everything. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
It would have been nice if the source code had been made available, but it doesn't appear to have been. There may be no support at all. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Tinine Guru ![]() Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
There is no support but it doesn't deter moi. There's an awful lot of sample source that pretty-much covers everything. I had it working in a heartbeat and I'm certainly no matherp ![]() |
||||
CaptainBoing![]() Guru ![]() Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
It just works ![]() if you can get it. despite saying it is now freely available, the the link is dead (goes to a squatter) shame |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
Use the link/instructions posted by Tinine above, or check https://www.byvac.com/gpeasy/index.php/ByPic_Firmware Latest MX170 seems to be http://www.byvac.com/downloads/mBASIC/ByPicMX170_2.32.108.zip |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
I am still reading up on PIO operation for RP2040 but is there any way to use the PIOs for I/O debounce or filtering rather than signal generation? |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
I found a reference to Bypic being open source (see comment by Jim at https://hackaday.com/2014/11/03/checking-email-with-the-esp8266/#comments) but not sure if source exists anywhere. Edited 2022-01-04 07:47 by flasherror |
||||
Tinine Guru ![]() Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
@flasherror I suspect that refers to the sample source-code and not the firmware. |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5090 |
@flasherror, I am certain the pio of the pico can do it. But you need to give us more info on the number of pins and the maximum frequency on those signals. Is the basic program capable of handling the burst datarate, or the average datarate, or none of both. Volhout PicomiteVGA PETSCII ROBOTS |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
More details: I want to monitor two product dispensers, both having the same details below. This means monitoring 4 separate inputs. Due to my Pico pin allocation the I/Os aren't contiguous but I don't know if that is a issue for PIO coding. One input (to Pico) monitors active high "dispenser on" signal. This is driven from external equipment. The other input monitors active low (grounded) "product dispensed" signal as confirmation that product was dispensed successfully. The monitoring is to ensure that in the event of a malfunction staff can be alerted (and event logged). When "dispenser on" the "product dispensed" signal for a single product dispensed is a 20-50mS active low pulse width every 300-600mS. If something like 800mS passes with "dispenser on" but no associated "product dispensed" pulse then something has gone wrong. "Product dispensed" pulses under 10-12mS are probably glitches and can be ignored. Normally my approach would be setup a frequent (2/4mS) timer interrupt to debounce inputs, check for timeouts etc. But since this may not be reliable for MMBasic, the only things I can think of that will work is offload to a slave PIC, or possibly use the PIO to do the precise/monitoring timing work. The PIOs sound interesting from what I've read but will take some getting used to. 32 instructions total for all 4 state machines doesn't sound like a lot to me. Is there a PIO simulator where I can play around to become familiar with PIO coding? Edited 2022-01-04 11:36 by flasherror |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5090 |
@flasherror, Nice project ! Very good for the pi pico, depending on the human interface you require. If it is only a counter for dispensed products and some red and green lights to show obstructions in the dispenser it is simple. As to the PIO sequencer: The pico has 2 PIO blocks of 4 sequencers, so you have 8 in total, with 32 instructions in each block. If you use MMBasic in the pico VGA, the VGA video encoder uses one whole pio block, so you have ony 4 sequencers left. But you only need this version if you plan to attach a VGA screen. With LCD screen you can use the normal pico MMBAsic software. MIXTEL90 and Matherp have created a way to program the PIO sequencers in the MMBasic environment. But the PIO sequencer language (not basic, some kind of assembly language with only 8 instructions) is identical between the python environment and the MMBAsic environment. Only the way to program the assembly compiled into the chip is different. MIXTEL90 can help you with that, but the examples in the PIO (PASM) are explanatory. On the Raspberry pi website there are examples for programming the PIO from python. Between these examples is one that decodes IR (infra red) remote control signals. That protocol is based on measuring pulse width, and outputting logical 0's and 1's depending on the pulse width. You can use this example for your project. Change the time duration, or the clock frequency of the sequencer, and you can try. Success with your project, Volhout P.S. Unfortunately the Christmas holidays are over for me, otherwise I would prove to you that a pico can do the above mentioned tasks from MMBasic alone. You don't need the sequencer. But the sequencer can remove the nasty real time requirements. Edited 2022-01-04 17:57 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
CaptainBoing![]() Guru ![]() Joined: 07/09/2016 Location: United KingdomPosts: 2170 |
Latest MX170 seems to be http://www.byvac.com/downloads/mBASIC/ByPicMX170_2.32.108.zip ah! didnt see that - thanks both |
||||
Tinine Guru ![]() Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Latest MX170 seems to be http://www.byvac.com/downloads/mBASIC/ByPicMX170_2.32.108.zip ah! didnt see that - thanks both Let me know if you can't locate something, buddy. I kinda went to town after the early warning and not only copied the entire website but I also made PDFs of the includes and sample source. |
||||
flasherror Senior Member ![]() Joined: 07/01/2019 Location: United StatesPosts: 159 |
I kinda went to town after the early warning and not only copied the entire website but I also made PDFs of the includes and sample source. It would be helpful for new bypic users to have the PDFs and sample code. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I want to monitor two product dispensers, both having the same details below. This means monitoring 4 separate inputs. Due to my Pico pin allocation the I/Os aren't contiguous but I don't know if that is a issue for PIO coding. One input (to Pico) monitors active high "dispenser on" signal. This is driven from external equipment. The other input monitors active low (grounded) "product dispensed" signal as confirmation that product was dispensed successfully. The monitoring is to ensure that in the event of a malfunction staff can be alerted (and event logged). When "dispenser on" the "product dispensed" signal for a single product dispensed is a 20-50mS active low pulse width every 300-600mS. If something like 800mS passes with "dispenser on" but no associated "product dispensed" pulse then something has gone wrong. "Product dispensed" pulses under 10-12mS are probably glitches and can be ignored. Dispenser On goes high While high: Expect falling edge on Product Dispensed every 300-600ms If additional falling edges occur within, say, 100ms then ignore them as glitches. If no falling edge within 800ms of Dispenser On or last falling edge then signal error. You never need to look for the rising edge of Product Dispensed. It's of no interest. Dispenser On going low signals the end of the run. The timing of Dispenser On isn't obviously critical within 100ms or so. Only two inputs, the Product Dispensed ones, need to be dealt with. We only need the falling edges, so use those to trigger interrupts. There are two machines, so a Micromite on each would make sense. They can run at full speed then with no cross-interruption. Each can provide a "Healthy" output for monitoring. This would be high when Dispenser On is off and when Dispenser On is high and falling edges are being detected. At all other times (including power off, obviously) it would be off. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |