**** BEGIN LOGGING AT Thu Jun 13 02:59:57 2019 Jun 13 04:44:35 is there an evolving standard for headers on the pocket beagle? male vs female, pins/sockets up/down? Jun 13 04:58:17 bbb.io/capes Jun 13 05:17:44 BAH on capes.... "Expansion Boards"! Jun 13 13:34:19 Anyone know whether the slew mode for the GPIOs works switched to "slow"? I haven't been able to find too much info on it but I think I read somewhere that it was "experimental". Probably very old information. Jun 13 13:35:27 That's regarding BBB Jun 13 13:59:50 did you look at the pin with a scope outrageous_ ? Jun 13 14:22:03 Rickta59: No, Haven't gone that far yet. Scope is at workshop a few miles away and I'm at home fiddling with the BBB I am gearing up to create an overlay to try it out soon. Just wanted to see if anyone here had experience with it. Jun 13 14:22:46 what are you driving with the gpio pin that needs adjustment? Jun 13 14:30:56 Rickta59: The intention was to use it for inputs as I understood from something I read that it would delay the transition between states that could act as a debounce. Possibly that is a misunderstanding? Jun 13 14:35:29 I thought it was used for controlling how hard the output is driven Jun 13 14:36:32 Rickta59: Given that my knowledge of these things is not great, the odds that you're right and I'm wrong are probably high :) Jun 13 14:44:42 you might be right and i'm confused Jun 13 14:44:48 this book talks about it: Jun 13 14:44:52 Exploring BeagleBone: Tools and Techniques for Building with Embedded Linux Jun 13 14:46:34 this seems to indicate it is an output thing Jun 13 14:46:37 https://e2e.ti.com/support/processors/f/791/t/271189 Jun 13 14:47:35 "The slew rate control changes the output buffer drive strength during the rise/fall transitions. " Jun 13 14:48:01 http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf look for slewctrl Jun 13 14:59:43 I see. Perhaps it's in this case intended for outputs. It seems to be a concept with both inputs and outputs according to wikipedia, but I'm now doubting that it can do what I initially thought. I will have to experiment :) Jun 13 15:02:57 what kind of input are you sampling? Jun 13 15:14:55 Probably nothing with a very high frequency. I'm going to be using this for various kinds of equipment telemetry/monitoring. What I am working on currently has to do with water reservoir level, most likely with simple float switches. I do not know exactly what to expect regarding future use cases though. Jun 13 15:41:54 outrageous_: the slew rate setting just affects outputs, is not very well specified, and mostly has to do with EMI reduction at the expense of timing accuracy as far as I understand Jun 13 15:44:53 outrageous_: the gpio controllers do support debouncing, although the debounce time cannot be set per pin and I'm not sure if the kernel driver offers any way to actually enable debouncing Jun 13 15:46:08 I'd suggest simply debouncing in userspace Jun 13 19:32:04 zmatt: I see. Yes, Software debounce appears to be an easier solution. Jun 13 21:03:31 outrageous_: to complete what zmatt said the slew rate affect the maximum current that is injected into (or sinked from) the pin in output mode in order to get it from low logic level to high logic level Jun 13 21:03:54 because you have all the stray capacities on the line you have to fill up, and that takes either time or current Jun 13 21:12:55 to debounce in software the quick and easy way is every 1 ms increment or decrement a counter if gpio is high or low, staying in [0; 10] for instance Jun 13 21:13:16 if you have a 0 → 10 transition then it's a rising edge, if you have 10 → 0 it's a falling edge Jun 13 21:13:41 that's a quick approximation to a real digital RC filter but not so far off Jun 13 21:24:55 mawk: Cool. Thank you for the clarification and suggestion regarding software debounce :) Jun 13 21:25:38 you can also hardware debounce, eg use a capacitor Jun 13 21:30:56 mawk: Yes. I think SW makes more sense at this point as to not have to add complexity and components to the "cape" board. Was just thinking about the slew mode as my initial thought/hope was that it would be usable for input debounce. Jun 13 21:35:34 yeah I'd use RC filtering in case there's a problem with noise pickup creating annoying amounts of spurious interrupts, but not for something like debouncing a mechanical switch Jun 13 21:36:52 mawk: are you suggesting polling? ew Jun 13 21:37:23 zmatt: what I do is start the 1kHz clock on the first edge, then sample every ms Jun 13 21:37:40 and if I'm stuck one way or another I stop the clock Jun 13 21:37:47 that's stlil unnecessarily complicated Jun 13 21:38:34 what would you do instead ? Jun 13 21:39:11 just check if value hasn't changed recently, if not don't acknowledge the edge ? Jun 13 21:39:53 also yeah for BBB it's quite complicated, I wouldn't do it like this Jun 13 21:39:58 I was speaking for what I do on a mcu Jun 13 21:42:19 https://pastebin.com/A7T055H3 Jun 13 21:45:23 ah Jun 13 21:45:24 hmm Jun 13 21:46:17 so it's to prevent stuff like 1 0 1 where you don't sample the 0 because it went too fast Jun 13 21:46:55 it's just because sampling at a fixed interval is silly Jun 13 21:49:15 I guess the only downside is that this would result in high cpu load if the gpio keeps toggling for an extended amount of time, but that's not a situation one normally encounters Jun 13 21:49:38 (and probably would cause high cpu load anyway, since the kernel irq would still trigger) Jun 13 21:50:31 if you're using an edge-triggered event and a timer, this is the simplest way to combine the two to do exactly what's desired Jun 13 21:50:35 but it could still fire a ton of interrupts in a short time Jun 13 21:50:50 if you get 0 1 0 1 0 1 Jun 13 21:51:12 if they're slow enough to be not be coalesced Jun 13 21:51:15 yes Jun 13 21:51:19 indeed Jun 13 21:52:11 the counter thing is to exactly mimic what a RC filter is doing, eg summing up the input Jun 13 21:52:40 but the RC filter is not an ideal to be met, it's merely the simplest hardware solution Jun 13 21:52:57 Yes. And I think for this particular use case at least, I would like to know if was switching very rapidly, which to me makes sense to also do in software. Jun 13 21:54:52 None of the use cases I have in mind at the moment involve anything that should be switching very rapidly. Mostly just low tech stuff. Jun 13 21:55:08 outrageous_: yeah the logic of what to do on gpio event can be more complicated of course, including taking into account how often it has toggled since the value last stabilized, and if necessary disabling the gpio irq (temporarily or until operator intervention) Jun 13 21:55:33 zmatt: indeed :) Jun 13 21:55:51 yes it's the hardware ideal but it has nice properties, for instance not firing up repeatedly when the input is just slow enough to not coalesce but toggling repeatedly, which a human pushing the switch can't do and is just hardware bounce Jun 13 21:57:22 mawk: thing is, for your solution to be worth it you'd probably also need to disable and reenable the irq, which itself takes substantial time and adds more complexity Jun 13 21:57:38 I do it without the irq, just reading the gpio Jun 13 21:57:44 but yeah on BBB under linux it's not ideal Jun 13 21:58:19 you said yourself "start the 1kHz clock on the first edge" Jun 13 21:58:22 that requires an irq Jun 13 21:58:42 and polling continuously is not something that should be suggested seriously :P Jun 13 21:58:52 not when avoiding it is this easy Jun 13 22:02:34 ah yes for the first edge as an optimization; but then I don't really do it like that on my mcu, I just have a timer that auto starts on the gpio edge, and I stop the timer after I decide it Jun 13 22:03:03 but it's a bit clunky yes Jun 13 22:03:51 on an mcu that may make sense (depending on how many gpios to want to monitor and what else you want to do), but that's not the platform being discussed Jun 13 22:04:59 the debouncing algorithm says the same, the goal is ultimately for instance with a button to get a single signal with a single push Jun 13 22:05:11 just avoiding coalesced edges doesn't do it entirely I think Jun 13 22:05:34 my code accepts the new gpio state when it has stabilized Jun 13 22:05:52 I don't know anything better to do Jun 13 22:07:06 (my pseudo-code I should say) Jun 13 22:10:27 Well, I appreciate the suggestions from both of you and will certainly keep them in mind when I implement this over the weekend :) Jun 13 22:31:53 Hi. I am having problems writing to the cp14 debug registers. Some ARM devices, ie Zynq, have security controls to disable or ignore writes. Does the am335x have anything like this? I am not running Linux. Jun 13 22:51:17 Hi kiwichris. I'm afraid that's outside my knowledge. Mind me asking what you are running on it since not Linux? Jun 13 23:01:52 RTEMS. We support a few beagles. We maintain a "transparent" port of FreeBSD running on RTEMS with real-time threads that gives us drivers for network, USB, SD, eMMC etc. I am attempting to get our libdebugger to run. This is a built-in software based gdb remote server that uses the cp14 support to manage stepping etc in a running system. However a write to a cp14 reg causes an exception. The code works well on a Cortex-A9 based Zynq. Jun 13 23:07:51 kiwichris: Cool and interesting, thanks for sharing :) Jun 13 23:10:06 outrageous_: no problem; we have a GSoC project this year to get the PRU running which will be interesting, an RTOS controlling a dedicated real-time device, it would be interesting to loop some IO between them to test each other out; have to get the thing working first :) Jun 13 23:49:20 Hello all. Anyone tell me how to factory reset my Pocketbeagle? Jun 14 01:41:20 kiwichris: the DBGEN signal is controlled by a bit in an ICEPick register, which is only accessible via JTAG (although I've made a hideous hack that is enable to set the bit via software control by manipulating pin config registers to make ICEPick think the jtag signals are toggling. this however does require nTRST to be high, whereas it has a pull-down on the BBB) Jun 14 01:43:54 kiwichris: however what's causing your exceptions is that the cortex-a8 uses memory-mapped debug registers, not cp14-based control Jun 14 01:56:29 the only cp14 registers are the id register (DBGDIDR) and the internal views of the status/control (DBGDSCR) and data transfer (DBGDTRTX/RX) registers Jun 14 01:57:56 (and the two registers which are supposed to contain the memory address of the cpu's debug registers and the debug rom table, except TI couldn't be arsed to configure those correctly) **** ENDING LOGGING AT Fri Jun 14 02:59:58 2019