 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 4 of 4 |
|||||
| Author | Message | ||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
True. But you can (& should) check the CPU & related hardware so that you know for sure and also know any limitations (in this case, fairly short-lived interrupt requests it appears, with no hardware to latch them). True, except such an OS will not lose a user interrupt (well, I've never met one that did and I've fought a lot of them). It may delay it, of course. Most are, yes. (Again, the user should check.) Usually, but in this case the interrupts were lost even with a tiny routine because the main program used MMBasic statements (BOX, LINE, TEXT etc) which can be busy for longer than the interrupt request lasts. The Picomite manual does warn about this sort of thing. Agreed. I like the fix for the program in this thread (using a counting input & checking for changes). Avoids needing an interrupt, thus side-stepping the MMBasic statements concerned. Also, I think the original idea that PAUSE made it work wasn't quite true. It mostly hid the underlying problem, but some of the interrupt requests must still have been lost - perhaps too few to notice, which would be a lurking issue in many a program. John Edited 2022-03-27 02:51 by JohnS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10315 |
This is getting silly EVERY version of MMbasic checks for interrupts at the end of each Basic statement with the single exception that the checks are also made during a PAUSE statement For every version of MMBasic SETPIN n, INTx is not a true interrupt but the pin is read at the end of each Basic statement and a S/W interrupt is triggered if the pin has changed in the required manner For every version of MMBasic Pin interrupts will be lost if the pin reverts state while a single Basic statement is running For every version of MMBasic this is more likely to happen with commands that take longer but could happen with any command if the pin change is short enough For every version of MMBasic this is most likely to happen with commands that communicate with H/W or move lots of data (e.g. TEMPR, graphics commands, MATH commands (where relevant)) For every version of MMBasic if this is critical you need to manage this in your code by using the timer command to see how long things take to process and find a relevant workaround For every version of MMBasic SETPIN CIN, PIN, FIN are based on true H/W interrupts and thus will always give accurate results For every version of MMBasic the core Basic language is pretty much identical and the main differences are the way the firmware interacts with the various H/W peripherals BUT the basics of even this are the same (e.g.serial I/O is always interrupt driven, serial output is non-blocking, serial receive happens in the background and writes to the receive buffer etc. etc. etc........) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I don't think I'd call it silly. There was a program which was said to work with PAUSE but not without the PAUSE. That turns out to be wrong, I am virtually certain (for the reason I've stated). It was said that making the interrupt routines short would/did fix it - but not so. Looks to me like a useful learning exercise, revealing traps for the unwary. John |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 675 |
Uhm... I started this topic, but never thought it would catch so much attention, since the problem for me is solved. As a C/C++ guy and beginner of BASIC / MMBASIC dialect, I can just say this: If I see the word interrupt mentioned as command or part of statement / trigger option, whatever, I expect an interrupt which behaves with highest priority and don't loses counts / events. This is in MY OPINION counter intuitive to everything I learned. My thoughts as beginner were: There is a Geiger counter pulse, what is the first thing you may think of? Interrupt! I looked in the manual, found the interrupt, set it to falling edge, perfect! Simple as that. But .... not really. BUT: I am more than happy that Peter could clarify how I can simply solve my problem by using SETPIN CIN / OPTION COUNT. This makes perfect sense to me, but the word Interrupt is misleading in my opinion. You might say I am using the wrong command for what I want to do, but ... sorry Interrupt in 99,9% of cases means INTERRUPT, NOW! Not: "maybe...only when the pulse is long enough and the sun shines bright enough and the grass is green" Interrupt, period. What is the point of interrupt that does NOT interrupt? :) Let us all don't take things too serious! I was just confused which the way an interrupt is handled by MMBASIC, if Peter says "use this or that command for it", I am fine with it. Best whishes Daniel Edited 2022-03-27 04:15 by Amnesie |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Thanks Peter. I think that cleared it up rather well - and in a bit more detail than the manual. :) It's easy to get caught out if you come from a background where interrupts are just interrupts because they are all in hardware. I can see how things get confused - I did too at first. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
Thank you Peter, That clears it up for me and I wish that level of detail was in the manual. CIN itself is only briefly described also in the manual. It seems to me that the use of: SETPIN pin, CIN would be the best way to catch any short interrupt. Checking that pin periodically in a program would tell you if there had been any interrupts, and how many, while MMBasic was busy doing other things. Bill Keep safe. Live long and prosper. |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9610 |
Perhaps it would be worthwhile taking the relevant statements in Peter's last post, and adding that to the manual under the interrupts section then? That seems to lay it out very firmly as to EXACTLY what happens, and having that specific description as part of the manual text would perhaps prevent any confusion or "Silly" questions about it later on. Not that I thought it was silly, Peter, people were just wanting clarification, and they now have that from your post above and everyone now seems happy. Case closed? I can see where the hardware people are coming from, and I can also see where the MMBASIC people are coming from. Hardware interrupts ARE instant, but under MMBASIC, you have the interpreter overhead added into the mix, and it can only check for and respond to an interrupt after each MMBASIC command has been executed. This is USUALLY quick enough for most people, but this thread DOES highlight an area where this can becomes a problem - but there is also a workaround using CIN as demonstrated. I've never seen this issue with respect to interrupts on MMBASIC during all the years I've been using it and following it, so this I think, is a unique case that demonstrated the issue. I guess nothing is perfect, but there will ALWAYS be overheads and issues like that with an interpreter rather then hardware C code.  Smoke makes things work. When the smoke gets out, it stops! |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 582 |
I agree. In fact I don't think Basic was ever meant to be at a level that supported interrupts. (which is why I don't use it) |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2642 |
"What is the point of interrupt that does NOT interrupt?" What would happen if MMBasic allowed interrupts to interrupt mid-command? The best case is that command has to be re-done after the interrupt is serviced, causing it to be late. What if it was more important / time critical than the interrupt? Worst case, the command is abandoned halfway through writing an important variable to memory and now the whole program is messed up. The way MMBasic handles interrupts now is good and practical. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
excellent  this is the key piece of information for many users. the MX170 version of MMbasic has 4 count inputs available. i don't know about other platforms.geoff: this would make a worthwhile section to add to the MMbasic manual (all versions to which it applies) explaining how to capture very short events by checking the count of a pin. for instance, the 'core meltdown' signal that may be sent by a device just before the 'core meltdown sensor' is vaporized! incidentally, one can always use an external RS flip-flop to capture a pulse. or even an external I/O expander such has been discussed on the forum in the past. cheers, rob :-) |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I've filed Peter's list away to try to remind me :) I really do like the CIN way as a work-around. In some ways better than an interrupt. John |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 675 |
Since the "CIN way" solves the problem so easy it is not even a "workaround"! But as said; there should be a better hint on this in the manual, no matter what "pro skilled" people can read out of it. The whole discussion tells me, that I am not the only one who was a bit irritated... |
||||
| Turbo46 Guru Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
To be fair, the manual DOES say that some short interrupts may be missed. Peter's explanation tells us clearly why and now we know that CIN is a way capture any of those that may be missed. Geoff is one of those relatively rare people that can not only write a program like MMBasic but provide a really excellent user manual for it. Not only that but MMBasic is free! Geoff and Peter have repeatedly ignored suggestions that they provide a donate button so that we can give them some recompense for their work. It is more than a bit uncharitable to complain when so often suggestions are considered and acted upon. I too have filed Peter's notes away and hope to see them in some form in later editions of the manuals. Bill Keep safe. Live long and prosper. |
||||
| zeitfest Guru Joined: 31/07/2019 Location: AustraliaPosts: 582 |
It has a lot of hidden cost. In most similar countries, for electronics and IT widgets, you would expect a vertical industry, ranging from garage start-ups to corporations at the national level, complete with an ecosystem of magazines, training, consultancies etc. The MMBasic stuff although enjoyable to watch, unfortunately consumes much of the oxygen at the low level - including this BBS (which originally was about alternative environmental tech), more at the magazine level, and has not created any real (edit - I mean realistic scale) commercial base in Australia. As such it has a large opportunity cost. Edited 2022-03-30 12:21 by zeitfest |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
MMBasic is software, you're talking about hardware really. There are lots of IT things which involve software but are nothing like your statements. Also, everything has a lot of hidden cost. Often it has an explicit up-front cost as well. True, although the same would have been true of Linux in its early days but look at it now. Or Python. Or <insert favourite language implementation here>. Whether that will change for MMBasic - who knows? Probably not, as there are thousands of other software systems which have fallen by the way side. Yet some take off and may not be the ones you'd expect. All sorts of people pointed out the failings of open software (& hardware) yet they've done well. Many said RMS (Richard Stallman) was wasting his time but things like gcc are best of class and very widely used. As you'll know, adopting a commercial product can leave one absolutely stuffed if that product is dropped / changed in an unattractive direction / has a bug you can't get fixed / etc. (Think of things Microsoft have dropped, or google for that matter.) At least with open source you can potentially maintain it yourself or have someone do it for you. John Edited 2022-03-31 05:13 by JohnS |
||||
| Page 4 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
