**** BEGIN LOGGING AT Sun Jun 14 02:59:57 2020 Jun 14 12:55:46 zmatt: after you left I hooked up the motor and switched the pins to pulldown since the encoder would be sending the lows and highs Jun 14 12:56:14 the encoder has 3.3v push-pull outputs? Jun 14 12:56:24 it did not work but my input voltages were low going into the encoder Jun 14 12:56:33 it has a sensor voltage line Jun 14 12:56:36 I gave it 3.3V Jun 14 12:56:43 from the BBB Jun 14 12:56:52 have a datasheet of the encoder? Jun 14 12:57:06 but when I test it with the multimeter it is low like 0.7V Jun 14 12:57:32 ehm, if the 3.3V supply is 0.7V, that's called being "off" Jun 14 12:58:23 this is the best I got Jun 14 12:58:24 https://www.servocity.com/118-rpm-hd-premium-planetary-gear-motor-w-encoder Jun 14 12:58:29 has some specs Jun 14 12:58:38 the encoder spins so I beleive it is working Jun 14 12:58:53 would the alligator clips ruin everything Jun 14 12:58:59 should I solder everything up Jun 14 12:59:42 I mean, it doesn't matter how you make the connection, as long as it's a proper connection Jun 14 13:00:14 the encoder lines also don't need to carry significant current so it doesn't even have to be a great connection, as long as it's connected Jun 14 13:00:33 for the power to the encoder at the pins I get 3.3V Jun 14 13:00:53 if I test the aligator clip at the wire lead going into the encoder it is lower Jun 14 13:01:16 I need to be at 3.3V power going into the sensor to have a chance right? Jun 14 13:01:49 if it's significantly lower than 3.3V then obviously your connection is broken Jun 14 13:02:31 I need to mess with that then Jun 14 13:02:40 I thin this is just a power/wiring issue Jun 14 13:02:49 was I right to switch to pulldown on the pins though? Jun 14 13:03:16 the code sees it it says waiting for rise but the signal never happens Jun 14 13:03:35 in the pull up state it said waiting to fall but any signal would be additive so it would never fall Jun 14 13:03:36 pullup/pulldown won't matter Jun 14 13:03:41 that is why I switched Jun 14 13:03:45 ok Jun 14 13:04:06 internal pullup/down is mostly just to keep the pins from floating if nothing is connected to them Jun 14 13:04:12 let me try and make better connections Jun 14 13:04:28 I will report back in a bit Jun 14 13:04:31 if it is properly connected to the encoder, its output will completely override the BBB's weak internal pullup/pulldown Jun 14 13:04:40 ok Jun 14 13:15:42 are you sure the encoder outputs aren't open collector/drain? Jun 14 13:16:41 mru: "The pulse amplitude of the encoder’s output square wave signal is dependent on the voltage you supply the sensor. For example, if you provide 5V to Sensor Voltage +, then Channels A & B will have a pulse amplitude of 5V." Jun 14 13:16:51 sounds push-pull to me Jun 14 13:17:06 yeah Jun 14 13:17:25 where did you find that text? Jun 14 13:17:31 on the page he linked Jun 14 13:17:45 under "tech tips" Jun 14 13:17:59 ah, I only noticed the silly videos Jun 14 13:18:24 as usual for all this rc shit, the state of documentation is atrocious Jun 14 13:19:16 so what does that mean Jun 14 13:19:33 I was about to say how do you even know the pinout, but that's "documented" in one of the product photos Jun 14 13:19:41 yeah Jun 14 13:19:44 it is not the best Jun 14 13:20:21 I'd connect it to a bench power supply and measure those outputs without connecting them to the beagle Jun 14 13:20:36 ok Jun 14 13:20:41 that seems a bit unnecessary Jun 14 13:20:58 if it doesn't work as expected, that's what I'd do Jun 14 13:21:04 to get a handle on what it's actually doing Jun 14 13:21:17 well his problem was measuring 0.7V on the 3.3V supply line :P Jun 14 13:21:27 that's called a broken connection Jun 14 13:21:28 ok, that's bad Jun 14 13:22:00 how does that even happen? Jun 14 13:22:09 I'd understand 0 V Jun 14 13:23:09 leaked from the encoder outputs back to encoder supply maybe? although no, he said he changed the inputs to pulldown Jun 14 13:24:17 dunno, but with MattB0ne's history I'm fairly confident it's just user error, either in hooking things up or in the measurement itself Jun 14 13:30:08 i cannot even argue with that statement Jun 14 13:30:11 its fair Jun 14 13:30:40 so I checked the supply Jun 14 13:30:43 it is 3.3 Jun 14 13:30:51 https://www.robotshop.com/media/files/pdf/638324_datasheet.pdf Jun 14 13:30:54 it's open collector Jun 14 13:30:55 i have a male to female jumper Jun 14 13:31:20 and I just take the encoder lead and push into the female side Jun 14 13:31:45 I tried putting my MM on the channel A line Jun 14 13:31:56 mru: how do you know this is the encoder? Jun 14 13:32:17 same model number Jun 14 13:32:24 i get a reading 0.08V Jun 14 13:32:31 and same photo Jun 14 13:32:37 If I disconnect the pwer to the encoder it drops to 0 Jun 14 13:32:42 https://www.robotshop.com/uk/12v-118rpm-9582oz-in-hd-premium-planetary-gearmotor-encoder.html Jun 14 13:32:52 when the motor is running I just do not get anything out of the channel lines Jun 14 13:33:12 MattB0ne: ok, so mru just discovered that the single line of documentation that website you linked has for the encoder outputs, is wrong Jun 14 13:33:23 sigh Jun 14 13:34:45 mru: maybe it has internal pull-up though? otherwise it's weird to be specifying an output rise time Jun 14 13:34:46 always assume documentation is as accurate as it is plentiful Jun 14 13:35:02 that is a good rule of thumb Jun 14 13:35:11 and I need to stop going to cruddy vendors Jun 14 13:35:14 MattB0ne: at the very least, use PIN_INPUT_PULLUP Jun 14 13:35:26 maybe that's enough, maybe it isn't, but it's a start Jun 14 13:35:32 am I reading this rightthe output voltage will be below 1V Jun 14 13:35:41 I tried with pull up same thing Jun 14 13:35:54 you're not reading it right Jun 14 13:35:54 but i fixed the wiring Jun 14 13:36:16 so now with the fixed wiring try it with PIN_INPUT_PULLUP Jun 14 13:36:58 how strong are those pull-ups? Jun 14 13:37:00 50k? Jun 14 13:37:16 mru: oh never mind the output rise time is specified with load pull-up and capacitance, at least I assume that's what the RL and CL mean Jun 14 13:37:21 100K±50% Jun 14 13:37:44 maybe it needs to be stronger Jun 14 13:37:51 I'd try with 10k or less Jun 14 13:38:04 probably yeah Jun 14 13:38:25 but that requires soldering or breadboarding, so it doesn't hurt to first just try it with internal pull-up anyway Jun 14 13:40:19 no bueno Jun 14 13:40:19 they're saying output leakage typ < 0.1 uA, so then a 100K pull-up will win easily. but rise time will be shit so you'd run into problems if the motor is turning too fast Jun 14 13:40:33 i am running slow Jun 14 13:41:27 MattB0ne: how slow? Jun 14 13:42:37 like, 1 rpm on the output shaft is already 854 Hz (3416 phases per second) Jun 14 13:42:45 sorry, 60 rpm Jun 14 13:42:55 1 revolution per second Jun 14 13:43:03 and what are you observing exactly? Jun 14 13:45:06 because running the pru program via debugging.py is not really suitable for testing with a motor obviously since it makes the pru run excruciatingly slow (since it's halted and its state is inspected after every single instruction) Jun 14 13:45:25 though it would still show activity, just random activity Jun 14 13:46:35 i would say takes a good 7 sec for a full rotation Jun 14 13:47:16 same as before Jun 14 13:47:22 no real change on the channel lines Jun 14 13:47:36 stuck at 0.08V Jun 14 13:47:50 most probable explanation would be that your connections just suck Jun 14 13:48:05 especially since that was also the problem for the supply line Jun 14 13:48:13 I can try tinning the wire leads Jun 14 13:48:21 and push that into the female headers Jun 14 13:48:24 please don't Jun 14 13:48:42 so I can solder the lead to a male header pin Jun 14 13:48:44 get some male headers and solder your wires onto those Jun 14 13:48:50 ok Jun 14 13:48:59 let me do that for all of the leads and see what we get Jun 14 13:49:21 and obviously triple-check that you're inserting them into the right place Jun 14 13:50:37 what I did once for a beaglebone was write the pin numbering onto a stickers and stick those onto the side of the BBB's expansion headers Jun 14 14:07:52 I marked the ones I ma using Jun 14 14:08:01 one that I test on is third from the bottom Jun 14 14:08:22 so solder male headers that go to female to male jumpers that attach to the board Jun 14 14:08:38 I measured the supply Jun 14 14:08:41 and it is 3.3V Jun 14 14:09:16 If I unplug a channel line and use my positive terminal on that line and negative on the ground with my multimetere Jun 14 14:09:29 I am stuck at 0.08V regardless of what the motor does Jun 14 14:09:51 well duh you unplugged it from the BBB's internal pull-up Jun 14 14:10:04 shouldnt the encoder send a signal Jun 14 14:10:34 it is generating square waves right so I should see that Jun 14 14:11:49 I'm guessing you don't remember mru finding a spec sheet that indicated that it was an open-collector output rather than a push-pull output Jun 14 14:13:05 now I'm not sure how the conclusion was drawn that that spec sheet is indeed for this encoder, but it would explain why you're seeing 0V Jun 14 14:13:47 but connecting it to a BBB input with internal pull-up enabled should allow it to work (at low speeds) Jun 14 14:17:41 now my pins are set to input Jun 14 14:17:52 since the encoder is a sink Jun 14 14:17:55 should be outs? Jun 14 14:17:56 what do you mean "now" ? Jun 14 14:18:01 what? Jun 14 14:18:02 no Jun 14 14:18:14 they always were Jun 14 14:18:20 i haven't change that Jun 14 14:18:23 they should be input with pullup Jun 14 14:18:46 they are Jun 14 14:19:02 so I should check the line whil plugged in Jun 14 14:19:10 let me see what it does Jun 14 14:19:20 yeah just run debugging.py ... it probably won't count correctly, but it will show activity Jun 14 14:24:24 i think I still got a connection issue Jun 14 14:24:32 i think my male headers are not long enoguh Jun 14 14:24:51 if I use my mm in that squre in the female header Jun 14 14:24:53 I get 3.3 Jun 14 14:25:12 If I tocuh the expsoed solder on the male header Jun 14 14:25:20 it is 0.8V Jun 14 14:25:26 what does debugging.py print? Jun 14 14:25:37 no activity Jun 14 14:25:52 what line is it waiting on? Jun 14 14:26:05 A high Jun 14 14:26:18 A is high, wait for A fall Jun 14 14:26:58 if the actual A signal of the encoder measures 0.8V then that does imply a connection problem Jun 14 14:27:34 wait but didn't you say you connected it using jumpers? Jun 14 14:27:59 this is the power lead Jun 14 14:28:21 I thought you said earlier that you fixed the power connection? Jun 14 14:28:38 anyway, go fix your connections Jun 14 14:29:09 all four leads have male pins solder on Jun 14 14:29:20 and they plug into female to male headers that go to the board Jun 14 14:29:39 "female to male headers" ? Jun 14 14:29:52 jumpers i mean Jun 14 14:30:52 I think longer headers will help Jun 14 14:31:02 I have trouble imagining that, but you do you Jun 14 14:33:16 lol Jun 14 14:33:24 actually let me try mru example Jun 14 14:33:38 if I send 3.3V from my PSU to the unit Jun 14 14:33:45 it takes the wiring out since I power my motor that way Jun 14 14:34:29 just to confirm, you've made sure you have a solid ground connection right? Jun 14 14:34:38 between bbb and motor/encoder Jun 14 14:34:47 i am using the BBB GND Jun 14 14:34:58 ok Jun 14 14:35:00 power and GND from the BBB Jun 14 14:35:09 so 4 connections Jun 14 14:35:16 I am going to mvoe that to the psu Jun 14 14:35:18 set at 3.3V Jun 14 14:35:25 please don't Jun 14 14:35:25 and spin the motor slow Jun 14 14:35:29 no? Jun 14 14:35:38 or at least, not while it's connected in any way to the BBB Jun 14 14:35:49 ok i can do that Jun 14 14:36:14 what can I expect to get from the channel line Jun 14 14:36:24 nothing, if they're indeed open-collector outputs Jun 14 14:36:45 that spec sheet is presumably correct since the product photos on both pages are all the same and both mention the same model number 638324 Jun 14 14:36:47 so really it is a pointless exercise then Jun 14 14:36:54 yep Jun 14 14:37:02 man this thing sucks Jun 14 14:37:07 how the hell do you trouble shoot Jun 14 14:37:21 so wire it up with some pullups on a breadboard Jun 14 14:37:22 I don't know, I never manage to produce this much trouble in the first place Jun 14 14:37:41 you dont have my skill =) Jun 14 14:37:58 and you just measure in places and figure it out Jun 14 14:38:00 dunno Jun 14 14:39:06 let me go through a bread board Jun 14 14:39:16 that really isnt header length dependent Jun 14 14:39:25 and I can check more stuff that way Jun 14 14:40:07 I will try mru thing of wiring up pull-ups too Jun 14 14:40:58 when things aren't working, my strategy is to simplify as much as possible until something works as expected, then expand from there Jun 14 14:41:20 so I gut out the beagle then Jun 14 14:41:22 in this case that means removing the beagle Jun 14 14:41:28 yup Jun 14 14:41:33 this is painful Jun 14 14:41:46 better pruchasing would cricumvent this Jun 14 14:41:57 purchasing would circumvent a lot of this Jun 14 14:42:20 pru-chasing is what you're doing now :) Jun 14 14:42:49 there's probably nothing wrong with that motor Jun 14 14:42:54 it's just poorly documented Jun 14 14:43:25 you guys do this a lot in your day to day job Jun 14 14:43:39 "this" ? Jun 14 14:43:49 pru chasing Jun 14 14:44:02 me, no Jun 14 14:44:59 I have no idea what you mean by that honestly Jun 14 14:44:59 so my plan is to use LED as a read out Jun 14 14:45:27 I am going to try and diagnose with bread board Jun 14 14:46:07 I would need some manner of detecting the activity as I wire the pull ups Jun 14 14:46:16 otherwise how would I know Jun 14 14:46:18 scope? Jun 14 14:46:26 scope if available Jun 14 14:46:42 or bbb otherwise Jun 14 14:46:53 I dont have a scope Jun 14 14:47:04 everybody should have a scope Jun 14 14:47:17 by BBB you mean the debugging code that we have been using Jun 14 14:47:21 it should pick up stuff Jun 14 14:47:29 fair Jun 14 14:47:44 I am slowly getting stuff Jun 14 14:47:48 scopes are pretty pricey Jun 14 14:48:00 they're worth it Jun 14 14:48:05 my PI will probably not be on board Jun 14 14:48:16 I am in life sciences so all of this work is off the reservation Jun 14 14:48:31 you can get a half-decent scope for 500 euros/dollars/pounds Jun 14 14:49:04 I may be able to borrow one Jun 14 14:49:38 let me work the bread board for a bit Jun 14 14:49:47 I am hoping if I can get a clean 3.3V that it will work Jun 14 14:50:06 though I mean it was soldered so I am not sure why I would get such a big drop throguh the connector Jun 14 14:51:13 MattB0ne: https://pastebin.com/kB8siRnn Jun 14 14:51:39 that will continuously monitor r31, thus you'll be able to see if anything is happening on the pru inputs Jun 14 14:52:56 after connecting bbb (gnd, 3.3V, both pru input pins) to breadboard, confirm that you see activity if you connect a pru input to ground (with a wire/jumper) Jun 14 14:53:23 then proceed to connect gound, power, and signals to the encoder Jun 14 14:55:01 ok Jun 14 14:55:31 there are only two outcomes possible when you connect a signal to the encoder: either the BBB is able to pull up the encoder output, in which case you won't see activity on the pru input but the encoder output will now measure high (3.3V, or reasonably close), or the encoder output will drag the bbb input low, in which case you'll see activity from the python script Jun 14 14:59:48 we shall find out Jun 14 14:59:53 setting it up Jun 14 15:21:28 ok I am not sure how the 3.3V plays a role in the breadboard Jun 14 15:21:45 I have the pru pin to bread board Jun 14 15:21:52 and bread board to BBB GND Jun 14 15:22:05 where would the 3.3V from the BBB come into play Jun 14 15:23:28 it wouldn't for now, except the breadboard makes it easier to validate connections Jun 14 15:23:57 (between encoder and bbb) Jun 14 15:24:33 no activity Jun 14 15:24:45 so the encoder outputs are now 3.3V ? Jun 14 15:25:24 well still at the part where I have your script running and I am just taking the pru pin to GND Jun 14 15:25:27 via bread board Jun 14 15:25:43 then your connections are broken, or you're using the wrong bbb pins Jun 14 15:25:54 also double-check your pinmux again using show-pins, just to be sure Jun 14 15:26:18 what value of R31 is my script giving? Jun 14 15:26:28 0x00010004 ? Jun 14 15:26:30 r31 = 0x00010004 Jun 14 15:26:41 ok yeah, then it's measuring both pins high Jun 14 15:26:54 which is mutually exclusive with them being connected to ground, i.e. your connection isn't working Jun 14 15:27:32 so just go to next step Jun 14 15:27:51 what? no? Jun 14 15:28:08 "it's clearly broken" "ok, so I'll just pretend it's not broken and continue?" Jun 14 15:28:36 fix your connections Jun 14 15:36:12 just looking at pin 41 Jun 14 15:36:15 easy to find Jun 14 15:36:17 it does not work Jun 14 15:36:24 i tried with mm Jun 14 15:36:32 and I am not getting 3.3V out Jun 14 15:36:47 getting 0.030V Jun 14 15:37:12 please share output of: sudo show-pins | grep pru Jun 14 15:37:38 "sudo: command not found" :) Jun 14 15:38:20 https://pastebin.com/yX7rUSfF Jun 14 15:39:20 MattB0ne: oh wait how is the other P9.41 signal configured? Jun 14 15:39:28 it's pulldown isn't it Jun 14 15:40:24 add a PIN_INPUT_PULLUP( P9_41b, 7 ) and USES_PIN( P9_91 ) Jun 14 15:40:35 ok Jun 14 15:40:44 it seemed to be working last night Jun 14 15:40:47 thoguh Jun 14 15:41:04 fair, so that means youre 0.03V is a measurement error Jun 14 15:41:11 (or a connection error) Jun 14 15:41:17 but you should still add those Jun 14 15:41:28 since otherwise you have a pullup/pulldown conflict on P9.41 Jun 14 15:44:46 let me take the cape off Jun 14 15:47:53 ok cape off Jun 14 15:48:13 i tested the 3,3V, 5V and the pru pins Jun 14 15:48:20 the supply comes in correct Jun 14 15:48:30 the pru is coming in at 1.57 Jun 14 15:49:11 with pullup enabled on both P9.41a and P9.41b ? without any other connections to it? Jun 14 15:50:12 yes one consistently at 1.57 the other at 3.18 Jun 14 15:50:17 maybe I need a new board Jun 14 15:50:47 show-pins | grep 'P9\.41' is showing "up" for both? Jun 14 15:50:53 sudo show-pins I mean Jun 14 15:51:15 'one consistently at 1.57' which one? Jun 14 15:51:27 41 Jun 14 15:52:18 that only makes sense if there's a pullup/down conflict, which shouldn't be possible if you added the pinmux I mentioned for P9_41b Jun 14 15:52:53 https://pastebin.com/fi5sMcg1 Jun 14 15:53:09 need to do that Jun 14 15:53:22 i stopped since it was working last night Jun 14 15:53:29 but let me do it Jun 14 15:53:31 ... Jun 14 15:53:35 ok I'm done with you for today Jun 14 15:53:43 I asked whether this was with pullups enabled on both pins Jun 14 15:53:49 I gave you instructions Jun 14 15:53:52 you said "yes" Jun 14 15:53:56 but plain didn't do it Jun 14 15:54:00 P30 and P41 Jun 14 15:54:03 both Jun 14 15:54:08 and didn't even bother to say you didn't do it Jun 14 15:54:17 I said "with pullup enabled on both P9.41a and P9.41b ?" Jun 14 15:54:22 that's both pins Jun 14 15:54:33 anyway, I'm done, go solve your problems on your own Jun 14 15:54:50 well thanks anyway Jun 14 15:54:57 i will keep working on it Jun 14 15:55:42 you did say fair Jun 14 15:55:47 but anyways Jun 14 15:55:52 cease speaking Jun 14 15:55:53 thank you for your assitance Jun 14 15:56:04 i can chat Jun 14 15:56:09 you are banning from chat Jun 14 15:56:10 really Jun 14 15:56:33 jesus Jun 14 15:58:33 come back tomorrow or something, but right now I'm _very_ annoyed and I strongly advise against complaining Jun 14 15:58:54 i will work on it and I understand your annoyed Jun 14 15:59:51 wow, you managed to make zmatt lose patience Jun 14 17:07:40 Hi, I've got at problem setting the GPIOs on P8, but not on P9 on my BBBW. I'm using gpioset like this; gpioset --mode=time --sec=2 CHIP OFFSET=VALUE. I'm using a multimeter on the GPIO port to see the inital value, se my input will be 1 if initial is 0 and vice versa. CHIP = 0 for gpio [0-31], 1 for gpio [32-63] ... offset = gpio number - chip gpio starting number, such that fx gpio 60 offset = 60-32 = 28. So far all digital gpios tested on P9 is Jun 14 17:07:40 working but none on P8. Does anyone know if I'm doing something wrong, or if something is not setup correctly ? Jun 14 17:09:45 I am done for the day but I just wanted to report that when I remove the LCD cape everything works as intended. I am just going to look for another less problematic cape. This was without adding the additional pull on with P9.91 Jun 14 17:10:12 probably tried to use pins that aren't configured as gpios? with the sysfs gpio interface that's not possible since those pins don't their gpios exported, but I don't think gpiod (which I assume gpioset uses? I've never heard of it) lacks such sanity checks Jun 14 17:10:51 mastermind_: you should prevent a pullup/pulldown conflict regardless of whether it seems to be causing problems Jun 14 17:11:04 huh, yea that might be, thanks :) Jun 14 17:11:15 either both a and b need to be pulldown, or both pullup, or one needs to be nopull Jun 14 17:11:28 I have it in now Jun 14 17:12:08 implemented so I see the 3.3V on P9.41 Jun 14 17:12:11 Munken: the P9/P8 sheets of my pins spreadsheet https://goo.gl/Jkcg0w give a nice overview of the P9 and P8 headers and what pins may be in use for Jun 14 17:12:47 oh wow, that's extensive! Jun 14 17:13:07 Munken: and my show-pins utility gives a detailed overview of your current pin configuration (as well as gpio state, at least for exported gpios): https://github.com/mvduin/bbb-pin-utils/#show-pins Jun 14 17:13:19 I've just started with the ones on https://beagleboard.org/Support/bone101 Jun 14 17:13:45 there are lots of overviews of the BBB expansion headers out there.. some better than others Jun 14 17:13:55 haven't seen any with as much information as mine though :) Jun 14 17:14:11 no neither have I, that is really great :) Jun 14 17:14:36 I'm just testing out a library I'm making in rust, funky stuff started happening once using P9 :o Jun 14 17:14:53 but yes it might just be that P9 have some exported by default Jun 14 17:16:25 show-pins will show you which pins are configured to gpio mode Jun 14 17:17:00 I don't think being exported is relevant for the gpiod interface, it (rudely) doesn't care, which is why you didn't get an error Jun 14 17:17:30 oh gpioset is also only temporary? well that's annoying Jun 14 17:18:14 yes it is for the new interface Jun 14 17:18:18 cdev Jun 14 17:18:50 you create a fd for working with it, once removed it returns to initial state Jun 14 17:18:50 yeah, which I don't regard as an even remotely suitable replacement for the sysfs gpio interface Jun 14 17:18:54 it's worse in many ways Jun 14 17:19:27 I can't speak on that, but I thought that if that is the next thing, I might as well just use it :) Jun 14 17:20:03 I doubt the sysfs interface is going anywhere Jun 14 17:20:22 but yeah, I had some discussion about this recently, if you're interested in knowing why I think gpiod sucks: https://liktaanjeneus.nl/gpio-discussion.html#gpiod Jun 14 17:21:55 basically gpiod combines the performance of the sysfs interface with the safety and abstraction of raw writes to the gpio controller ;) Jun 14 17:23:28 (it's not quite _that_ bad, I'm being slightly hyperbolic, but only slightly) Jun 14 17:25:14 hehe, yea well all I know is that usually I would just know what gpio I needed, and now I have to make stupid funktions calculating on which chip i need to open a gpio, and then do stuff... But well this is the future :D Jun 14 17:25:49 no, you're _choosing_ to use that awful mess Jun 14 17:26:39 true, but deprecation in 4.8 makes me wonder if developing for sysfs makes sense ? Jun 14 17:27:25 I predict it's not going anywhere, it's a stable kernel-userspace interface and the kernel policy is to never break userspace Jun 14 17:27:47 I'll definitely be yelling if they try, since gpiod is simply an unusuable replacement for us Jun 14 17:29:14 ok, well that's an eye-opener.. As I remember the linux kernel mindset is 'as long as one person is using functionality X it will be supported'. So with that in mind, it might not be removed anytime soon :D Jun 14 17:31:58 like I explain in aforelinked discussion, using sysfs + gpio-of-helper gives per-gpio access control, with DT deciding which gpios are exported and whether they are input, output, or bidirectional. this allows unprivileged userspace applications to be given access to gpios without any risk to hardware Jun 14 17:32:36 giving userspace access to a gpio character device is basically a new MAY_DESTROY_HARDWARE posix capability ;-P this is not acceptable Jun 14 17:58:36 what is acceptable depends a lot on what level of control you have over the software Jun 14 18:02:02 I mean, in the end that's something people will have to weight for themselves. we have full control over the software, but that doesn't mean we're going to run everything as root and hope for the best. limiting access both protects against accidents and limits the impact of security vunlerabilities Jun 14 18:04:19 and one of the most important jobs of the kernel is to provide the access control mechanisms needed to be able to limit access, and gpiod offers basically none (just access to the entire gpio controller) Jun 14 18:04:38 HI alla Jun 14 18:04:49 i am new to beagleboard xm Jun 14 18:05:20 can anyone help me with the procedure to install Ubuntu on beagleboard XM? Jun 14 18:05:21 wow that's a pretty old board... are they still manufactured? Jun 14 18:06:01 i borrowed it from my friend, he also never used it Jun 14 18:06:06 either way, a few no doubt still exist Jun 14 18:06:14 in fact, I have some Jun 14 18:06:27 kiran: anyway, there are no officially supported ubuntu images, the recommended images are debian Jun 14 18:08:33 I want to install KODI on xm, my understanding is we need to install OS first and then istall KODI, for this debian is also fine Jun 14 18:08:45 please let me know if i am wrong Jun 14 18:09:06 I don't know anything about kodi, but yeah generally you'll want an OS before you install software :P Jun 14 18:09:17 uh, that's going to suck Jun 14 18:09:35 :) Jun 14 18:09:36 what is? Jun 14 18:09:42 kodi on a beagle xm Jun 14 18:10:00 yes Jun 14 18:10:08 Search Results Jun 14 18:10:43 is it not possible? Jun 14 18:11:33 I found 10 year old videos of people running XBMC on the bbxM, seems to run fine? Jun 14 18:11:58 yes Jun 14 18:12:31 i am looking for debian with GUI Jun 14 18:12:58 fine for the time perhaps Jun 14 18:13:05 can you help share the proper link for OS with GUI for beagle XM Jun 14 18:13:17 I'd assume the resource requirements of kodi have gone up just like for everything else Jun 14 18:14:17 sorry, I zero experience with the old beagleboards Jun 14 18:14:20 *I have Jun 14 18:14:29 mru: yeah, fair Jun 14 18:15:29 and I'm guessing that getting hardware-accelerated video decoding working is also not going to be trivial Jun 14 18:15:43 it's not going to work, period Jun 14 18:15:54 no problem, Thanks for reply. Jun 14 18:16:02 mru: that doesn't sonud very optimistic Jun 14 18:16:06 it never worked with any public software Jun 14 18:16:51 and the video accelerator wasn't very accelerated anyway Jun 15 02:58:13 Hi, is anyone able to help direct resolving a error when building BBB uboot files? Jun 15 02:58:39 I'm following https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black Jun 15 02:58:58 Have applied the uboot patches without error. Jun 15 02:59:16 Then I hit this build error: Jun 15 02:59:30 https://github.com/eewiki/u-boot-patches/issues/12 **** ENDING LOGGING AT Mon Jun 15 02:59:57 2020