 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 PIO - can PIO IRQ trigger Basic code / transfer data?
| Author | Message | ||||
| flasherror Senior Member  Joined: 07/01/2019 Location: United StatesPosts: 159 |
I need some clarification on how PIO interrupts interact with the Picomite MMBasic interpreter as current documentation might not be detailed (or functionality for PIO to MMBasic interrupts might not present). Basically I want to use PIO for input debouncing. How this would work (in theory, don't have the details figured out yet) is that the PIO would monitor inputs and trigger an IRQ (one of the lowest 4 IRQs, see C/C++ SDK Section IRQ 3.4.9.2. Operation) which could then trigger MMBasic code as a result of the interrupt. Somehow this Basic code would be able to transfer data from PIO (for example which input was triggered or the pulse width time). In other words, I need to trigger MMBasic code via PIO IRQ & pass data from PIO code to MMBasic code. The first point of RP2040 datasheet section 3.2.6. IRQ Flags confirms IRQ trigger is possible: "Asserting system level interrupts from a state machine program, and optionally waiting for the interrupt to be acknowledged" Does Picomite currently support PIO code triggering a Basic interrupt and PIO to Basic data transfer? All the PIO code that I have seen so far is primarily concerned with data output, not input. I realize normally this isn't the thing that might be usually done as it is a kind of weird to have (slow) MMBasic code interact with blazingly fast PIO  but this might work for me.Just had another thought after I wrote the above: I wonder if the 2nd unused Picomite CPU core could implement debounce code on it and then trigger an interrupt the running program / pass data to it? |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
You're right on the cutting edge here. lol The state machine(s) just plod happily round their little loop reading and doing whatever memory tells them. If an instruction says "set interrupt n" then that's what it does. If it says "wait until interrupt j goes high" then that's what it does. Whether the interrupt is a system one or one local to the PIO depends on the number of the interrupt, otherwise they are identical. The system interrupts are not directly readable from MMBasic AFAIK - in fact I suspect they are disabled during execution of every BASIC statement. Sometimes that will be for an appreciable time, so this might not be a worthwhile direction. The second processor wouldn't be disabling them so it would be able to deal with them, but you have your work cut out if you want to get into setting that up. (The state machines read & process one instruction per clock cycle, and their clock speed is decided by the division ratio set up in the CLKDIV register, which divides down from the system clock. By default they run at full system clock speed so they are fair flying along!) How about something nice and simple? A hardware flip-flop for each input. Set comes from the trigger (via a monostable if you want to ignore very short pulses). Reset can be a common pulse from the controller that resets them after processing. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
You'd expect a simple way to pass data PIO <-> uC core. Could you have missed it? A way to set a flag is all you require. BTW I've done lots of debounce stuff but never needed it quite so fast. MMBasic is easily fast enough IME. John Edited 2022-01-07 07:07 by JohnS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I think the problem will be this: MMBasic only processes interrupts at the end of a line. The interrupts are disabled until it's complete. System interrupts can't be allowed in the middle of a BASIC statement - anything could happen! So the only way a PIO is going to be able to send *accurately timed* interrupts back is to use the second cpu core as the first one is fully occupied. The PIO instructions, being part of MMBasic, can't deal with interrupts from the PIO. Also, using the SD card will disable interrupts until the operation is complete. You can read data from the PIO, but it can't interrupt the MMBasic CPU *with accurate timing* as the CPU will have the interrupts disabled for a lot of the time. You should only be looking for leading edges anyway. A leading edge suggests that something has been detected and it has to be dealt with. After that you can stick a timer on and only start looking for a leading edge again once it's timed out. If you have a pulse of, say, 2ms but it should never occur again within 100ms then use a timer of, say, 70-80ms and you'll ignore every bounce within that period. The trailing edges don't matter and you shouldn't bother looking for them in most circumstances (unless it's in addition to a timer and even then only to reset a flag). Edited 2022-01-07 07:35 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| flasherror Senior Member Joined: 07/01/2019 Location: United StatesPosts: 159 |
Not always fast enough, if you have LCD or SD card activity going on which might prevent frequently occurring Tick interrupts from being processed. I give more background about my debounce problem here. I was thinking that it might be possible to check PIO interrupts 0-3 after each Basic command is done executing - this will allow the same kind of Basic code to handle "PIO needs attention interrupt" like how SETTICK works etc except that the PIO generates the interrupt. Wouldn't be fast but might be simple and probably easier to implement since you are only checking them after each basic command has finished being processed. Another option is currently Picomite only uses one of the two processor cores. The unused second processor, in theory, allows some possibilities: 1. It might be possible to execute *some* Basic code on 2nd processor and pass flags/data between "main" basic and "background" basic? Again, for simplicity flags/data could be checked after every "main" basic command rather than a "true" interrupt? 2nd processor could have its own SETTICK timers for example so "background" tasks don't interfere with timing of "main" code. Main CPU being tied up with long operation tasks like LCD clear would not affect background code. 2. Move time consuming MMBasic tasks to 2nd processor (LCD drawing commands/advanced GUI functions so they don't pause basic code as much while in progress?) There has been some discussion about potential uses for the 2nd processor (running CSUBs?) but I don't remember what the end result was. I also recall there is/was a commercial product that extended MMBasic to have some kind of background tasks but I cannot remember the product name or company website. Perhaps the same concept could work with the 2nd processor? Edited 2022-01-07 08:06 by flasherror |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
What's up with hardware? The simple logic I described earlier will catch every signal even if they happen instantaneously.The total cost of the logic chips and some perfbord will probably be less than a pint. Why make things more complicated than they need to be? If you must do it all on a single chip and need accurate response from all channels at once then get a Propeller P2, but I'm pretty sure it's overkill here. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
The simplest solution I see, is use 2 pico's. They are cheap, and you keep everything programable. One pico does the input signal decoding (pulse width, and maybe also the run time (300-600ms, 800ms=fail). The main loop of this pico could be a "do:loop" to make use all interrupts are handled fastest. 8 parallel outputs (2x4) to the second pico (add some LED's to these lines for simple error shooting). Lines per sensor could be "sensor 1 valid", "sensor 2 valid", "runtime valid" the 4'th line would be an ACKN from second pico to first to indicate you have received the info. The second pico does the display and nitty gritty things you would like to do that take more than few ms. In it's main loop it would get the latest data from the 8 pins, and send an ACKN. Below 10 euro for the pair, and freely programmable in MMBasic. Breadboard friendly Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
The idea is good, but the problem is not the instantaneous change, but getting time information from it. When you are late , and need a flipflop to remember the change, you are also late to measure the time of the pulse width. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
But you don't want the pulse width. You want to do something when the mechanism signals, the width of the signal pulse is irrelevant. That's why I say think of the leading edges only. See flasherror's original debounce thread, where I have made a further suggestion, which does not involve PIOs etc. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
There was a requirement to treat pulses <12ms as glitches (discard them). Valid pulses where 20ms-50ms. See first post of previous thread. Volhout Edited 2022-01-08 01:18 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
What generates these pulses? They seem to be a bit fast for contacts. Should they need debouncing? What causes the 'glitches'? Noise? Long high impedance run between devices? Different earth connections? Can they be eliminated? Shielding, lower the impedance, opto couplers, tie the earths together, move the devices closer together. I would consider an 8 pin Picaxe as a pre-processor for each input. Small, cheap and the same program for each one. Bill Keep safe. Live long and prosper. |
||||
| flasherror Senior Member Joined: 07/01/2019 Location: United StatesPosts: 159 |
Manufacturer of product dispenser recommends ignoring shorter than 12mS "product successfully dispensed" pulses. If they recommend it I'm going to do it I currently plan to use a cheap PIC to handle input processing to make sure pulses aren't missed. 16F1705 is a cheap PIC but like all PICs right now is difficult to obtain (but I have some bought long ago). The crazy thing is the long lead times on parts, I have seen "back in stock" dates of over 52 weeks! The advantage of using a PIC rather than another Picomite is PCB space required. Edited 2022-01-09 01:12 by flasherror |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Are those short pulses contact bounce, occurring naturally after a main pulse, or something else? It changes the way you handle them. If they can happen at random during the 300-600ms between main pulses then you have to time every pulse to see if it's valid. If they are contact bounce then you ignore the trailing edge of a main pulse for up to, say, 150ms as the next one is going to be at a minimum of 300ms, and they can occur as much as they want within that time, they'll be ignored. Still not enough info. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
