 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 Geiger Counter Interrupt Problem - Loop too short?!
  Page 3 of 4   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Interrupts are fully covered in the manuals. Page 26 in the PicoMite manual and page 19 in the PicoMiteVGA manual (as downloaded from Geoff's site this morning) |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5091 |
Hi Peter, What could use some detailing in the manual text is that the PAUSE command should not be used in interrupt routines, but can freely be used outside the interrupt routines. (unless I am mistaken). Or does this depend on the platform ? picomite may be different from micromite or CMM(2) Regards, Volhout Edited 2022-03-25 23:41 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
RTM |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
I have RTM and it does cover interrupts very well but IF the following statement is correct it would be nice if the manual(s) could include something like it. Those of us who began programming microprocessors in assembly language would expect that any interrupt of a few uS would be captured and executed. This isn't necessarily so in MMBasic and perhaps a clearer explanation of why that might happen would help. Bill Keep safe. Live long and prosper. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
Does this issue (of sometimes missing interrupts) apply to all MMBasic variants/platforms (PIC32MX, PIC32MZ, STM32F4/H7/..., Pico, ...)? I was expecting hardware would latch the interrupt and at worst MMBasic would be a bit late servicing the interrupt. John |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
The manual does say that: The interrupt section of the manuals that I have read have the same description so I would guess it is a core function of MMBasic. Bill Keep safe. Live long and prosper. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Yes: always has, always will |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
Read that AND understood that Peter but is it also true for long SOFTWARE related operations like the earlier example of writing text to an LCD screen? That point is still not clear to me. Bill Keep safe. Live long and prosper. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
Do you really need spoon feeding? So the examples given were H/W related except how do you thing the firmware talks to an sd card - yes, you guessed it - software Geoff has probably spent hundreds of hours on these manuals. They are far better than anything else comparable and I'm sorry if I get protective about the quality but the information is almost always there unless you choose not to see it Edited 2022-03-26 08:57 by matherp |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
I guess I do.  Thanks Peter.They were my words. I just wanted it confirmed because the manual(s) only refers to hardware related commands. Bill Keep safe. Live long and prosper. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
No question, the manuals are overall very good. However, I'm not sure it's obvious exactly which commands/functions can or may take a long enough time to miss interrupts. Or, what can be done to make completely sure an interrupt will not be missed. On some MMBasic host CPUs I suppose a CSUB can be hooked to an actual interrupt, but CSUBs aren't always available. On others, hardware will latch the interrupt so it will "just" be serviced late (which may be too late). I was expecting, and I think others were too, that in effect a part of MMBasic definitely (in all cases) saw the interrupt regardless of what it was doing at the time, probably did very little other than made an internal note (set a flag or whatever) that the interrupt had occurred, then when it was about to process the next program item examined that note (flag) and if set went off to the program's interrupt routine. I gather that's not the case, though :( I suppose the workarounds are things like making sure an interrupt doesn't go away until the program takes some action to clear it. Or hooking an interrupt to a CSUB. (I expect there are more workarounds; can't think of them right now.) John Edited 2022-03-26 18:15 by JohnS |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Guys, please keep it civil.... This has been standard from the very start of MMBASIC. No-one should use PAUSE inside an interrupt. ANY interrupt. MMBASIC is NOT assembly language, and comparing what assembly does to what MMBASIC does, is apples and oranges.  I hear what you are saying, but.... Perhaps some clarification could be added to the manuals on that aspect. Smoke makes things work. When the smoke gets out, it stops! |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
this is an important distinction that likely has not been explored fully in the mmbasic documentation for the very good reason that a major driving goal has always been to keep things as identical as is possible at the BASIC code level. ie, differences at the silicon level are kept hidden as best as possible by the interpreter. the PIC32 processors support hardware interrupts, which i assume are serviced in real-time by a C routine (within the interpreter) that sets a collection of flags. these flags are then checked at the end of processing each BASIC line and handled by 'software' interrupts as configured by the user. in this way, any pin state change is registered, but multiple transitions on a pin may be combined into one (unless a collection of counters is used instead of a collection of flags). out of necessity, the STM32 may have a completely different hardware arrangement. the RPi ARM implementations will most certainly be different again due to the non-real-time nature of the underlying (linux) O/S. the PICO may be again different due to the simplified silicon (smaller die area) restricting the complexity. the best way to find answers may will be to simply create a set of hardware+software tests, where a pin transition (or multiple transitions) can be generate while PAUSE, TEMPR, and other likely commands/functions are in progress to see what happens. a couple of 555 timers can be used to create a delayed pulse of an adjustable length. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
There's quite a bit in the manuals already. Maybe what's needed is to list the most likely things (lengthy commands/functions/etc) to cause problems? Or the best work-arounds? It's not necessarily obvious that such as TEXT could cause lost interrupts... If someone is designing a board they can likely arrange to latch any interrupt which could otherwise be lost - but only if they know that's needed. Many interrupts are in effect self-latching e.g. a signal that a FIFO is empty is not going to be short-lived, so it's only the other cases which are potentially an issue. John Edited 2022-03-26 19:40 by JohnS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7938 |
I think the point is that if an interrupt is from an on-chip hardware source e.g. a buffer or counter, then it's a hardware interrupt. Otherwise it's a polled "interrupt". It's a pity they both have the same name, but they both do the same thing - interrupt normal program flow to do something else. Good point about PAUSE. The golden rule is that interrupts should take the absolute minimum of time to execute and NEVER any longer. The sort of thing you should have in an interrupt is to set a flag. That's all. The main program loop runs the process and resets the flag. It doesn't matter whether it's a hardware or a software interrupt, you should treat them in the same way. Edited 2022-03-26 19:54 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
true, but at the same time the behavior needs to well-defined and deterministic. that is, wherever (for example) an MX170 running MMBASIC behaves differently to a PICO running MMBASIC, this needs to be well understood and documented. personally, i don't run games. i do, however, run 'embedded controller' code that needs to behave in a 100% predictable way. this is why i've stuck with the MX170 version of MMBASIC. cheers, rob :-) Edited 2022-03-26 19:53 by robert.rozee |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7938 |
I would argue that it doesn't require specific documentation at all. What we are dealing with is MMBasic, nothing else. If you have problems with interrupts then write your programs to assume that they are *all* polled and you can't go wrong. It's a far safer way to work anyway. BASIC in general is NOT suitable for real-time accurate operations and it's not safe to assume that it is. In some cases there are specific commands for things like frame blanking which allow synchronous program operation with something such as video - but they are not necessarily hardware interrupts. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
I am not sure that is ever going to be possible in one single document. Happy to be proven wrong, but.... There are so many ports now, to so many different chips, that there simply IS no easy way for any ONE manual to cater for ALL variants. This is why DIFFERENT manuals now exist for different ports. MHO only. I think you simply need to refer to the manual for that specific port, and IGNORE the other ones, as they are not relevant to the port in question. IE: The manual for port X, represents all you need to know for port X, and you should not read other manuals for other ports, as they may not be relevant to port X. Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I suspect that isn't correct except where the interrupt will persist for a suitably long time (which many interrupts do). With various MMBasic constructs taking a while (*), it seems you can miss any interrupt which occurs but doesn't stay long enough. (*) BOX, TEXT, LINE, maybe some of the MATH stuff, TEMPR, what else? Hardware level-type interrupts should always work, so things like UART buffer empty (or having room for at least one char) will be fine. John Edited 2022-03-27 00:44 by JohnS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7938 |
You can't *assume* that even buffer interrupts are in hardware. They *probably* are, but they could also be high priority polling. The only way you can be *certain* that you are working with hardware interrupts is to write in a low level language or assembler. Even then an OS might disable all user interrupts while it does something important. Only an NMI has ultimate priority. Generally hardware interrupts work as I described - they set an interrupt flag and it's up to the user to clear it so they are, in effect, latching. If you can make all your interrupts work like that then you won't miss any. Your best chance of catching interrupts in MMBasic is to keep the routines as short and as fast as possible. If it's absolutely essential that you don't miss a particular interrupt then use an external flip-flop. Trigger it from the remote signal, feed the output from it to an input pin and use an output pin to reset it. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Page 3 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
