**** BEGIN LOGGING AT Thu Feb 01 03:00:03 2018 Feb 01 04:11:53 I purchased a new BBX15 last week from Mouser and have a HDMI issue wherein I don't see any display from the monitor connected to the HDMI port. But the user LEDs are flashing on power up. Any idea whats the issue? Feb 01 04:12:53 Also serial debug is not useful because I connected through the FTDI RS232 to USB convertor to my PC but I see only wierd symbols in the teraterm client Feb 01 04:13:41 I checked the baudrate and other serial parameters all seems fine but still text doesn't show up in the teraterm client only wierd symbols comeup Feb 01 04:54:27 Hi! Everyone. Does anyone know how to remotely SSH login into BBB through internet? Feb 01 04:55:13 I always login in through my local network ie 192.168.x.x Feb 01 04:55:39 My BeagleBone already has an IP, as I can ping it Feb 01 04:56:21 but I still can't login it through putty as I did in local network. :( Feb 01 04:57:40 I can even use web browser to see my BeagleBone webpage through internet. But still don't know how to ssh login Feb 01 05:06:41 Still don't know how to ssh into my BBB at home Feb 01 05:07:16 My BBB has a public IP now, as I can ping it and even use web browser to see the BBB main page Feb 01 05:07:42 But can't ssh login my BBB using Putty Feb 01 05:27:56 Still don't know how to ssh into my BBB at home Feb 01 05:58:46 perhaps there's a firewall rule? Feb 01 06:01:52 you mean firewall setting inside the BBB? Feb 01 06:03:21 thanks for reply, zmatt. My BBB now has a public IP. I can ping it, even can use web browser to see the BBB main page Feb 01 06:03:55 (I can event use port 3000 and see the cloud9 IDE) Feb 01 06:04:07 that sounds like such a bad idea to expose that to the internet Feb 01 06:04:09 But just can't ssh login it remotely Feb 01 06:04:50 yes, I'd try to disable it later. For the moment, I just really want to ssh login my BBB at home Feb 01 06:05:02 check iptables -L Feb 01 06:05:57 Guess I have to do this later, for I am really far from my BBB. @@ Feb 01 06:06:15 that's not the best time to ask for help then :) Feb 01 06:06:32 thx anywar zmatt, you always help! Feb 01 06:39:46 @zmatt, I've tried "iptables -L" Feb 01 06:40:27 @zmatt, I see three chains, all with policy ACCEPT. Feb 01 06:42:48 Hello all, can someone help me with a question regarding the beagle board x15? Feb 01 09:23:33 ZtLiu: Have you considered something like https://www.dataplicity.com/ or http://platformio.org/ instead of direct SSH exposure? Feb 01 13:18:07 hello all Feb 01 13:18:26 how can I check which code is loaded on the pru currently Feb 01 13:18:38 and how effective is the PyPRUSS library? Feb 01 15:02:54 hello all, on the blue how can i refer to the pins I2C_SDA_2 etc Feb 01 15:03:00 in a program? Feb 01 15:03:14 what for? Feb 01 15:03:40 like Feb 01 15:03:46 in case you want i2c, use the i2c device driver. in case you want a gpio, read up on pinmuxing and use the sysfs :) Feb 01 15:03:49 if i download a mpu9250 library Feb 01 15:04:09 ok thanks Feb 01 15:04:15 one more question if you don't mind Feb 01 15:04:49 Can i use a generic peripheral library with the blue? for example say I download a mpu9250 driver library Feb 01 15:05:07 can I pass in the i2c pins and use the driver? Feb 01 15:05:35 (that reads very much like: thank you for answering my previous question, but i don't like the answer. can't you just tell me what i want to hear?) Feb 01 15:06:31 for gpio im using the adafruit libs for beaglebone Feb 01 15:06:37 well apologies but i don't mean to be rude Feb 01 15:07:09 see, three is already a driver: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/drivers/iio/imu/inv_mpu6050 Feb 01 15:08:22 so if you are on linux, the way to do it is to just use that driver as-is, and not to ride gpios just because some random library for a uC does that. Feb 01 15:09:22 i understand but i need to be coding in python as i am pretty much handicapped in C/C++ Feb 01 15:09:34 so i thought i could use a python library for the MPU Feb 01 15:09:34 so thats the difference? Feb 01 15:09:52 difference in? Feb 01 15:10:12 there is a driver. that driver provides sysfs files. and open/read/write/close surely ain't that difficult in python too. Feb 01 15:11:04 as far as i can see, there is absolutely no c involved. Feb 01 15:11:30 okay umm, could you briefly explain how i would use this driver in a python script? Feb 01 15:12:44 step 1: you add it to the device tree so the kernel is aware of it. step 2: the driver provides files to be found under /sys that you can just use Feb 01 15:13:54 won't the blue already have this driver? Feb 01 15:14:59 here, that looks like a relatively nice writeup on how devices are enabled through the device tree: https://stackoverflow.com/questions/33549211/how-to-add-i2c-devices-on-the-beaglebone-black-using-device-tree-overlays Feb 01 15:15:24 thank you for your patience with my inexperience! Feb 01 15:15:42 all is well, just get rid of uC-ish assumptions. :) Feb 01 15:16:18 i was under the knowledge that since the robotics cape is integrated onto the blue a driver won't be needed Feb 01 15:17:27 i don't know the blue. if this is some integrated peripheral, then the overlay for it should hopefully be already enabled, tight Feb 01 15:18:53 that looks like it does the i2c stuff manually: https://github.com/dmh2000/bbb-imu Feb 01 15:20:29 ill go and read up about using these drivers, but if i got you right, i should integrate this driver into a python script? Feb 01 15:20:36 rather than use python libraries as is.. Feb 01 15:20:47 that also seems to have a lot of inspiration: https://github.com/StrawsonDesign/Robotics_Cape_Installer Feb 01 15:21:32 no, i'm just saying that you should not try to manual bitbang i2c to that device, unless you have an extremely good reason - and "i just have this library" is an extremely bad one. Feb 01 15:23:07 im sorry what did you mean by "manual bitbang" Feb 01 15:23:24 and https://github.com/dmh2000/bbb-imu/blob/master/src/mpu9250.py is using the ADAFRUIT_I2C..?? Feb 01 15:24:29 https://en.wikipedia.org/wiki/Bit_banging Feb 01 15:26:19 so what are you saying here... i shouldn't use libraries i don't understand? Feb 01 15:26:30 partially. Feb 01 15:27:18 you don't need to understand every last bit of a library. but you need to understand what it does, and in what way. Feb 01 15:27:59 alright cool Feb 01 15:28:03 thanks :) Feb 01 15:28:24 i don't know if that adafruit thing properly uses the i2c driver, or if it does bitbang stuff. if it does the former, all is well. if the latter, then i would not recommend using it. Feb 01 15:40:30 uhh, why on earth would it bitbang? Feb 01 15:41:38 zmatt: because a lot of people who "port" stuff from uCs think that it is super cool? Feb 01 15:55:07 the adafruit stuff isn't ported from uCs, it's just dumb wrappers around existing code and/or sysfs access Feb 01 15:55:58 then all is well, just like i said. but why should he ask for using specific pins then? Feb 01 15:56:11 he meant which i2c bus Feb 01 15:57:57 sure, i can have misunderstood. but "how can i refer to the pins I2C_SDA_2 etc" sounds very much like "i want to do something with that specific pin" Feb 01 18:12:59 hello all, im trying to write an python mpu9250 driver for the beagle bone blue using smbus Feb 01 18:13:06 and when i choose the bus to be 2 Feb 01 18:13:09 it throws an error Feb 01 18:13:38 now on the schematic mpu9250 is connected to i2c bus 2 Feb 01 18:14:56 can anyone tell me how to use smbus to read the emu on the cape Feb 01 18:15:15 what's the error? Feb 01 18:17:02 well when i try to write to the imu to initialise it, it throws an error, here is the command i run: bus.write_byte_data(self.address, PWR_MGMT_1, 0x00) Feb 01 18:18:07 shall i post the error message here? Feb 01 18:18:27 use pastebin.com if it's more than one line Feb 01 18:18:46 well i guess it can be summed up as: Remote I/O error Feb 01 18:19:35 that means NAK Feb 01 18:19:42 ? Feb 01 18:19:57 a NAK response on the i2c bus Feb 01 18:20:15 but the i2c bus which imu is on is 2 Feb 01 18:20:38 it shows in i2cdetect -r 2 Feb 01 18:21:35 avoid using i2cdetect, it is a rather hazardous command to use and can confuse the heck out of i2c devices, even up to the point of them becoming unresponsive Feb 01 18:22:00 whoa Feb 01 18:22:03 okay cool Feb 01 18:22:09 so then whats the problem now Feb 01 18:22:38 bus = smbus.SMBus(2) Feb 01 18:22:40 well, if you got any sort of response from it using i2cdetect then clearly there's just an issue in your python code Feb 01 18:22:48 thats how i initialise the bus Feb 01 18:23:33 sure you got the right address? Feb 01 18:24:29 SLAVE_ADDRESS = 0x68 Feb 01 18:24:36 which is what shows up on i2cdetect Feb 01 18:25:02 should be right Feb 01 18:27:46 then dunno Feb 01 19:21:00 zmatt: sometimes, a digital scope with an i2c protocol decoder can be quite handy ;) Feb 01 19:21:19 or anything cheap supported by sigrok Feb 01 19:30:22 usually not needed though unless you suspect bugs in the kernel i2c driver or you're getting particularly confusing results Feb 01 21:05:26 hello all Feb 01 21:05:44 how do i check which i2c kernel drivers are present on my BB? Feb 01 21:05:51 does smbus use these drivers? Feb 01 23:48:11 using beaglebone black for a project at school and we started coding on keil selecting a project using the ARM cortex a7 processor and wondering about the compatibility of the ARM cortex a8 which the beaglebone black has Feb 01 23:48:28 we are coding in C Feb 01 23:49:20 uhh, for applications there's generally no difference Feb 01 23:49:37 apart from performance characteristics Feb 01 23:50:31 can you elaborate on performance characteristics? I did check compatibility and it seems like it is but i need to verify Feb 01 23:51:13 speed is a high concern for us and it is the reason i ask Feb 01 23:53:18 hard to elaborate on it in a general sense Feb 01 23:53:56 iirc the a8 does have a much faster (in the sense of performance/clockspeed ratio) implementation of Neon instructions Feb 01 23:54:27 any floating-point instructions that can't execute in the Neon pipeline are fairly shit on the cortex-a8 however Feb 01 23:55:29 other than that, there are just too many variables involved in performance to make any general statements Feb 01 23:57:26 well just asking in terms of programming sense....the BBB will interface with an ADC and DAC....operating as a universal amplifier controller. must be able to handle dynamic loads and will need to be very responsive. We have selected this to meet our parameters Feb 01 23:58:41 using keil and selected the project to be under the ARM 7 Feb 01 23:59:26 "ARM 7" ? ARM architecture v7 ? ARM cortex-a7 ? ARM7 ? those are all very different things Feb 02 00:01:12 normally the exact ARM core you use is a fairly unimportant detail, although you can select the right specific cpu rather than generically ARM architecture v7 to perhaps squeeze a tiny bit extra performance out of code Feb 02 00:02:05 yeah it's not specified in the keil 4.74 version i'm using. ARM7 (big endian/little endian) Feb 02 00:03:00 selecting ARM7 (either endian) comes up as ARM7TDMI-S Feb 02 00:03:08 those are ancient cpu cores Feb 02 00:03:19 like way older than any cortex-A series Feb 02 00:03:51 you may still find those in some small microcontrollers, although they've been replaced by cortex-M for the most part Feb 02 00:03:59 such is the way around my university. Feb 02 00:05:17 ? Feb 02 00:05:28 alright....second question i have is are there open source start up codes available for download? codes dealing with interrupts, timers, handling uart? Feb 02 00:05:53 oh you want to write baremetal code? Feb 02 00:06:29 (everything is out dated around here is what i mean by my previous comment) Feb 02 00:07:33 that's a new and somewhat unfamiliar term with me....but i think so Feb 02 00:07:51 not many people do baremetal programming on a beaglebone, most just run linux. TI does has some library/startup/example code collectively called "StarterWare", though from what I've seen of it, its quality... how shall I put it... Feb 02 00:08:04 "a steaming pile of pig manure" comes to mind Feb 02 00:09:11 baremetal means running directly on the hardware, without any OS Feb 02 00:09:31 baremetal programming aids in performance...isn't that correct? Feb 02 00:10:03 obviously an OS tends to add overhead Feb 02 00:10:41 linux more so than e.g. an RTOS Feb 02 00:10:50 yeah okay...i understand. we are running baremetal then. coding in C Feb 02 00:12:35 if the performance-critical part of your code is small enough, there's another option on the beaglebone: there's a set of two cores called "PRU cores" which are specifically intended for real-time tasks. you can keep the convenience of linux on the ARM core while using the PRU cores for the parts that need it Feb 02 00:13:01 that's assuming by performance you mean real-time responsiveness rather than computational power Feb 02 00:14:45 yes, you have me understood. operating in real-time is needed Feb 02 00:15:30 we won't be needing float, will be using a fixed point Feb 02 00:15:41 a good example of how their combined capabilities can be put to work is the BeagleLogic project, a 14-channel 100 Msps logic analyzer that uses the PRU cores to sample the digital inputs and transfer the data to a ringbuffer in RAM, while the ARM core is responsive for analyzing the data and/or shipping it off over the network Feb 02 00:16:35 even fixed-point math is limited on the PRU cores (floating-point is not supported at all there) Feb 02 00:17:56 sounds somewhat similar with our project, using an ADC to BBB and using the digital data to reconstruct a waveform with a DAC Feb 02 00:18:47 well, that does sound overall more complicated Feb 02 00:19:00 so you want ADC -> computation -> DAC ? Feb 02 00:19:08 yes i'm familiar with each and the sig figs needed are a certain resolution Feb 02 00:19:18 yes that will be done Feb 02 00:19:23 what sort of input->output latency are you aiming for? Feb 02 00:19:37 (excluding any latency inherent to your computation) Feb 02 00:19:49 microseconds Feb 02 00:20:03 or less than Feb 02 00:20:51 sounds like you're going to have an interesting time with this project Feb 02 00:20:56 we have a set bandwidth to operate on and have a simulated code already worked out with it running in 10^-6 range Feb 02 00:21:39 continually doing our best to make it even more responsive Feb 02 00:21:45 might it not make more sense to use something like a DSP for this? Feb 02 00:22:19 for our application it does not fit Feb 02 00:23:02 how so? Feb 02 00:23:35 also, how much data are we talking about, and how are you interfacing to the ADC and DAC ? Feb 02 00:24:19 we have certain parameters to meet for this project which will need user input for selected freq to be generated with LCD display, ethernet, optional wifi/bluetooth capabilities Feb 02 00:25:20 lol Feb 02 00:25:43 and you expect to get all that working without an OS ? Feb 02 00:26:07 I hope you have a team of really good people and lots and lots of time :) Feb 02 00:26:24 yes, we are all engineers, and this is our senior design Feb 02 00:27:10 in a real-world situation, you'd just use a DSP for the signal processing and hook it up to e.g. a beaglebone running linux for the gui and connectivity Feb 02 00:27:27 would save a ton of time probably Feb 02 00:28:34 needing data read from a bi-directional coupler of foward and reflected power, read and processed by the BBB, and out to the DAC to a power amp Feb 02 00:28:35 maybe you can use the PRU subsystem to run the performance-critical part, that would save using an external DSP (or other processor) Feb 02 00:29:49 essentially that would still use separate processors for high-level tasks (ui and networking) vs real-time tasks, except it's already integrated which simplifies things Feb 02 00:31:49 but the two PRU cores have only 8KB of instruction memory each (2048 instructions) and the amount of data RAM is similarly limited, so you can't fit large applications there Feb 02 00:32:30 i see, it's a possibility, as for now we are writing everything out. Feb 02 00:33:28 thanks for your help. Feb 02 00:33:43 getting back to the project Feb 02 00:34:20 interfacing with an ADC and DAC will also be interesting with such low latency constraints Feb 02 00:56:10 1) Do not apply any voltages to any I/O pins when the board is not powered on. Feb 02 00:56:10 2) Do not drive any external signals into the I/O pins until after the SYS_RESETn signal is HI (3.3V). Feb 02 00:56:10 3) Do not apply any voltages that are generated from external sources until SYS_RESETn signal is HI. Feb 02 00:56:53 do i get it right that i can't even, say, pull a gpio pin up with a 3.3V header pin? Feb 02 00:57:12 yeah that's bullshit Feb 02 00:57:23 // https://elinux.org/Beagleboard:BeagleBoneBlack Feb 02 00:58:09 it's mostly okay to drive signals into the BBB if they're powered from the 3.3V provided from P9 Feb 02 00:58:17 with some footnotes and asterisks Feb 02 00:59:43 gating it based on reset is definitely safer still, but I wouldn't worry about pull-ups... as long as you don't mess with the boot-mode pins on P8 Feb 02 01:00:11 also somehow i've burned one gpio to a state that it can only get up once and won't switch off until the board is completely powerless :) Feb 02 01:00:48 then you're still lucky Feb 02 01:00:50 and it's not the internal pulldown transistor that is dead as it actually supplies current all the time Feb 02 01:01:05 regardless the setting Feb 02 01:02:19 frying a IO frequently results in internal short-circuit between the power rails and render the board dead. having it result in a short just between the IO and either power or ground (but not both) is not that bad of an outcome Feb 02 01:02:33 it does illustrate why you need to be careful with how you treat the IO Feb 02 01:03:57 yeah, i'm just curious about how such an outcome would actually work, took me some burnt plastic to figure it out as the gpio was controlling a heater Feb 02 01:05:28 I don't know exactly what happens internally. I do know that the internal ESD-protection diodes tend to be involved in the short-circuit that results from exposing an IO to overvoltage Feb 02 01:08:24 the IOs are more complicated than more people realize anyway, since the tiny tiny transistors of the 45nm process at which the AM335x is manufactured have such a thin gate oxide that their absolute maximum rating is 2V, so it's pretty non-trivial that it has 3.3V I/O at all Feb 02 01:11:04 the gpio was controlling a heater... what did you connect to it? Feb 02 01:12:24 a mosfet gate thru a resistor Feb 02 01:13:18 i don't remember the resistor value, but it must have limited the current to a few milliamperes Feb 02 01:13:20 hum, that shouldn't present any significant load to the IO nor introduce an external voltage to it Feb 02 01:13:55 uhh, there shouldn't be any current flowing through a mosfet gate, other than when it's switching Feb 02 01:14:12 and switching a power mosfet can produce quite big currents Feb 02 01:14:17 ah Feb 02 01:14:19 so i decided to be on the safe side Feb 02 01:14:21 big capacitance Feb 02 01:14:25 yep Feb 02 01:14:44 (a few miliamps is btw also the max you should draw from a processor IO) Feb 02 01:14:53 yeah i know Feb 02 01:15:14 any risk of ugly voltage spikes being capacitively coupled back onto the IO ? Feb 02 01:15:38 I can imagine a heater may have quite a bit of inductance Feb 02 01:15:48 dunno Feb 02 01:16:56 my primary theory is that the ground of the heater (and mosfet) have disconnected from the ground of the SoC as i had a mess of wires and separate PSUs for the board and for the heater Feb 02 01:17:28 so i could get a worst case of 310V/2 from atx psu divider or something Feb 02 01:18:39 sounds like you're really lucky anything survived at all Feb 02 01:18:50 the mosfet is intact btw Feb 02 01:18:55 maybe consider something like an opto-coupler? Feb 02 01:19:56 yeah i'm considering this, but i don't really know how to evaluate such risks Feb 02 01:21:07 also, you could try to provide IOs that interact with messy systems (even if indirectly) some extra protection by adding schottky diodes from GND -> IO and IO -> 3.3V to prevent transients outside this range Feb 02 01:21:38 together with a series resistor, this provides a fair amount of protection Feb 02 01:21:40 also i'm not sure there are popular (easily available from local shops) optocouplers w/ push-pull outputs Feb 02 02:57:24 they have isolated gate drivers, I would suggest that. Unless the opto isolator is designed for the appropriate speed and you have a gate driver on the other side (etc) the isolated gate driver is the simpler solution. Of course probably no one is still listening so this probably doesn't matter. **** ENDING LOGGING AT Fri Feb 02 03:00:04 2018