 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 : Fastest reliable tick timer interrupt rate
Page 1 of 2   |
|||||
| Author | Message | ||||
| flasherror Senior Member  Joined: 07/01/2019 Location: United StatesPosts: 159 |
I have an application I would like to use Micromite (MX170) or preferably Picomite. I want to get some advice before I start coding. I need to monitor/debounce some pulses that may occur at any time (among other tasks). Valid Pulses are minimum 20mS to 50mS. I'll need to debounce inputs to ignore pulses that are under 10-12mS (as they might be glitches). I was planning to setup a tick interrupt using SETTICK 2,DEBOUNCE_ISR,1 to run my debounce code every 2mS (or possibly 4mS). My concern is that since MMBASIC is an interpreter and may be doing other things (serial rx/tx, LCD interface, housekeeping etc), can a periodic interrupt every 2mS be reliable? I realize that a lot depends on what exactly my program is doing, but my concern is whether interpreter does occasional "unpredictably long" tasks (doing garbage collection, drawing to LCD etc) I expect Picomite (being faster) will be easily able to handle this, but how about the slower Micromite MX170? One other thought is that with LCD stuff, time required might be a function of SPI bus speed and thus may not benefit from faster CPU? Am I overthinking this, or are there cases where a 2mS/4mS tick interrupt will be significantly delayed (or overrun)? Edited 2022-01-03 12:03 by flasherror |
||||
vegipete Guru  Joined: 29/01/2013 Location: CanadaPosts: 1132 |
Is the PULSIN function useful? Visit Vegipete's *Mite Library for cool programs. |
||||
| flasherror Senior Member Joined: 07/01/2019 Location: United StatesPosts: 159 |
Pauses execution while waiting for pulse. I want to measure multiple pulses on multiple inputs without blocking. Edited 2022-01-03 12:25 by flasherror |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2640 |
My experience is that when something needs checking that often it is best to test the condition at a suitable point in the main loop. An interrupt is called that for a reason! If an interrupt is necessary just use it to set a flag, then deal that at a suitable point in the main loop. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Picomite: This sounds like a perfect task for a PIO state machine(?) See the appendix in the manual.....and then teach me how to use that stuff  MX170: For time-critical and high-speed applications, I use Bypic. I have tasks running (actual processes, not just setting a flag) @1KHz (1mS) while simultaneously having a live/active command prompt. I know for a fact that this is rock-solid reliable because I am closing a PID loop on a DC motor/encoder and a single glitch would make itself known. See attached PDF where it shows examples of: -Running tasks (up to 20) -Running on a timer-interrupt Execution speed @40MHz is comparable to the CMM2. Traffic Lights.pdf |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
@flasherror I use an picomite where I check 4 channels for glitches that are longer than 2ms. What I do is attach the 4 IO pins to 4 interrupts, and in the interrupt routine read the timer. Since the tick is 1ms (integer), this detects glitches longer than 2-3ms. I can't find the code at my work PC but I can describe what it does. So I'll type down some "pseudo code" Assume you are looking for a "high" level key press. Code for 1 key on pin x In below code replace x with your IO pin number. For 5 keys, multiply the whole code 5x. Yes, it is not compact but very efficient. Uses not time when there is no change, and minimal when there is a change. Setpin x,INTH,Int_press_x Do 'here comes the main code Loop Sub Int_press_x Setpin x,INTL,Int_release_x t=Timer End Sub Sub Int_release_x Setpin x,INTH,Int_press_x if Timer-t > threshold then keypress=1 End Sub Note this code is not tested, but this is what I did. When I find the actual code, I will post it later. Edited 2022-01-03 17:38 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I don't think "interrupts" in MMBasic are true hardware interrupts. I think Peter once said that they are checked after every program line - you can't interrupt part way through a statement. That doesn't make them less useful, but it's something to be aware of. It might be an idea to consider using the PORT() function to test all the required input lines simultaneously on every program scan (or on a SETTICK) rather than triggering multiple interrupts. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
A simple RC network on the input? If you don't mind an extra IC then an MC14490 is made for this (literally). We used them by the bucket loads. Bill Keep safe. Live long and prosper. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Hey... that's a useful chip! I didn't know they existed. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Huh? I thought you were the penny-pincher They're like 10 quid a-piece |
||||
| Pluto Guru Joined: 09/06/2017 Location: FinlandPosts: 375 |
MAX6816, 6817, 6818 and LTC6994 are other possibilities for debouncing. Fred |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
10 quid!? And not through-hole DIP either so no wonder I've not noticed them. lol It's a lot cheaper to dedicate a Pico to just doing debouncing. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
Hi Mixtel90, You are correct that that is a limitation of interpreted basic. You cannot interrupt a basic statement in execution. And when that statement is a SD card write, it can take some time. But honestly, even if you write C and use hardware interrupts, there will be tasks that you want not interrupted by a simple keystroke. So you disable the key interrupts. This is something you can improve on, but not avoid in software. I still think the proposal is a solution for the thread starter since it works on a MM2 as well as a picomite. But hardware filtering is also possible. But keep in mind that blocking basic statements will always slow down key processing, as long as you remain in the interpreted basic domain. The MM2 can have maximum 10 hardware interrupts on IO pins. Volhout Edited 2022-01-03 20:34 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Yes except for complex LCD commands. For example CLs takes 81mSec on a 320x240 SPI display. And, of course, you mustn't use blocking console input commands |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
@flasherror I am not sure a 2ms timed interrupt will solve your problem. The MM2 can execute roughly 30.000 basic commands per second, which is 60 in 2 ms. If you write a 2ms interrupt routine it should be extremely short. I am not sure what your input signals look like. If they are real key presses, you get maximum 5 per second (fast typing). Then the 2ms timed interrupt may be a large overhead (90% of the time wasting time). Better use the IO interrupt method proposed by me earlier. If your input signal has much higher change rate (like combined over all connected IO pins 100 changes per second), the 2ms timer interrupt is preferable. Regards, Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
flasherror doesn't say if the pulses are from one or many sources or from what device(s) they are coming. For a single source an MC14490 is overkill of course. A simple RC network may suffice if it is only one input. The MC14490 is available as a through hole DIP, that's what we used, but we had 16 inputs per board so the cost was cheaper and the result was more compact that any alternative. If something like the CLS command will prevent the processor from servicing the interrupt then a hardware solution may be better. A valid pulse may be gone by the time the interrupt routine runs Bill Keep safe. Live long and prosper. |
||||
| Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
MC14490: Ah, I might've known....this is more like it |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
From the Shakitobitsi Electronics Corporation (Bakalli 32412, Fulokrapsi, PRC), with your choice of manufacturer's logo and component number applied? ;) Yep, looks more realistic. Within my price range, even. :) 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 |
Wow... lots of replies. Thanks everyone. Replying to all below: I forgot about the PIOs for the picomite... I'll have to read/understand this to see how they can help in this situation. Bypic looks like it is no longer developed and forum is closed. This is an interesting approach but doesn't it have the same issue as tick timer? Specifically pin change interrupt response might be delayed if interpreter is busy doing other things? Also, rapid changes in pin state will occupy more CPU time? One issue about debouncing inputs in software is that you want the debounce code to be run like clockwork to simplify/make it reliable. Never heard of this chip actually. But if I had to add an extra chip I could add a PIC to do the debounce and talk to the MX170/Picomite via UART. That would ensure that inputs are always monitored (PIC doing the work) and nothing will be missed (even if MX170/Pico is busy UART RX buffer will be processed eventually) but still might have a delayed response in noticing/taking action if busy (which may be acceptable). The issue isn't so much simple debouncing but debouncing with ensuring that only pulses within min/max valid range are handled. And of course, how to best implement this given basic limitations. Might be able to do without the LCD (but prefer not to) but may want to have SD card logging with Picomite, so possible long delays might still be present. Pulses from multiple source, probably about 4 independent devices that may change at any time. Edited 2022-01-03 23:01 by flasherror |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
A PIC will generally do interrupt on change over a full port so that may be an idea. The MX170 is no slouch even running MMBasic though. If all it had to do was debounce 4 inputs and set one of four output flags on a valid input then use a common reset signal coming back to reset them... Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
