**** BEGIN LOGGING AT Fri Jan 25 02:59:58 2019 Jan 25 03:03:06 Hello! Jan 25 08:53:07 Hello ! Jan 25 09:00:24 I have enabled ttyO1 loading BB-UART1-00A0.dtbo , accordlying to schematics, P9-24 and P9-26 are Tx and Rx for this UART Jan 25 09:01:48 Connecting them to a serial terminal and running minicom (same speed 9600 N81) , minicom is able to send (wrong) carachters to terminal , but not vice-versa Jan 25 09:02:40 so it seems P9-26 (rx) isn't working, how to check if pin is involved in other tasks ? Jan 25 09:34:39 looping RX and TX works ok , external terminal issue sry Jan 25 11:31:51 a serial terminal? ehhh, I hope you're not connecting beaglebone i/o to an actual rs232 port without using an rs232 driver chip Jan 25 12:25:30 hi, just found the bbb and the cape-concept and hope that someone can ansert my (stupid) questions. Is it possible to simultaneous use multiple capes? i.ex attach 3 "BeagleBoard.org Comms Cape" to be able to interface 6 (3*2) 4-20mA interfaces? Jan 25 12:41:04 Hardware Issue of the day : Jan 25 12:43:46 I'm connecting UART1 (P9-24, P9-26) to an STM32F070 board Tx-Rx, They share the same +5V supply , whenn booted together, beaglebone stays freezed for 70 seconds before to boot (all leds off) then it starts Jan 25 12:44:05 The same happens when reboot is issued to beagle Jan 25 12:44:56 Disconnecting P9-26 (beagle Rx) no issue Jan 25 12:45:24 without looking at the schematics, it might be that this applies pullups or pulldowns to some sysboot pin, and therefore affects the boot order that the rom tries Jan 25 12:46:21 newbe: theoretically it is possible, but if they share common pins it probably won't work Jan 25 12:46:36 the STM board RX and TX leads are connected to STM chip by mean of 100 ohm resistor (in series with lines) Jan 25 12:46:47 urgh Jan 25 12:47:18 serial line over a resistor in line? and probably with mismatched voltages? Jan 25 12:48:31 what are beagle's levels when used as UART ? Jan 25 12:48:37 TTL levels ? Jan 25 12:49:06 fred__tv: it is not permitted to drive a voltage into beaglebone I/O while its own 3.3V I/O supply is not up yet. If the STM's 3.3V supply is an independent regulator that comes up before the beaglebone's, then you need to be sure to keep the uart lines in high-impedance until you're sure the beaglebone is up Jan 25 12:49:31 either that or use a level shifter (even though both sides are 3.3v) or isolator Jan 25 12:50:03 welcome to the fun of working with multiple power domains Jan 25 12:51:43 easiest workaround ? a relay to switch ON 5V to STM board , driven by beagle 3.3 ? Jan 25 12:51:53 (or a transistor Jan 25 12:51:57 ) Jan 25 12:54:03 controlling the stm's power from the beaglebone might work, but it might also just introduce the same problem in the opposite direction. you'd need to check the electrical specs of the stm Jan 25 12:55:06 No problem if STM is powered up when beagle already is, just tried. Jan 25 12:55:38 no *visible* problem != no problem Jan 25 12:56:18 you were lucky to get an obvious visible problem on the beaglebone side (a boot issue), but even without issues you may still becausing cumulative damage to the hardware Jan 25 12:56:41 It would be a nonsense a further interface to keep things isolated until boot ends.... Jan 25 12:56:55 the stm is probably a lot more robust than the beaglebone though Jan 25 12:58:30 I don't understand... think about a STM plus AM335 on a same board they are connected together and have to boot at same time.... Jan 25 12:58:53 it is just one solution, not a requirement. you can also fix it by powering the stm32 from the beaglebone 3.3v supply, keeping both sides in reset until both supplies are up, or configuring the IOs later Jan 25 12:59:38 that's not how it works, the beaglebone's 3.3V supply is provided by a power-management iC that ensures proper sequencing of supplies Jan 25 12:59:51 while you're probably just using an LDO or something for the STM's 3.3V supply Jan 25 13:00:11 which means the STM's 3.3V supply is not properly sequenced within the powerup sequence of the beaglebone Jan 25 13:02:42 the whole power-up of the beaglebone takes dozens of miliseconds, if the STM starts driving a 3.3V into the beaglebone during that time, it will violate its Absolute Maximum Ratings, and both potentially disrupt its functioning and potentially damage it Jan 25 13:04:09 clear Jan 25 13:04:47 also consider the possibility of what happens if the beaglebone shuts down for whatever reason (due to software request or because the pmic detected a problem) Jan 25 13:05:49 https://imagebin.ca/v/4UjHMO2cz34f Jan 25 13:06:10 TX and RX are connected directly to beagle header Jan 25 13:06:39 so a voltage is applied when STM board is powered up Jan 25 13:10:45 does, "rx" here mean from the STM's perspective, i.e. driven by the beaglebone? Jan 25 13:14:04 yes Jan 25 13:15:26 I understand they are useful for diagnostics, but apart from the signal deterioration caused by connecting those leds to a communication line, I'm also a bit worried about how much current is flowing through them... but it depends a bit on the voltage drop across the led Jan 25 13:17:07 the beaglebone i/o are not designed to drive a substantial amount of current continuously Jan 25 13:17:43 why is the series resistor so much smaller for the rx led than for the tx led? Jan 25 13:19:24 anyway, most issues would have been fixed if you used the beaglebone's 3.3V supply also for your external hardware Jan 25 13:19:59 I understand that's not always practical, but once you have multiple power domains you really need to start thinking about what happens during power-up/down to ensure specifications are not violated Jan 25 13:20:13 I got to go now, good luck Jan 25 13:23:07 (also that 100ohm series resistor on the rx line near the stm is useless, if it's meant as series termination then it needs to be near the driving side of the line, i.e. the beaglebone in case of the rx line) Jan 25 13:29:31 wait, looking at the STM schematics, it seems it can be supplied with 3.3 Jan 25 13:30:10 just tested, it works at 3.3 as well as 5V, @65mA Jan 25 13:30:37 I could use VDD_3V3 or SYS_5V from beagle Jan 25 13:30:48 (that are 250mA rated) Jan 25 13:34:42 From manual : Jan 25 13:34:44 The VDD_3V3EXP rail is supplied by the LDO on the BeagleBone and is the primary power rail for expansion boards. Jan 25 13:34:57 The SYS_5V rail is the main rail for the regulators on the main board. When powered from a DC supply or USB, this rail will be 5V. The available current from this rail depends on the current available from the USB and DC external supplies. Jan 25 14:00:02 tbr: I have won the China lottery and now I have a couple of spare LED matrix displays Jan 25 14:00:12 tbr: if you're interested, I can bring some to fosdem Jan 25 14:00:17 tbr: provided you're there Jan 25 14:01:12 thinkfat: unfortunately, not going this year. somehow couldn't convince myself. Jan 25 14:01:32 but thanks for the offer Jan 25 14:52:03 fred__tv: supplying it by the 3.3V supply of the beaglebone should fix all problems Jan 25 14:52:13 65 mA is no problem Jan 25 14:53:06 already done , works perfectly ! Jan 25 14:53:35 step-by-step , problem-by-problem .... Jan 25 14:55:50 little (big) problem : I send a command to STM , it gives me back immediately an answer in numeric format : how to display on console or capture into a file ??? Jan 25 14:56:18 printf "command" /dev/ttyO1 works Jan 25 14:56:48 >/dev/ttyO1 you mean Jan 25 14:56:52 but see no answer (only note the RX led giving back data) Jan 25 14:57:03 the problem is that you're opening and closing the serial port Jan 25 14:57:08 yes > Jan 25 14:57:22 right Jan 25 14:57:30 this problem wouldn't exist if you communicated via the serial port in a real program, but you can work around it in bash too Jan 25 14:57:44 I need it done in bash Jan 25 14:57:59 open the serial port using: exec 4<>/dev/ttyO1 Jan 25 14:58:12 now the serial port is opened at file descriptor 4 in the shell Jan 25 14:58:36 you can write to it using the redirection >&4 and read from it using <&4 Jan 25 14:58:42 "file descriptor 4" is just new to me..... :-((( Jan 25 14:58:51 ahhh Jan 25 14:59:03 each open file in a process has a non-zero integer to designate it Jan 25 14:59:13 0, 1, and 2 are stdin, stdout, and stderr Jan 25 14:59:28 ok Jan 25 15:00:02 if you want to close the serial port without having to close the shell, you can use: Jan 25 15:00:05 show me a practical exaple please.. Jan 25 15:00:08 exec 4>&- Jan 25 15:00:50 just use >&4 instead of >/dev/ttyO1 (after opening it using the command I gave above) Jan 25 15:02:34 read -r foo <&4 would read a line and store it into the shell variable $foo . read can also read until a different delimiter, or a fixed number of chars, see "help read" Jan 25 15:03:36 ok , but how can it be done in a single line command ? (send command and display answer?) Jan 25 15:04:14 uhh no, although you can make it a single command of course Jan 25 15:04:50 but at some point you'll be pushing against the limits of what is practical to do in bash scripting... bash is not really meant to be used as general-purpose programming language Jan 25 15:05:10 honestly, display the answer is for testing purpose, I really need to write answer into a file.... Jan 25 15:05:42 ok, so write the answer into a file Jan 25 15:06:07 and if you want to do all these things (open port, write command, read answer, write answer to file) in sequence, then make a shell function or a bash script for it Jan 25 15:06:41 (a python script to do the same might actually be shorter and more readable and reliable though) Jan 25 15:07:21 the 1% i know about bash, is ALL i know about programming language....:-((( Jan 25 15:08:59 sticking to bash is probably only going to make things harder in the long run, since doing stuff like this in bash is harder and more arcane than doing it in a real programming language Jan 25 15:09:05 can't it be done in something like "cat /dev/ttyO1 > filename" Jan 25 15:09:22 sure, but it will keep reading forever and never finish Jan 25 15:10:37 ok Jan 25 15:10:44 also, since it opens the serial port for that command I'm not sure if any previous data is kept buffered or not. opening the serial port like I explained earlier and using cat <&4 >file would fix that particular problem, but would not fix the problem of it continueing to run forever Jan 25 15:11:01 that's why I suggested the read command, which can read up to a delimiter, a fixed number of chars, and/or a timeout Jan 25 15:12:08 trying... Jan 25 15:15:55 using read to save into a file , how's the syntax ? Jan 25 15:16:21 it can't, it saves into a shell variable, which you can then write into a file Jan 25 15:17:41 read -r foo <&4 & cat $foo > filename ? Jan 25 15:18:10 && you mean, & does not do what you intend here Jan 25 15:18:19 also, echo, not cat Jan 25 15:18:21 sry double... Jan 25 15:18:36 read -r foo <&4 && echo $foo > filename ? Jan 25 15:19:01 without a space between > and filename Jan 25 15:19:17 primary school :-((( Jan 25 15:19:25 what a shame Jan 25 15:19:44 so: Jan 25 15:20:03 and again, this assumes the reply ends in a newline. if you want to use a different condition for terminating the read, see "help read" for the various options Jan 25 15:20:56 printf "command" >&4 && read -r foo <&4 && echo $foo >filename would work ? Jan 25 15:21:19 instead of asking, you could just try it Jan 25 15:21:27 this assumes the port is already opened of course Jan 25 15:21:55 also, it assumes the stm never writes anything to the serial port except in reply to your command, and it assumes the read consumes the entire reply Jan 25 15:22:16 otherwise data will remain buffered and you'll lose proper synchronization between command and reply Jan 25 15:22:51 it would be easy to work around this in most programming languages, but I have no idea how you might fix the problem in bash Jan 25 15:22:52 sure Jan 25 15:30:13 it seems to work.. Jan 25 15:44:38 hmmmm Jan 25 15:45:56 STM answer is composed by 10 rows of numeric data and one row with "OK" Jan 25 15:46:23 can I use OK as end of reading ? Jan 25 15:46:51 no, you'll need to read in a loop until you see the OK response Jan 25 15:50:41 while read -r line && [[ "$line" != "OK" ]]; do echo "$line"; done <&4 >file Jan 25 15:59:07 sry OK is returned without doublequote Jan 25 16:16:59 the doublequote is for the shell, not a literal part of what it matches Jan 25 16:17:08 it works in a single line but inside a script it gives me syntax error [[ Jan 25 16:17:38 your script is probably being executed by sh instead of bash Jan 25 16:17:48 if it has #!/bin/sh at the top, change to #!/bin/bash Jan 25 16:18:06 you're right Jan 25 16:29:47 Board has slightly different behavior when supplied with 3.3V, what about SYS_5V ?? Jan 25 16:31:56 sys_5v has the benefit of at least being cut when the beaglebone powers off, but it still provides power earlier than the 3.3V Jan 25 16:32:19 (sys_5v is switched on at the start of the power-up sequence, 3.3V near the end of the power-up sequence) Jan 25 16:33:12 so is it like to connect at VDD_5V (thus problem) ? Jan 25 16:34:21 using sys_5v is slightly better (by making sure the stm is only powered when the beaglebone is turned on) but otherwise still has the same problem yes Jan 25 16:35:46 another option is to use the reset output of the beaglebone to control a power switch to the stm Jan 25 16:36:07 using the 3.3v of the beaglebone to power the stm directly is however the simplest solution Jan 25 16:42:31 ok I'll do some tests on WE Jan 25 16:42:57 I'm blown.... Jan 25 16:51:33 Have a nice WE ! Jan 25 23:24:43 here's a sequence of perfectly stupid questions I halfway know the answer to. Jan 25 23:25:27 First, my beaglebone black came with an old-ish linux distribution that has python 3, but not pip for python 3. and a lot of my preexisting code is python 3. Jan 25 23:25:44 now, why is that a problem? because there's currently no easy way for me to access the internet from the beaglebone. Jan 25 23:26:04 that said, I know I can pretty much have a bootable sd card. Jan 25 23:26:47 but I like the beaglebone's built-in IDE too. Jan 25 23:28:23 what would be grrreat would be to be able to set up like a python 3 virtualenv and send it (maybe via scp, I don't know) to the beaglebone. Jan 25 23:28:32 now this is starting to look like a python question. Jan 25 23:38:15 syntaxfree: what OS are you using on your host pc? Jan 25 23:39:33 if you're using an old image, updating to the latest iot image is probably a good first step anyway Jan 25 23:39:43 but I'm not sure python3-pip is installed by default Jan 25 23:41:37 getting your beaglebone internet access, even if temporary, would be pretty convenient though. what's your situation w.r.t. internet access, does your computer connect to the internet via wifi? does your computer have an ethernet port? Jan 25 23:42:30 zmatt: I have Windows + WSL Ubuntu. Jan 25 23:43:28 which is 99.9% like booting to Ubuntu except for things windows really wants to control. Jan 25 23:43:38 I'm aware what wsl is Jan 25 23:44:41 (and I disagree with your description of it, but it does a reasonable enough job at emulating the linux kernel to be able to run a lot of linux userspace programs, which is convenient) Jan 25 23:45:19 you don't "boot" into it though, last time I checked you didn't even have a systemd instance Jan 25 23:46:03 I'm a lowly data scientist. I wouldn't know, despite having had linuces as primary oses over the years. Jan 25 23:46:25 I actually bought a cardboard box filled with air and a CD-ROM with red hat 4 in the 90s. Jan 25 23:46:32 but I digress. Jan 25 23:47:15 so.. my question about your internet situation? Jan 25 23:47:49 since in windows it's really easy to bridge ethernet and wifi together, hence if your computer connects to internet via wifi but also has an ethernet port, then it can use the ethernet port to provide internet access to the beaglebone Jan 25 23:50:38 I'm writing that down as one of my top options. Jan 25 23:50:58 I don't have an ethernet cable at the moment, but tomorrow shops should be open until noon. Jan 25 23:51:43 Maybe I should go troll #python to see what's the equivalent of winpython (self-contained python distribution that runs off an usb stick if needed) for modern linux. Jan 25 23:51:52 because I know I can scp files into the beaglebone. Jan 25 23:51:53 this is how easy btw: https://www.windowscentral.com/sites/wpcentral.com/files/styles/xlarge/public/field/image/2016/03/bridge-connection-windows-10.jpg Jan 25 23:52:33 why would you need/want that? Jan 25 23:52:54 every linux distro packages debian Jan 25 23:52:56 eh Jan 25 23:52:57 python Jan 25 23:53:08 both 3 and legacy 2 Jan 25 23:53:27 (also known as the python-2-that-just-keeps-refusing-to-die) Jan 25 23:53:29 to have an entire set of dependencies in a bundle. Jan 25 23:53:50 my beaglebone right now has python3. but not numpy, etc. Jan 25 23:53:51 dependencies get installed automatically by the package manager Jan 25 23:54:19 assuming internet access. again, procuring an ethernet cable, as suggested by you, is my top option right now. Jan 25 23:54:27 major python packages are often also packaged for the os, but more conveniently you just install pip via the os package manager Jan 25 23:54:41 the "self-contained python" alternative may be more convenient under certain constraints. Jan 25 23:54:50 you can also share internet to the beaglebone via usb, but it's slightly trickier Jan 25 23:55:05 I saw a tutorial that tried to explain that. Jan 25 23:55:52 I couldn't follow the steps 100.00%, but something very close to that. Then when I enabled connection sharing, I couldn't ssh to the beaglebone. Jan 25 23:56:21 hmm Jan 25 23:57:41 did you configure your computer to use a static ip address? Jan 25 23:58:15 which tutorial did you follow? the digikey one? Jan 25 23:58:34 not really. I have to take this laptop to work everyday. Network settings are weird there. Jan 25 23:58:53 it's just the network settings for the usb interface Jan 25 23:58:57 doesn't affect wifi or ethernet Jan 25 23:59:16 so shouldn't matter.. hopefully Jan 25 23:59:22 ah, yes. I did that. Jan 25 23:59:54 Anyway. I have a game plan for tomorrow and a date for tonight. Thanks, you were very helpful! Jan 26 00:00:44 you're welcome! if you have more questions, just be sure to stick around after asking them here... it can sometimes take a fair bit of time to get a reply **** ENDING LOGGING AT Sat Jan 26 02:59:57 2019