**** BEGIN LOGGING AT Thu Sep 08 02:59:59 2016 Sep 08 04:56:50 hi Sep 08 05:18:07 how to make serial communication with beagle to pic microcontroller Sep 08 07:08:37 Hi there Sep 08 07:09:13 I am a newcomer in open source community Sep 08 07:09:36 I have good experience in electronics Sep 08 07:09:50 i have worked on arduino platform Sep 08 07:10:07 Now I would like to work with beaglebone Sep 08 07:10:16 I'd say go for it! Sep 08 07:10:19 ;) Sep 08 07:10:38 if anyone tries to stop you, tell them you have my permission Sep 08 07:10:52 Can anyone explain me how I can contribute Sep 08 07:12:11 ehm, I'm not sure how to answer such a vague question Sep 08 07:12:25 What should I learn to be a part of this community? Sep 08 07:13:10 I read something about cross compilation and PRU on http://elinux.org/BeagleBoard/GSoC/Ideas Sep 08 07:13:40 I am not getting how should I proceed Sep 08 07:15:41 I have some programming experience in python and C Sep 08 07:37:40 Any help would be appreciated Sep 08 09:15:44 I am currenctly using am335x-boneblack-emmc-overlay.dtb Sep 08 09:16:17 and would like to rebuild the DT so i dont have to mess with overlays Sep 08 09:21:25 Let's say I want to enable spi, I would just have to change status to okay in am33xx.dtsi recompile it and make /boot/uEnv.txt to us my dtb file? Sep 08 09:23:06 I can also remove i2c or uart from the dtsi if I am not using it? Sep 08 09:36:33 laurittr: I don't really know, but do tell me if you figure it out Sep 08 09:38:29 you can e.g. make a new .dts based on one of the existing variants Sep 08 09:47:23 if I want to use UART1 RTS/CTS pins, which are taken by the capemgr/i2c2 setting, how do I do that in the least intrusive way? Sep 08 09:47:48 ( uart1_rtsn/ctsn conflict with i2c2_scl/i2c2_sda ) Sep 08 09:49:13 Spidler: google for devicetree and have fun Sep 08 09:49:33 Defiant: Yea, Already in that little special mess ;) Sep 08 09:50:02 Defiant: Trying to figure out if delete-node/i2c2 is the way to go, or simply delete-node on the simple parts... or if I should build a new core dts without the capemgr completely.... Sep 08 09:50:35 setting status = "disabled"; on the node might suffice Sep 08 09:50:55 That would prevent it from taking the pins? Sep 08 09:51:26 I think so, but Try It And See :) Sep 08 09:51:51 Well, that gives me something to work with, thanks :-) Sep 08 09:51:55 I personally have a dts that never enables capemgr to begin with Sep 08 09:52:01 Mmm Sep 08 09:52:06 I'm probably going there in the long run Sep 08 09:52:26 But first I want to get this port to work with RTS/CTS mode rather than just toggling gpio pins to change direction. Sep 08 10:20:10 hi Sep 08 10:27:18 hi Sep 08 11:24:34 zmatt: So, simply disabling the i2c2 will just crash the machine if the capemgr is still there. ;-) Sep 08 11:53:31 oh yeah you do need to get rid of that also, I just suggested using status = "disabled" on the i2c node Sep 08 11:54:13 same might work on capemgr but since it doesn't represent actual hw and nothing should be referring to it I'd feel more comfortable using /delete-node/ on that one Sep 08 12:18:03 zmatt: Makes me curious, I wonder what happens if you use the capemanager to load a dts that disables the capemanager... Sep 08 12:18:19 "one, two, three, implosion" Sep 08 12:18:54 lol Sep 08 12:19:05 maybe consider using configfs instead to load that overlay :P Sep 08 12:19:43 though in general overlays that disable stuff have a noticably higher probability of causing a kernel panic than ones that enable functionality Sep 08 12:19:51 Yeah Sep 08 12:19:59 I'd guess it's not quite very well tested. or approved Sep 08 12:20:11 I think I'll go your direction and just make a new base dtb for this Sep 08 12:20:15 :-( Sep 08 12:20:23 So much fucking _hassle_ to get a single serial port. Sep 08 12:20:25 not all of the kernel was originally designed to handle runtime changes Sep 08 12:20:43 It's not really as if you expect hardware to disappear under your feet Sep 08 12:21:25 well, to be honest I haven't used overlays in ages... I just use customize the main dts Sep 08 12:21:43 wow sentence fail Sep 08 12:21:43 Mmm Sep 08 12:22:15 Is the correct way to do that to simply maintain that in the kernel tree, or just copy that + infra and keep in a separate repo? Sep 08 12:22:37 aka. Are the changes forward portable with kernel changes, or not... Sep 08 12:23:19 in theory new kernels are supposed to not break older device trees Sep 08 12:23:50 it's a nice theory Sep 08 12:23:54 Mmmm Sep 08 12:24:29 so, disabling the i2c2 sort of breaks things. Sep 08 12:24:48 And I guess that if I just reprogram the pins that are in conflict, then the i2c2 driver will fuck with my pins ;P Sep 08 12:25:02 And I don't think I can have an overlay that claims exclusive on them? Sep 08 12:25:03 kernel won't let two drivers claim the pins Sep 08 12:25:19 Ah Sep 08 12:25:41 but I can promise you things work fine without i2c2 enabled Sep 08 12:25:48 Yeah Sep 08 12:26:08 I'm just not really at a point where I'm comfortable in building & maintaining my own device tree ;) Sep 08 12:26:43 It's how we did it as well. Sure it's a hassle, but in the end it's vastly more repeatable. Sep 08 12:27:26 Ragnorok: Right, any tips on how to organize it? Sep 08 12:29:19 Sadly, no. There are two of us working on it and the other guy did the mods. I can say for building it was simpler (for me at least) to just download the kernel builder, build a kernel one time, then it's easy to get just DTBs build. I'm sure there's better ways, but I doubt there's simpler ones. Sep 08 12:29:28 Bah. Fargin' fingers. Sep 08 12:29:31 I've personally gone deeply custom, with a hurd of dts files using dtsi fragments for common functionality, a makefile that builds them, but then I'm just nuts Sep 08 12:29:53 you definitely don't need to build the kernel Sep 08 12:29:59 zmatt: I appreciate nuts some times. :-) Sep 08 12:30:04 Oh. For that we copied the main DTS and but our changes in it, then pointed there with uEnv. Sep 08 12:30:14 Hmm Sep 08 12:30:25 The in-kernel dts files seems weirdly organised. Sep 08 12:30:42 Or rather. seems to contain a shitton of undocumented dts files with crappy commit messages ;P Sep 08 12:30:52 We don't have but about six or seven mods. I think we also had to copy one dtsi. Sep 08 12:31:07 cimmitmsg: "Add pinmux" # Spid reaction: I HATE YOU SO MUCH! Sep 08 12:31:40 btw for building dts -> dtb, you can grab the CPP and DTC invocations from https://github.com/mvduin/overlay-utils/blob/master/Makefile Sep 08 12:31:43 ... why the fuck do I have 868 sockets in syn wait?! WHAT IS WRONG WITH THIS SYSTEM!? Sep 08 12:31:53 just snip out the bin/dtsi-to-overlay ;-) Sep 08 12:32:01 Sorry, That's more of my daytime proper work Sep 08 12:33:09 The common dtsi. Basically we kept the original structure and did a copy / modify because not much really changed. Sep 08 12:33:27 zmatt: That looks delightfully maintainable Sep 08 12:33:47 although you've got yet another syntax for pinctrl. Sep 08 12:33:59 yes I do, one I happen to like Sep 08 12:34:06 Yeah Sep 08 12:34:24 so I don't actually use overlays, but this stuff is derived from my actual dts repo Sep 08 12:34:39 I'm not blaming you. but after staring at magical 0x36 in some places I just want to stab someone. :) Sep 08 12:34:50 yes, fuck that Sep 08 12:34:51 "What does it mean, what does it meeeeeeean" Sep 08 12:35:01 ANyhow Sep 08 12:35:03 along with naming pins after some function other than the one being used Sep 08 12:35:07 I'm being obnoxiously ranting Sep 08 12:35:18 Which is probably a good sign that I need to eat lunch. Sep 08 12:35:32 and then the beaglebone also naming pins after a fixed function, but a different fixed function then the name used by the TRM Sep 08 12:35:39 Oh yeah Sep 08 12:36:10 And some places using MODE6 | OUTPUT constants, and others just having a random magic constant. Sep 08 12:36:33 And even on that I can't figure out why it's not handling my RS485 properly. Sep 08 12:36:42 How difficult should a two wire bus _be_ really. Sep 08 12:37:20 oh, if you want a driver to work properly, check Documentation/device-tree/bindings/ to see what device tree config it's expecting Sep 08 12:37:21 Anyhow, time to stop being a whiny bitch about this and go eat some food, catch you all later! Sep 08 12:37:34 then ignore that and check the driver source code what it's *actually* expecting Sep 08 12:37:40 haha Sep 08 12:40:58 although I would personally not look forward to digging into the 8250 driver Sep 08 12:41:11 (then again, I dug into drm and survived) Sep 08 12:42:56 even did some kernel coding, which worked reasonably well -> https://pyra-handheld.com/boards/threads/many-little-steps.77802/#post-1388823 Sep 08 13:06:29 Hi Sep 08 13:06:42 is there anyone here? Sep 08 13:06:47 hay alguien acá? Sep 08 13:06:57 there are 245 people in here Sep 08 13:07:02 http://www.catb.org/esr/faqs/smart-questions.html Sep 08 13:08:07 I'm new here Sep 08 13:13:06 I need to know about how to log in to share my project Sep 08 13:29:13 zmatt: Cool :) Sep 08 13:29:42 zmatt: I'm not looking forwards to any kernel hacking. I've only been doing netfilter and some ipv6 hacking in the Linux-kernel. :-( Sep 08 13:31:23 Spidler: you're fighting the rs485 battle? Sep 08 13:31:39 veremit: yes. Sep 08 13:32:06 veremit: I get signal -one- direction at least. But it's not toggling RTS/CTS Sep 08 13:32:23 whats your current method? ah you're fighting the rts game .. I thoguht gpio was the way to go myself .. Sep 08 13:32:48 my understanding was that the logic wasnt there for rts toggling Sep 08 13:33:03 not for accurate timing anyhow (lets say ''roughly'' accurate timikng!) Sep 08 13:33:46 9600 isn't "accurate" Sep 08 13:33:56 We're going long distances. Sep 08 13:34:24 ah you're "slow" lol .. ok I was more bothered about 115200 :D Sep 08 13:34:30 how 'long' is long? Sep 08 13:34:31 And it's not acceptable to modify the code to fuck around with a GPIO pin. And so far the 8250_omap driver doesn't _seem_ to take gpio pins... Sep 08 13:34:36 A couple of hundred meters Sep 08 13:34:43 oo nice Sep 08 13:34:44 Long enough that lightning strikes become an issue Sep 08 13:34:48 oh yes Sep 08 13:34:56 esd protection no prob. Sep 08 13:34:57 We fried 4 places this summer Sep 08 13:35:13 Due to lightning hitting fan controllers and taking out equipment Sep 08 13:35:14 there are patches (somewhere) for the 8250 to accept gpio Sep 08 13:35:20 One place got fried via the ethernet... Sep 08 13:35:22 Mmmm Sep 08 13:35:29 remote locations? Sep 08 13:35:34 I'm not the _least_ fond of diverging from mainline kernels :P Sep 08 13:35:40 Patches hurt me in the long run Sep 08 13:35:42 Yeah Sep 08 13:35:52 Remote, inaccessible, locked down, pretty standard embedded. Sep 08 13:35:53 naa, I was waiting for some kind of adoption somewhere .. but its a total niche :( Sep 08 13:36:04 Mmmm Sep 08 13:36:10 It's why I want to go the RTS way Sep 08 13:36:11 "standard" embedded is someone's hobby room these days :P but yeah I take your point :D Sep 08 13:36:14 At least it's supported Sep 08 13:36:18 it is?! Sep 08 13:36:24 Well, _should_ be. Sep 08 13:36:26 *stabs* Sep 08 13:36:27 it partially implemented but not tested :D Sep 08 13:36:31 Right Sep 08 13:36:45 you remind me that I really should read up on the lkml. Sep 08 13:36:51 I might have to fall back to omap_Serial too Sep 08 13:36:53 I wish you luck .. I want it .. but I'd end up patching the patches Sep 08 13:36:54 Which I loathe. Sep 08 13:36:56 :-( Sep 08 13:37:04 yeah tell me about it .. you can see why I simply gave up! Sep 08 13:37:21 I do Sep 08 13:37:26 You have my fullest sympathy Sep 08 13:37:33 our applications continue to use FTDI bridges or STM32 micros or PICs Sep 08 13:37:39 *Nod* Sep 08 13:37:48 but its pathetic really that the processor doesn't natively support it Sep 08 13:37:49 I just want to get rid of the USB connected serial devices Sep 08 13:37:56 yip .. totally hear ya! Sep 08 13:38:10 Because I've had just as many problems with glitching usb connectors... Sep 08 13:38:15 yup! Sep 08 13:38:32 * veremit wears the t-shirt :) its a pain embedded stuff huh!? :D Sep 08 13:38:35 Mmmm Sep 08 13:38:44 * Spidler hands veremit an mbus card. Sep 08 13:39:00 I wish I had the guts to get one designed for the BBB. Sep 08 13:39:50 :) Sep 08 13:40:29 My house server got fried via the DSL line. Kinda sucked. Still does. Is there a reason why a PRU won't work for a "driver"? Complexity I expect. Sep 08 13:42:24 Mmm Sep 08 13:42:28 * Spidler glares. Sep 08 13:42:29 Right Sep 08 13:42:33 RS232 on UART2... Sep 08 13:42:44 And when I plug out the ethernet connector I get garbage on my serial... Sep 08 13:42:52 WHat . the .. FUCK Sep 08 13:44:31 Ragnorok: the PRU is one option, it has access to the UART peripherals Sep 08 13:44:56 .. Problem solved, glitching cable, when I moved the ethernet.. Sep 08 13:44:58 Yey! Sep 08 13:45:03 I love easy to solve problems! Sep 08 13:45:11 Just thought it might be able to do an end run on these other issues. (shrug) Sep 08 13:45:15 \o/ Sep 08 13:45:34 Spidler: more tac required :D Sep 08 13:46:08 tac? Sep 08 13:53:35 * Spidler looks at his system.. ttyUSB0, ttyUSB1, ttyUSB10 ... someone is counting as if it's javascript.... Sep 08 13:54:25 ah if it's bounced, they dont' clean up properly .. blame udev Sep 08 13:54:27 or systemd Sep 08 13:54:40 you'll have to unplug the lot to clear the stack Sep 08 13:55:08 Nah. Sep 08 13:55:14 I just unplugged 8 ports ;P Sep 08 13:55:39 Well, I unplugged the _power_ to it it seems Sep 08 13:55:54 I've got a lot of these different USB/serial adapters on my desk Sep 08 13:56:02 At some point it becomes very annoying to figure out which port is which. Sep 08 13:56:15 So simply unplugging all of them and seeing what remains turns to the solution. Sep 08 13:56:37 The alternative is a udev rule that names them after the USB-hierarchy. and that's not too fun Sep 08 13:57:35 Speaking of systemd, I've disabled syslog and think I've configured journald for 25M in logs, but I never see more than 4M in /var/run/log/journal. Sep 08 13:59:23 Spidler: use the power of udev and give each adapter a specific name Sep 08 13:59:28 Ragnorok: can't help with systemd - I have a quiet loathing of it and its philosophies Sep 08 13:59:43 Spidler, KotH: I'd tend to agree Sep 08 13:59:48 lol I can understand that. Sep 08 14:00:33 I may have to start to get a devuan(?) build going for arm .. else it's cross-compile gentoo :/ Sep 08 14:01:56 veremit: I'm under the impression systemd is so insinuated into the BBB that's it's not possible to remove it. I could just disable journald I suppose and go back to syslog. Basically I only want logging to happen once, and since systemd is already there... Sep 08 14:02:33 Ragnorok: its woven into the fabric of debian now .. esp. jessie Sep 08 14:03:44 Ragnorok: systemd has nothing to do with BBB Sep 08 14:04:05 no .. its the host OS :) Sep 08 14:04:11 Ragnorok: one is a boated /sbin/init, the other is a hardware platform Sep 08 14:04:31 Roit. I was being lazy. BBB is easier than Debian. That's what I get, I guess. Sep 08 14:04:32 but .. I haven't seen many other ready-to-go images for BBB yet .. although I've barely looked Sep 08 14:04:47 Meh, I quite _like_ systemd Sep 08 14:04:56 veremit: i have quite a few machines with jessie and stretch and do not run systemd Sep 08 14:05:07 Then again, I've been the fucking maintainer of monit, sysinit and a few other init scripts through the years. Sep 08 14:05:08 veremit: i also don't have any problems and my system boots under 20s Sep 08 14:05:14 KotH: yeah, how did you make that happen!? Sep 08 14:05:26 Serious. Mine takes 27. Sep 08 14:05:30 veremit: i never installed systemd in the first place ;) Sep 08 14:05:51 Ragnorok: with a bit of tweaking you can get it under 10s with sysV Sep 08 14:05:53 KotH: how do you get around that at the installer phase? I thoguht it was welded into debian now?? Sep 08 14:06:08 KotH: Nice. Sep 08 14:06:13 veremit: all of my machines are older than wheezy :) Sep 08 14:06:19 KotH: *D'oh* Sep 08 14:06:23 lol Sep 08 14:06:27 fair call :D Sep 08 14:06:32 veremit: but yes, a fresh install is systemd and you have to uninstall it manualy Sep 08 14:06:43 veremit: but it can be done Sep 08 14:06:56 Sound complicated. Sep 08 14:07:01 not really Sep 08 14:07:14 You can make it boot faster than that. ;) Sep 08 14:07:17 at least not anymore complicated than running apt-get Sep 08 14:07:20 KotH: yeah I can imagine, just don't want the hassle, which is why I went debian in the first place :D .. but it looks like I'm going to sink into the hardcore gentoo end eventually anyhow for the flexibility Sep 08 14:07:25 I still have the source for our custom init-system from a few years ago Sep 08 14:07:26 zmatt claims around 4 seconds. Sep 08 14:07:44 veremit: well, i can understand that the debian-installer guys do not want to support two init systems at install time Sep 08 14:07:54 I'm targetting around 10s for an imx6 with wifi ... Sep 08 14:07:58 So I can just apt-get remove systemd and it won't shit itself? Sep 08 14:08:02 which is on the back-burner right now Sep 08 14:08:15 Ragnorok: record i've seen on a embedded system was <1s from power applied to Qt app running Sep 08 14:08:21 Wow. Sep 08 14:08:28 Ragnorok: and no, it wasnt a systemd system ;) Sep 08 14:08:40 that's gotta be hibernated .. Sep 08 14:08:43 I'd be delighted to hit under 5. Sep 08 14:08:54 Ragnorok: the release notes say how you get to a sysv system Sep 08 14:08:55 or suspend or similar .. Sep 08 14:09:07 KotH: Ok. Thanks! Sep 08 14:09:09 Ragnorok: you need to do some apt pinning as well to prevent systemd from comming back Sep 08 14:09:11 KotH: for jessie? Sep 08 14:09:13 veremit: yes Sep 08 14:09:21 mm will have to try that Sep 08 14:09:29 am i the only one here who reads manuals and release notes? Sep 08 14:09:37 RTFM?! never .. Sep 08 14:09:42 I read manuals. Release notes not so much. Sep 08 14:10:07 KotH: its that fatal balance between "install, go" and "f** it doesn't work .. rtfm" Sep 08 14:10:07 * KotH learned the hard way to _always_ read the debian release notes before upgrading Sep 08 14:10:16 rofl Sep 08 14:10:34 * Ragnorok learned just pin grub and it'll at least boot after upgrading Sep 08 14:10:43 Not the BBB ofc. Sep 08 14:10:54 grub4arm ftw... Sep 08 14:11:09 ..... Sep 08 14:11:21 although .. I -think- similar has been done .. you can get lilo I -tyhink- Sep 08 14:11:40 lilo? now you're just being a neckbeard ;P Sep 08 14:11:51 Noone who's enjoyed life will go back to lilo Sep 08 14:12:06 you have to do a bit of chainloading I suspect .. from uboot-> Sep 08 14:12:39 Being a neckbeard I have to concur. Sep 08 14:13:03 Spidler: until recently, pre-instaled computers at this university came with lilo Sep 08 14:13:12 About lilo that is. Sep 08 14:13:15 Spidler: last 6 months kind of recently Sep 08 14:13:23 KotH: ... oh fuck. Sep 08 14:14:07 that's pretty shameful .. Sep 08 14:14:17 even grub-legacy is looking 'old' .. Sep 08 14:15:00 gummiboot ftw ;P Sep 08 14:15:07 hahaha Sep 08 14:15:18 Not that I have any hardware that can actually do that, but hey. Sep 08 14:15:33 I'm weird in that I think EFI secure boot is a quite decent design. Sep 08 14:15:46 Well, "less turgid than the ACPI mess" Sep 08 14:15:57 lol Sep 08 14:16:06 yeah I haven't opened -that- can of worms yet Sep 08 14:16:15 It's not pretty. Sep 08 14:16:20 turgid <- good usage Sep 08 14:18:28 Hmm Sep 08 14:18:37 Anyone here who has a BBB with the bb-overlays in it? Sep 08 14:19:29 Can you try to echo BB-BONE-WL1837 > /sys/bus/platform/devices/bone_capemgr/devices and see if that crashes your Beagle? Sep 08 14:19:38 Or if that's something unique to me;P Sep 08 14:21:55 I don't appear to have that, by find. Sep 08 14:22:08 it's in the bb-overlays package. Sep 08 14:22:17 * Spidler goes to scourgue up another beagle Sep 08 14:22:25 Right Sep 08 14:22:29 I've run out of serial cables Sep 08 15:16:22 Hi. Anyone knows whats the production lifetime of the BeagleBone Black? Sep 08 15:16:40 And if there are plans to make un updated version of it? Sep 08 15:20:05 pedro_nf: A Long Time(tm) and No. Sep 08 15:20:34 there are variants eg. sancloud beaglebone enhanced(?) Sep 08 15:20:40 veremit: thanks Sep 08 15:21:04 ok so I can count on it for the next few years? Sep 08 15:21:23 1) as long as the cpu is manufactured .. and there's no plans to EoL it Sep 08 15:21:32 definitely Sep 08 15:21:39 yes, I checked that out with TI Sep 08 15:21:56 there is no eol for its processor Sep 08 15:22:50 so if I want to invest on a mini PC for my project its a good bet, right? Sep 08 15:23:06 better then RPi I guess Sep 08 15:23:21 our production commitment is 10+ years from launch Sep 08 15:23:32 ok nice Sep 08 15:23:40 though updates may happen to BOM for individual components that go EOL (typically RAM) Sep 08 15:23:58 ho ok Sep 08 15:24:08 we may go a few months at a time without production, but we still make the original BeagleBoard. Sep 08 15:24:27 I'm just worried about connector pinout and arch linux compatibility Sep 08 15:24:41 BeagleBone Black launched in 2013, so 2023 for Black. Sep 08 15:24:54 we get commitments from TI for processor availability. Sep 08 15:25:39 ok thanks you for the infos Sep 08 15:29:53 jkridner: That's good info. Thank you. Sep 08 15:30:02 ( Not related, just interested. ) Sep 08 21:30:19 It's nice to know that my beagle bone blacks won't be totally obsolete in a year (just mostly). Sep 08 22:00:30 GenTooMan: still will be a very useful arm building block for years to come... Sep 09 00:18:50 I just installed Ubuntu 16.04 on my beagle board black. I wanted a desktop gui so I installed LXDE, following instructions from elinux.org. Now, my board cannot connect to internet at all. It used to work before but not now. Any help? Sep 09 00:23:00 Reposting my question since I got disconnected: I have installed Ubuntu 16.04 on a microSD card and booted it to the BeagleBone Black. I was successfully able to access BBB from my mac through usb and could access internet. However, i just installed LXDE and it doesn't let me serial connect to the usb or access the internet on the BBB **** ENDING LOGGING AT Fri Sep 09 02:59:58 2016