 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 : Oneshot CFunction for MM2
  Page 2 of 2 |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 11144 |
Yes but not the second version and also I don't even have a PIC32 dev environment or the unlocked compiler - in other words, this version is deprecated Edited 2026-03-01 20:09 by matherp |
||||
| Mechanical Newbie  Joined: 23/02/2026 Location: AustraliaPosts: 7 |
Hi matherp, phil99 Firstly, thanks to all for all the help on this - very much appreciated! I was using the Explore-28's only because I had a couple lying around, and because I'm quite familiar with the code. I developed a Reflow Oven controller using an Explore-100 (which I am using all the time - published in the Silicon Chip magazine), and some reasonably complicated system code on Explore-64's. But I'm not "wedded" to these. Thanks for the tip about the Picomite option - I found the number of variants somewhat daunting, but the MMBasic codes look familiar (Geoff's Manual looks like the Micromite, and Micromite Plus manuals rolled into one, with a whole lot more commands and functions added!). I see Silicon Chip have published a RP2350B development board - which looks good, but is probably overkill. Altronics here in Perth have RP2040 and RP2350A Development boards. I'm guessing any of the above would do? My pin requirements are quite modest. BTW - I was interested to see the Structure type added - I cut my teeth with Turbo Pascal in the days of DOS, and used RECORD types - a Structured Type - often even Arrays of Records. In Turbo Pascal, the WITH 'record identifier' could be used to allow the components of the Record to be referenced without having to restate the identifier name. That was about 40 years ago! I STILL think Turbo Pascal is a great, efficient, and structured programming language - but Windows versions will not run much after Windows XP. |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 3116 |
Tested ONESHOT on a RP2040 and have not seen any problems other than the parameter POSITIVE can't be abbreviated to POS. If using analogue input a point to note with the RP2040 is the reliable accuracy is about 8 or 9 bits due to an error on the silicon. If you choose the RP3250 make sure you get the RP3250-A4 version. The older (but often cheaper) A2 has issues on the digital inputs. I forget the details but there is info elsewhere on TBS or other web sites. |
||||
| Mechanical Newbie Joined: 23/02/2026 Location: AustraliaPosts: 7 |
Hi matherp, phil99 Thanks for the heads up, phil99, I'll try to get the A4 version. I do recall a mention of the need to use an external pull-down of 8.2Kohms in Geoff's Picomite manual, due to some digital input issue. matherp, thanks for your 'scope image - as it happens I have the same 'scope, only 2 channels - so I have been producing the same image using the Exp-28! But your image prompted me to investigate the timing between the pulse ending, and the start of the trigger pulse, in far more detail. With my present initialising arrangements and a 100Hz triggering rate, if I stretch the command output pulse width well beyond my 9.7ms clamp, until the time between the end of the pulse, and the start of the next trigger pulse drops to only 30us, then I could cause the output to flip from normal to inverted, then back again following the next call - every time - unless following calls are for a smaller pulse-width, in which case the mode would not change, so if inverted it would stay inverted, until the next maximum pulse-width. Of course the initial delay also impacts this time gap - the longer the initial delay, the shorter the allowable pulse-width (unrelated to the 13.1ms mathematical limit). If I increase the 30us timing gap, to 80us, the problem goes away - with my 100Hz trigger rate, and 20us initial delay, this allows my command pulse-width to go up to 9.9ms without issues. 9.95ms causes issues, but only to be expected (now!). Now, I know I had been initially using different start-up configurations, and a longer initial delay - but I am at a loss to understand why the inversions were popping up previously - because my maximum generated pulse-width request never exceeded 9.62ms! Must have been a marginal, and combinatorial effect. Now I am using a start-up of: "SETPIN 15, CIN : ONESHOT 0,0,0" with the subsequent periodic ONESHOT initial delays set to 20us, and the pulse-width request clamped to 9.7ms {"ONESHOT 18, 20, CINT(msecs*1000)}, and so far all's good. Apologies for my confused queries...Glad to have gotten to the bottom of this (I hope). Best Regards |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8738 |
The issue with the A2 version is that, when configured as digital inputs, the GPIO pins always have a high value resistance up to 3V3 so they are always sourcing a small current. If they are set up to be active high then this current is sufficient to activate them in many cases, or at least compromise the noise threshold. Adding an external 8K2 resistor to GND is enough to sink the leakage current to a level where it's safe. Active low inputs, where either an internal or an external pullup is used, are not affected. Neither are ADC inputs when GPIO pins are configured for that. As most micro-controller digital inputs tend to be active low the A2 stepping isn't really a problem for most people, as long as you are aware of it. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mechanical Newbie Joined: 23/02/2026 Location: AustraliaPosts: 7 |
Hi matherp, phil99 I've investigated the pulse inversion further, and suspect my findings may possibly apply to the Picomite Oneshot as well. With respect, could I suggest the oneshot documentation, as well as the statement: "maximum pulse length in seconds = (65536*8)/(CPU speed in Hz)" include the statement: or "maximum pulse length not to exceed trigger repetition interval - delay period - 20us" whichever is the smaller. I understand the trigger interval - delay period is obvious, otherwise the output pulse would overlap the trigger pulse leading edge. What I have found, is that the output pulse must complete about 8-10usec before the trigger pulse leading edge, or otherwise the output pulse will invert, or become a free-running square wave with a half-cycle duration of 13.1ms (in my case, using a 40MHz CPU speed). It appears (to me at least) that the 8-10us is a needed initial re-setup time, following pulse completion. I have suggested to use the 20us, to provide a safety margin, after testing a large number of delay and pulse-width variations. In my case, using a 20us delay, and trigger repetition period of 10ms, the calculation is: maximum pulse-width = 10ms - 20us - 20us = 9.96ms - test works at 9.97ms. Hope this proves useful - I must admit this is obvious, in hindsight! Hi Mixtel90 - thanks for the explanations. I guess the take-home is: For the Stepping A2 variant, current leakage to the pins from the supply makes the SETPIN x, DIN, PULLDOWN command inadequate to prevent false pin high sensing. An added external 8k2 pulldown resistor solves this issue. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5823 |
Hi mechanical, If you describe your test setup, used command, and preferably waveforms (maybe a picture) of the anomaly, I can verify on PicoMite. But since Pico internals may operate different the issue may not exist. If I ready your text and try to understand, I think you are referring to a re-triggering before the previous has ended. If the ONESHOT generates an inverted pulse, and the retrigger starts with the wrong level the whole output waveform is inverted. But I need your exact command and values, and input signal description. Volhout Edited 2026-03-04 17:59 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11144 |
There is no practical limit to the periods on the PicoMite. Note I am just about to post 6.02.01RC0 which will include the additional optional parameter for a quiescent period after the output pulse (trigger hold-off) |
||||
| Mechanical Newbie Joined: 23/02/2026 Location: AustraliaPosts: 7 |
Hi Volhout I am using the 2nd version of ONESHOT running on an Explore-28 at 40MHz. My issue is re-triggering after the previous pulse has ended, but without sufficient "dead-band" between these two events. I think the is a setup time issue, and it appears matherp is dealing with this - see below. My setup commands using PWM 1C on pin 6, trigger pin 15, and output pin 18, are: ' pins 6 and 15 are connected to trigger the input SETPIN 15,CIN ONESHOT 0,0,0 PWM 1,100,50,50,0.5 ' sets up the 100Hz repetitive re-triggering pulse SETTICK 2000, updatePW, 1 ' change required pulse Then in the processing loop I have: Do '---- '---- Loop SUB updatePW ONESHOT 18,120,CINT(9.9 * 1000) ' to get a 9.9ms pulse, after a 120us delay END SUB This is not exactly my configuration, as I have a periodic external radio signal that determines when the required output pulse-width is to be changed - but the SETTICK simulates this adequately. Good to check the output pulse on an oscilloscope. The above configuration invokes a 26.2 ms square wave output - on my Exp-28. The above settings breech the pulse-width command limitations described in my politely suggested limits - as the requested delay plus requested pulse-width exceeds the re-triggering period set by the 100Hz PWM frequency (10ms period). I can believe it might be possible to generate 9.9ms pulses, at 100Hz rates, with a long pre-delay - but not on this version of ONESHOT. To do this, without skipping pulses, would require the next shot to be set up, and triggered, before the current pulse has completed. I understand matherp is including a "trigger hold-off" figure, to provide the pre-trigger period needed to setup the next "shot". I'm guessing this might imply that exceeding my suggested technical limits, would generate a skipped pulse, rather than risk pulse inversion or free-running oscillation (both of which I have regularly observed). My technical limit degenerates, allowing very long pulses, if the trigger repeat period is also long enough. BTW - from my initial review, I feel the Picomites are great and very competent products, and matherp's coding is superb - I had no intention of slighting anything nor anybody, but was just observing a technical limitation (I don't think it logically makes a lot of sense to output a pulse-width that is longer than the re-triggering duration, as this is then no longer a pulse - more a case of the pin being permanently ON - although I do see a benefit of the output pulse smoothly going up to the re-triggering duration, without ever going OFF) - i.e. the output ranging from fully OFF, through increasing pulse-widths, to fully ON. |
||||
| Page 2 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
