**** BEGIN LOGGING AT Thu Mar 18 02:59:56 2021 Mar 18 05:25:57 i am used to micropython on esp32. and I think my pocketbeagle is better than any of the pi variants I have tried. but much worse and slow and the software is rubbish. wow it is bad Mar 18 05:27:13 hello anyone here Mar 18 05:27:21 hi dude Mar 18 05:27:49 hello yourself Mar 18 05:31:16 i need a help regards with beaglebone black Mar 18 05:34:11 sorry I only got a pocketbeagle and I loath the beaglebone programming environment Mar 18 05:39:23 is there any solution for dht11 interfacing with beaglebone black board. I have tried many solutions but i couldn't sort out this. Mar 18 05:44:21 yeah, its not you. thats 3 lines of micropython code. I just spent 2 days trying neopixel. again 3 lines of micropython. but really a ds18b20 is way more accurate. I have used many types of temperature sensor and always come back to these Mar 18 08:19:49 that was weird Mar 18 08:41:35 like, did wizard3141 just drop in to complain that programming linux-based SBCs is not like baremetal programming on microcontrollers? Mar 18 11:11:32 python hardly qualifies as "bare metal" Mar 18 11:16:40 micropython does Mar 18 11:27:37 lol Mar 18 11:47:47 my pocketbeagle, cloud9, most examples are for a different board and dont compile. basic python gpio had to be installed, crappy work. anyway anyone used node red on this toy? Mar 18 11:49:45 you know, regardless of whether our complaints are justified (I'm perfectly willing to believe they are), you should maybe consider whether opening like that is really the best way to ask people for help Mar 18 11:49:50 *your complaints Mar 18 11:50:52 i did. whatever Mar 18 11:51:02 the "python gpio had to be installed" one isn't true though, that definitely comes preinstalled Mar 18 11:51:27 not on mine Mar 18 11:51:48 alternative ide? Mar 18 11:52:09 whatever you prefer, I use vim like I would on any other linux system Mar 18 11:52:27 cool Mar 18 11:53:02 tried node red? Mar 18 11:53:29 nope, I vaguely know what it is and that it comes preinstalled on the IoT images, but that's about it Mar 18 11:54:34 many things I have going on the usb hub-sound wifi and ethernet. and the speed is good Mar 18 11:56:00 that actually surprises me Mar 18 11:56:05 but good to hear Mar 18 11:56:08 $4 Mar 18 11:56:38 ? Mar 18 11:56:50 the cost of the hub Mar 18 17:24:00 Good Day,  I was hoping someone might be willing to help me with a PRU question on the BB AI?  I have a system that uses PRU2 via py-uio and it has been working fine but I'm now getting an error during PRU initialization that "/dev/uio/pruss2/module does not exist"; looking in the /dev/uio directory, pruss1 exists but pruss2 doesn't.   This Mar 18 17:24:01 worked previously and I don't think I've made any changes, the uio-pruss rules seems to be correctly configured and the device tree includes dra7-uio-pruss.dtsi.  Any suggestion on why pruss2 may have disappeared? Mar 18 17:24:20 uhhh Mar 18 17:25:38 Hi Tim :) Mar 18 17:26:33 Isn't /dev/uio/pruss2 made by a rule file? Not sure... Mar 18 17:26:52 yes, an udev rule supplied with py-uio Mar 18 17:27:09 Interestingly, I just rebooted again (about the 5th time), and pruss2 now exists. Mar 18 17:27:31 huh... some sort of timing issue? very strange Mar 18 17:27:49 I don't get how though Mar 18 17:28:13 the udev rule doesn't depend on... well, anything really Mar 18 17:28:41 Any insight onto when in the boot process those get run? Mar 18 17:30:27 just to be clear, it's not just that your software (presumably started at boot) is unable to find /dev/uio/pruss2, it also doesn't exist if you log in and manually check? Mar 18 17:30:47 (i.e. it's not just a matter of your software being started too early) Mar 18 17:30:48 ? Mar 18 17:31:29 also, then this happens, have you checked journal for errors/warnings that may be related, especially from udev ? Mar 18 17:31:39 Where does the /dev/uio/pruss2 symbolic link point to? Mar 18 17:32:04 Thats what I'm wondering too.  My software is run as as service at boot. Mar 18 17:32:23 hunter2018[m]: it's a directory containing symlinks actually Mar 18 17:32:28 pointing to /dev/uio* devices Mar 18 17:32:48 Guest49821: so you didn't check afterwards if /dev/uio/pruss2/module existed? Mar 18 17:33:35 I've tried running my software later also with no luck. but maybe after my software had already attempeted to start. Mar 18 17:34:27 ... but you've not checked manually whether it existed? e.g. just with ls /dev/uio/pruss2/ Mar 18 17:37:07 ? Mar 18 17:38:40 I did check to see of the /dev/uio it seemed to be there. Mar 18 17:39:42 okay so your problem is just your software being started too early? it probably needs suitable dependencies / ordering constraints in its service file to ensure everything it needs is available before it is started Mar 18 17:42:02 or it would need to explicitly wait itself for the device to show up Mar 18 17:42:19 I think I'm going add some delay to my startup and see if that fixes the issue.  In general the system had been pretty stable so hopefully I can get it to reproduce Mar 18 17:42:37 that's not a good solution though, you'd still be counting on luck Mar 18 17:43:10 I agree.  I really like the idea of watching for the device to be available. Mar 18 17:43:41 adding Wants=systemd-udev-settle.service and After=systemd-udev-settle.service to the [Unit] section of your service file is an easy way to guarantee udev is "done", although it's deprecated and may significantly increase boot time Mar 18 17:44:03 but you can also be more precise, hold on let me check Mar 18 17:47:38 That's awesome. I'm currently using Want= Network.  But if udev-settle is an option, that makes more sense. Mar 18 17:48:30 well those two things don't have anything to do with each other Mar 18 17:48:43 and like I said udev-settle is not recommended Mar 18 17:49:46 if you make this change to the udev rule the uio device will show up as device unit: https://pastebin.com/QK3FUAsv Mar 18 17:51:01 I'm doing a quick test for the suitable unit dependency Mar 18 17:53:12 also what do you mean by "Want= Network" ? Mar 18 17:54:56 be more precise in what you say, details matter Mar 18 17:55:46 Sorry, I was mistaken.  I went back and looked at what I'm actually using to start my software,  the line I misquoted is actually: After=network.target systemd-udev-settle.service Mar 18 17:56:32 you already had After=systemd-udev-settle.service, or do you mean you just added it? Mar 18 17:56:44 That was already there. Mar 18 17:57:19 did you also have Wants=systemd-udev-settle.service ? otherwise After=systemd-udev-settle.service won't really do anything (unless some other unit happens to pull it in) Mar 18 17:58:13 No I don't. Mar 18 17:58:44 anyway, the alternative to using systemd-udev-settle.service is making the udev rule changed I showed earlier (https://pastebin.com/QK3FUAsv) and then adding Requires=dev-uio-pruss1-module.device dev-uio-pruss2-module.device and After=dev-uio-pruss1-module.device dev-uio-pruss2-module.device Mar 18 17:59:24 zmatt.  Thanks so much for your help.  I'm going to implement this and do some testing Mar 18 18:00:19 This probably the first time I've seen this error in 100+ startups so I'm hoping I'll be able to do enough testing to see if this fixes the problem completely Mar 18 18:00:31 I appreciate your time and effort! Mar 18 18:00:53 of course if you have lots of other things you need to wait for, maybe using systemd-udev-settle.service would be more convenient, you'll have to see if using it (with Wants=systemd-udev-settle.service) makes your software start unacceptably late or not Mar 18 18:01:24 yeah, there are probably ways to deliberately slow udev down Mar 18 18:01:42 I can accept a long delay (30 seconds) in starting my software, if it starts reliably Mar 18 18:02:33 then maybe just first try Wants=systemd-udev-settle.service in addition to After=systemd-udev-settle.service to see if that works okay for you Mar 18 18:03:03 I will. Mar 18 18:03:09 btw, After=network.target might also not do what you're hoping for, the main effect of that ordering dependency is to ensure that at shutdown your service is stopped before network goes down Mar 18 18:03:35 (useful e.g. if you want to inform a server you're going away) Mar 18 18:04:10 Really,  I thought that it ensured the network configuration was completed prior to starting the software. Mar 18 18:04:21 not at all no Mar 18 18:05:14 Much of the service infrastructure is realatively new to me and I've been living off of "it works , leave it alone", but from this conversation it sounds like its time to read into the details a bit more. Mar 18 18:05:15 in general it's recommended to not try to rely on such a thing, since networking might not come up right away at boot, e.g. if the network cable isn't plugged in or the ethernet switch is off (or itself still startin up) Mar 18 18:05:34 you can read about these special units in "man systemd.special" Mar 18 18:05:40 That all makes sense. Mar 18 18:06:37 Thanks for the reference. Mar 18 18:06:45 you can do Wants=network-online.target After=network-online.target but what exactly that does (if anything) will depend on the network manager being used Mar 18 18:07:16 and it looks like connman does nothing with it Mar 18 18:08:18 ah never mind, it does work but you'd also need to "systemctl enable connman-wait-online.service" Mar 18 18:08:54 assuming you're using connman Mar 18 18:12:24 Yeah, I don't need it to be online, just to have some connection for the Python flask app to bind to, and at startup, the "lo" is all it really needs to find Mar 18 18:12:41 why are you binding to a network interface? Mar 18 18:12:46 normally you just bind to "any address" Mar 18 18:13:46 That is what I'm doing, I was about to add," and honestly, I'd bet that it would start fine without a network connection at all since I'm binding to all addresses anyway" Mar 18 18:14:17 yep, normally applications don't need to care about such things Mar 18 18:15:04 Which makes sense, just a thought I got stuck in my head and never questioned... Mar 18 18:16:42 of course normally your flask app shouldn't be using the integrated webserver, that's really only meant for development :P normally you'd run it in an application server (wsgi) Mar 18 18:17:30 (but there might be situations where you can get away with using the built-in server anyway ;) Mar 18 18:18:00 Agreed.  The problem is that Werkzeug is just too capable of a development server, there hasn't been anything to push me to "do it right". Mar 18 18:18:27 And since these are all run as standalone or internal applications, I'm not even overly concerned about security Mar 18 18:18:29 I'm going to guess your beaglebone isn't internet-facing and serving large hordes of clients anyway Mar 18 18:18:34 yeah, that Mar 18 18:18:45 which is the one thing that would push me to a WSGI server. Mar 18 18:19:04 Exactly right, most of the time, there is exactly one user connected, two on a busy day Mar 18 18:20:52 I'm implemented your suggested changes and the started the software without issue. Mar 18 18:20:58 * I've Mar 18 19:31:58 @zma Mar 18 19:32:17 @zmatt Thanks for the help today! Mar 18 21:56:05 Well, the maker faire this year is being held outdoors. no wifi! Mar 18 21:56:11 I should have been making arducopter stuff for bots...they need to notify people over a month beforehand. Mar 18 21:56:54 Blah. Mar 18 21:57:39 I can set up some stuff but not everything. Man, it is going to be difficult on a months notice. Mar 18 21:58:32 now, back to the basics of life, i.e. life before 2.4 Ghz. Mar 18 21:58:32 Ha. **** ENDING LOGGING AT Fri Mar 19 00:01:55 2021 **** BEGIN LOGGING AT Sun Mar 21 04:22:16 2021 Mar 21 10:36:41 * rob_w hails zmatt Mar 21 12:28:16 if I can can program in python is there any reason I have to bother with pru programming in c? Mar 21 12:29:57 no and yes! Mar 21 12:30:04 But...sure. Mar 21 12:30:23 PRU stuff can either be done w/ c or assembly from what I have seen... Mar 21 12:30:48 And then there is a library from one of such said persons that handles uio. Mar 21 12:30:55 what can i do with this pru business I can not do in python Mar 21 12:31:16 Handle a microcontroller code that you can load onto the PRU core. Mar 21 12:31:35 Either from elf or handle it via ARM to PRU... Mar 21 12:31:57 you lost me Mar 21 12:32:02 WIZARD3141: Are you using a library? Mar 21 12:32:24 For PRU or are you hardcoding via assembly? Mar 21 12:32:47 i am only doing python so far and using adafruit libraries Mar 21 12:33:12 Me too. I do not think you can handle PRU w/ the adafruit libraries. Mar 21 12:33:15 done lots of years of arduino Mar 21 12:33:30 Oh. I have no ideas about arduino. 5v? Mar 21 12:33:46 python is fun and c is awful Mar 21 12:33:49 I think they have gotten better w/ their chips recently. Mar 21 12:33:50 Ha. Mar 21 12:33:52 Yep. Mar 21 12:34:16 But...the BBB and related boards handles 3.3v logic. Mar 21 12:34:21 my favourite for the last year is micropython on esp32 Mar 21 12:34:51 I have level converters when needed Mar 21 12:34:56 So, just for an idea, never and I mean it, never put your arduino sensors/actuators on the... Mar 21 12:34:58 Okay. Mar 21 12:35:11 Just checkin'. Mar 21 12:35:40 Currently, I am having trouble w/ the Adafruit_BBIO lib. w/ the BBBlue. Mar 21 12:35:55 like for neopixel logic. and my pocketbeagle seems incapable of using neopixels Mar 21 12:36:14 I am not sure what neopixels are but it sounds like LEDs. Mar 21 12:36:24 I know! Mar 21 12:36:52 yes 4 wire +- data in and out 25000 colours Mar 21 12:36:58 There was a fellow. This fellow put together a PRU cookbook. I think his name on github.com is...dang it. Mar 21 12:37:03 Let me look it up real quickly. Mar 21 12:37:33 https://markayoder.github.io/PRUCookbook/ and I think it covers neopixels. Mar 21 12:37:33 yes i tried that for a week and no luck Mar 21 12:37:37 Oh. Mar 21 12:37:40 Dang! Mar 21 12:37:55 I hate when things do not work out perfectly. There is most likely a reason. Mar 21 12:38:04 every method repeatedly Mar 21 12:38:36 Ha. I do that at times. There are some .pdf files for CLPRU and PASM. Mar 21 12:38:53 You can search TI.com for their ideas or scour the interwebs too. Mar 21 12:39:08 The PRU stuff takes a specific library tool for compilation. Mar 21 12:39:45 i am going for a orange pi zero2  plus. all things work easily with python on that and its the same price as pocketbeagle, with bso much more hardware its stupid. also smaller than a pocketbeagle plus usb hub Mar 21 12:40:11 Oh. Mar 21 12:40:24 I am sorry. The bbb.io .org persons have other boards too. Mar 21 12:40:49 Some are easier to handle and are already smashed together and cooked. Mar 21 12:40:50 ! Mar 21 12:41:03 The boards! Mar 21 12:41:15 i think the pocketbeagle is too young. shelf for as while and see Mar 21 12:41:33 Oh. Did you look at the files on github.com for it? Mar 21 12:41:46 They have some good ideas and Molloy has a book on it! Mar 21 12:41:59 I think they put it out four years ago. Mar 21 12:42:09 Or longer... Mar 21 12:42:14 yep. downloaded every image file I could and they all lack decent python support Mar 21 12:42:36 sudo apt install python3-dev python3 and so on? Mar 21 12:42:46 love the hardware though Mar 21 12:42:46 What do you mean? Mar 21 12:43:07 What do you mean about lacking python support? Mar 21 12:43:43 no python neopixel drivers and bugger all device specific drivers. everybody else has them on their boards Mar 21 12:44:37 They have libs. out there...oh. I see. Yea. Not everything is so straight forward. I understand this so far. Sometimes people chip in when they have time for specific ideas or it just takes time. Mar 21 12:44:57 Drivers are hard to make at times. I do not know anything about it really. Mar 21 12:45:21 I just use what I learn and producing drivers is something I have not grown accustomed to for now. Mar 21 12:45:33 So, I am trying... Mar 21 12:45:56 micropython Mar 21 12:45:59 import  neopixel Mar 21 12:45:59 pixelstemperature = neopixel.NeoPixel(machine.Pin(0), 14) Mar 21 12:46:59 I am trying to make the drivers work. Like for instance, there is some correlation b/t labeling the hardware in say a .dts file, making the source available for the driver, and then applying the effort... Mar 21 12:47:36 I have not fully learned how yet. I am slow in this dept. b/c of lack of support, money, and time. The three evils in life! Mar 21 12:48:25 Anyway...I would hope you would stay. There is a lot to learn outside of just producing user libraries and using them. Mar 21 12:48:50 Linux has many different ideas associated w/ it. Mar 21 12:49:35 I heard one fellow say that micropython, which is Adafruit's clone right, may work w/ the ADC onboard the BBB. Mar 21 12:49:38 i have got my usb port on pocketbeagle working with sound, bluetooth and wifi. that was fun Mar 21 12:49:47 Nice! Mar 21 12:50:00 BELA...look up BELA. That is some neat library! Mar 21 12:50:30 They have an easy to use graphical interface and tons of code to goof w/. If you like sounds, BELA is a good sounds thing. Mar 21 12:50:34 ok. but capes cost too much. a usb soundcard is $3 au Mar 21 12:51:03 I do not know everything about their Cape but I have performed some ideas w/ it and its feedback was astounding. Mar 21 12:51:06 Oh. Mar 21 12:51:16 Yea. Time and development, I guess. Mar 21 12:51:17 will play with bela. been fun chatting ttfn Mar 21 12:51:23 Later! Mar 21 12:52:05 I am going to complain one day! Why does not one, single person stay when we are chattin' like original heros? Mar 21 12:52:15 Blah! Mar 21 16:24:04 rob_w: hmm? Mar 22 01:59:47 Has anyone looked up gcc compiler optimizations from their online docs? Mar 22 02:00:42 I just decided to look it up. So, it seems, at page 3.11, the dang optimze-options sections span forever. Mar 22 02:00:56 There is actually no end. Mar 22 02:02:07 Do you know who made that happen? Mar 22 02:04:16 Okay. it ends. Mar 22 02:04:19 Sorry. Mar 22 02:15:17 Hello Mar 22 02:16:47 Hello! Mar 22 02:16:55 Did you ever get the HDMI? Mar 22 02:16:59 Micro! Mar 22 02:18:35 So a few weeks I was advise to research a bit more into the USB connections from the pocketbeagle, that led me to study the osd335x Mar 22 02:19:30 pocketbeagle power and usb pins: https://pastebin.com/nJCbVsaA Mar 22 02:19:30 because my project is to add a usb hub to pocketbeagle, so I was researching how much voltage and current the pocketbeagle could provide Mar 22 02:20:14 that would been pretty helpful before hahaha, but it was good to research Mar 22 02:20:56 that I am certain that pocketbeagle can provid up to 500mA at 5V according to this :https://media.digikey.com/pdf/Data%20Sheets/Octavo%20PDFs/OSD335x-RefDesignTutorial.pdf Mar 22 02:20:59 if you're adding a hub to the pocketbeagle, it would probably be best to not draw the power you need from the pocketbeagle itself, but instead have a beefy 5V supply and use that to power the pocketbeagle and the hub Mar 22 02:21:24 even if the pocketbeagle can provide? Mar 22 02:21:55 I guess it depends on the application Mar 22 02:22:08 according from the pdf I sent, page 100 Mar 22 02:22:09 if you know that you only want to attach some low-power usb devices then sure Mar 22 02:23:20 if the pocketbeagle is powered via usb, the max total current on 5V is 1.8A, and this is for all current drawn by the pocketbeagle itself and whatever you want to draw (from P1.24/P2.13) combined Mar 22 02:24:02 and of course this requires that the pocketbeagle is plugged into something that's okay with supplying that much current Mar 22 02:24:20 Is there a source for that total current you mentioned? Mar 22 02:24:29 tps65217 datasheet Mar 22 02:25:12 also, that 1.8A is only after the pmic has been configured as such by u-boot, initially it's 500 mA if I remember correctly Mar 22 02:28:35 in case it's of interest, I have two diagrams showing how to correctly wire up a host port on the pocketbeagle while also providing power to the pocketbeagle: https://photos.app.goo.gl/e1663vMMDnEmGZaR6 (the diagram on the left is the *proper* way and can support whatever amount of current your 5V supply and usb power switch can handle, while the solution on the right is sort of minimal "you may be ... Mar 22 02:28:41 ...able to get away with this" and draws its usb bus power from the pocketbeagle) Mar 22 02:29:42 in case of the pocketbeagle being powered from usb, you simply wouldn't use P1.01 .. on the left diagram that means you's draw the usb power from P1.24 instead of the external supply (or *maybe* P1.07) Mar 22 02:30:40 in both diagrams I've omitted the filtering and esd protection that should be on any external downstream port, but in case of a hub you'd have those on the downstream ports of the hub of course rather than on the connection to the pocketbeagle Mar 22 02:32:58 I am thinking of using this one for the hub Mar 22 02:32:59 https://www.cypress.com/file/122726/download Mar 22 02:33:07 it seems like it already has the protections Mar 22 02:35:57 and its good for my project because the whole system is detailed there in pdf Mar 22 02:37:12 hmm, it doesn't say anything about internal protection/filtering, though their example schematic doesn't seem to have any on the downstream ports, other than power supply filtering for each downstream port Mar 22 02:37:32 and the example schematic has a common mode choke on the upstream port Mar 22 02:38:10 huh, maybe I need to continue searching Mar 22 02:39:14 "EMI and ESD need to be considered on a case-by-case basis relative to the product enclosure, deployed environment, Mar 22 02:39:18 and regulatory statutes. This application note does not give specific recommendations regarding EMI." Mar 22 02:39:21 useful. Mar 22 02:39:45 so it doesn't have the protections , but gives some direction Mar 22 02:39:48 translation: "figure out yourself" Mar 22 02:39:52 oh Mar 22 02:40:25 doesn't change much, already doing that haah Mar 22 02:40:48 do you have any advise on choosing the hub chip? Mar 22 02:40:59 of course it also matters a lot whether it's just a fun project versus making an actual product Mar 22 02:42:06 nope, none whatsoever. this one gives a perfectly fine first impression, but I don't have any actual experience with usb hub chips Mar 22 02:42:34 red flags would be a vague datasheet and/or lack of supporting documentation, but the state of documentation on this one seems okay Mar 22 02:43:35 Well, I am looking to make this project be above just functional, to have all the protections, to work in line with the pocketbeagle can give Mar 22 02:44:05 thats why I was searching a lot of weeks for exactly how much the pocketbeagle can give in voltage and current in the usb host without damaging itself Mar 22 02:44:41 but this is all very new to me so I ended up taking too much time searching every detaio Mar 22 02:44:43 detail Mar 22 02:44:47 if you're drawing too much current from its 5V output (P1.24/P2.13) it will simply power off Mar 22 02:46:03 ideally you'd have external protection to prevent that form happening, e.g. an usb power switch with some reasonable current limit Mar 22 02:46:32 isn't the usb power output pin 7? Mar 22 02:46:40 no Mar 22 02:47:01 see https://pastebin.com/nJCbVsaA Mar 22 02:47:38 I would not recommend using P1.07 since it's neither switched nor protected, it connects directly to usb0's vbus Mar 22 02:47:50 okay Mar 22 02:49:19 Probably the hub chip is going to use all the connections from the usb interface plus obviously the 5V and gnd pins Mar 22 02:49:50 and before the the chip I am going to put a power switch and esd protection Mar 22 02:50:17 putting esd protection between the hub and the pocketbeagle is probably not useful if it's a fixed connection Mar 22 02:50:52 so it would be better between the chip and the downstream ports Mar 22 02:53:15 so, here's the thing: normally "external" interfaces will have esd protection to protect them from damage when people insert cables/devices while they are electrostatically charged... but you're already handling naked unprotected electronics with no enclosure or rugged esd protection... you're already liable to damage or destroy things if you're electrostatically charged Mar 22 02:54:19 the P1/P2 headers of the pocketbeagle connect directly to the pins of the am335x with no protection whatsoever, those are the biggest concern here w.r.t esd Mar 22 02:54:32 whenever you touch them **** ENDING LOGGING AT Mon Mar 22 02:59:56 2021