**** BEGIN LOGGING AT Thu Sep 17 02:59:57 2020 **** BEGIN LOGGING AT Thu Sep 17 03:36:02 2020 **** BEGIN LOGGING AT Thu Sep 17 04:54:01 2020 **** BEGIN LOGGING AT Thu Sep 17 05:04:53 2020 **** BEGIN LOGGING AT Thu Sep 17 05:26:42 2020 **** BEGIN LOGGING AT Thu Sep 17 05:33:02 2020 **** BEGIN LOGGING AT Thu Sep 17 05:39:32 2020 Sep 17 06:42:32 hi guys ... i am implementing a freq counter driver for generic gpio inputs, found that using them as irq is too dangerous (irq storms) so i started using a kernel thread with a usleep_range() to poll the gpio state.. wonder if there is a good and highres alternative for such scenrio ? Sep 17 08:00:50 rob_w: use eqep? Sep 17 08:01:51 besides quadrature decoding it can also be configured to count rising edges, falling edges, or both Sep 17 08:02:16 well we are not wired to such a hw block , just generic gpios .. Sep 17 08:03:05 i am reworking it use 2 threads , one with a low usleep_range() to just count the state changes, one thread to then recalc the counts with the time diff to a freq Sep 17 08:03:11 will see how it performs Sep 17 08:03:50 using gpios to do anything high-frequency in software will always be terrible... if you're stuck with it (despite the BBB having a ton of very nice hardware resources for exactly these kinds of purposes), use PRU Sep 17 08:05:07 if the input toggles at sufficiently high frequency that using an irq can't keep up with it, there's also not really any hope of keeping up with it using a thread Sep 17 08:05:28 (since a context switch to a thread is more time-consuming than an interrupt) Sep 17 08:07:14 in general, on a single-core system, using more threads to achieve the same goal will just make performance worse Sep 17 08:09:06 so if using an irq is too expensive then the conclusion is that you can't do this in linux using a gpio Sep 17 08:09:25 but a tiny PRU program can do it without raising any sweat Sep 17 08:14:12 well , the layout is what it is .. 2 inputs are wired to the omap timer6 and timer7 which i use in capture mode, that works nicely Sep 17 08:14:46 the generic gpios are only need to take upto 2khz signals Sep 17 08:16:30 apart the system is not just doing this stuff but alot more so i need to find ways to balance all but thanks (as always) for your insights, i enjoy those alot Sep 17 08:17:27 well thousands of interrupts per second is still going to give a lot of load on your system, and according to what you said in fact prohibitive Sep 17 08:17:42 so unless both PRU cores are already otherwise occupied, I stand by that suggestion Sep 17 08:19:15 it can happily poll the gpios at some generous sample rate and keep a pulse counter for each gpio of interest (in shared memory) Sep 17 08:19:40 and you can then sample those in linux on a fixed timer to get frequency values Sep 17 08:20:36 (or alternative pru can do that too, allowing your linux application to read the latest frequency values from shared memory whenever it needs them) Sep 17 08:20:41 hi , any one have an idea how to get a 32 bit debian for beaglebone black Sep 17 08:20:59 wifi version Sep 17 08:21:00 sixtyfourbit: ehm, as opposed to what? **** BEGIN LOGGING AT Thu Sep 17 08:23:09 2020 Sep 17 08:23:11 oh Sep 17 08:23:44 accessing the gpio controllers is of course slower, but your 2 kHz signals are (for PRU) not time-sensitive at all Sep 17 08:25:06 hmm it has some charm Sep 17 08:25:39 i could push it into my pru driver and let the pru count and the kernel calc .. hmmmmmmmmm Sep 17 08:25:46 of course whether adding (somewhat non-deterministic) accessing to the L3 to one of your existing pru programs is a problem will depend entirely on what it's doing of course Sep 17 08:27:38 sixtyfourbit: what made you think it was 64-bit? .. and equally interesting, suppose the cpu and os were indeed 64-bit (they're not), why would you want a 32-bit system? :P Sep 17 08:28:54 a pc salesman once told me that 64-bit computeres had two 32-bit cores Sep 17 08:29:00 -e Sep 17 08:29:09 lol Sep 17 08:29:21 both dual-core and 64-bit were new at the time Sep 17 08:29:27 new to PCs Sep 17 08:41:58 rob_w: in case it's of interesting: I've measured the number of pru cycles it takes to read the pin input register of a gpio controller to be: 39 cycles for gpio0, 35 cycles for gpio1, and 37 for gpio2 and gpio3 ... in all cases with a small amount of variance of course Sep 17 08:42:06 *of interest Sep 17 08:42:46 so is that reading 1 pin or 1 controller ? Sep 17 08:42:47 I get why gpio0 is slower, though I'm not sure why gpio2/3 are slower than gpio1 Sep 17 08:43:12 for reading the gpio controller's input register, which contains the pin level for all 32 gpios of that controller Sep 17 08:43:19 alright Sep 17 08:43:58 so i got 2 on gpio1 and 2 on gpio2 .. which would add around 72cycles .. hmm Sep 17 08:44:37 then tobe added incrementing the counters **** BEGIN LOGGING AT Thu Sep 17 08:51:24 2020 Sep 17 08:52:02 you could also use the gpio controller to do edge detection, which means it would suffice to poll the gpio controller once per (worst-case) minimum period of the signals you're measuring instead of once per (worst-case) minimum low/high time Sep 17 08:52:51 (and it would simplify the logic to update the counters) Sep 17 09:00:32 zmatt: i dont get that .. u mean using the gpios as irq only on rising ? Sep 17 09:04:37 yeah, even though you can't receive the irq in pruss you can still read and clear the irq status bits for your target pins (this shouldn't conflict with the kernel as long as the kernel has no interrupts configured on these pins), and then you only need to increment each counter conditional on a bit-test Sep 17 09:05:17 instead of reading the input state and then having to compare that with the previous input state (that you'd need to save) to determine if an edge has occurred Sep 17 09:05:44 ahhh isee whata menat Sep 17 09:05:46 meant Sep 17 09:17:38 i.e. something like https://pastebin.com/FJu6M1Rp Sep 17 09:18:44 (updating the counters can of course be optimized if you have spare registers in which you can keep the counters) Sep 17 09:19:05 this is ignoring setup of course **** BEGIN LOGGING AT Thu Sep 17 10:14:30 2020 Sep 17 11:48:54 m **** BEGIN LOGGING AT Thu Sep 17 11:52:03 2020 **** BEGIN LOGGING AT Thu Sep 17 12:13:31 2020