**** BEGIN LOGGING AT Sun May 22 02:59:59 2016 May 22 06:04:38 ey yooo May 22 09:29:06 * zmatt fell asleep May 22 09:33:37 just tried hotplugging a small hub-powered hub which already had two devices attached (mouse and wireless keyboard/trackball combo) ... it worked fine and detected the hub and both attached devices. it also produced three entries in /sys/bus/hid/, one for the mouse and presumably the other two for the keyboard and trackball. it only produced an input device for the mouse (which worked, verified using May 22 09:33:43 evtest), not for the other two, but my kernel is ... May 22 09:33:45 ... fairly heavily stripped of drivers May 22 10:02:07 hey zmatt ! can you help me with some hardware thing ? trying to get a way to connect an ADC EVM to the PRUs. May 22 10:03:08 this is the EVM http://cds.linear.com/docs/en/demo-board-manual/dc782A.pdf May 22 10:03:38 don't ask to ask, just ask. I have limited time right now, but I'm not the only person here providing help :P May 22 10:03:44 I am trying to find a way to use that encode clock connection there ( J3 on the schematic ) with the pru. May 22 10:03:55 okay :) May 22 10:05:40 well the schematic makes evident it 50-ohm terminated coaxial, AC-coupled to the input buffer May 22 10:06:01 So the point with the encode clock it all that circuit there, that is basically a sinusoidal to square converter. But i want to use a pulse train from the pru May 22 10:06:08 and it should be terminated May 22 10:07:59 depending on model it accepts frequencies up to 170 MHz, and ADCs tend to be fussy about the cleanliness and stability of their main clock May 22 10:08:26 hence the use of a properly terminated and shielded input May 22 10:09:04 so I should use a parallel termination ? May 22 10:09:13 with that 50 ohms there ? May 22 10:09:36 and removing the C12 R7 and R9 ? May 22 10:09:54 dunno, that's how the evm does it but you'd need to check the datasheet what the demands of the adc are exactly May 22 10:10:01 the evm might be doing this just "for convenience" May 22 10:10:02 or something May 22 10:10:07 to allow longer cables May 22 10:10:29 I also don't know if you intend to run it at 170 MHz, or where you'd even get such a clock :P May 22 10:11:09 I will be running it at 40 MHZ max ! May 22 10:12:01 and this is the dsheet of the ADC http://cds.linear.com/docs/en/datasheet/223876fa.pdf May 22 10:12:25 page 19 clearly says , that the clock can be driven using a CMOS level signals May 22 10:13:03 but then it recommends using 2V. May 22 10:13:36 the evm probably does things the same it does to be able to connect a function signal generator or similar May 22 10:13:41 *the way May 22 10:15:56 yes but i need to drive the clock through pru. so what should i do ? May 22 10:16:30 and it wont be a long wire. So theres no need to terminate the line ? May 22 10:17:35 even if termination is requires, we can use double termination ? it will be a voltage divider ( so as to keep voltage range 2V ) and then it will provide termination too . May 22 10:20:00 *required May 22 10:20:25 double termination like : http://www.marvintest.com/downloads/knowledgebase/Q200196%5CFig7b.JPG May 22 10:20:35 using the voltage divider to terminate the line could work (126.7 ohm to ground, 82.5 ohm to ground ges you 50 ohm termination) May 22 10:21:03 that's a horrible drawn picture May 22 10:21:12 yep :) May 22 10:21:57 btw, these questions are related to my GSoC project, beaglescope May 22 10:21:59 for a unidirectional line, series termination at the source is typically preferred over parallel termination at the receiver May 22 10:22:56 parallel termination at the receiver tends to consume a lot of power, but is necessary for multi-drop lines May 22 10:23:03 but May 22 10:23:45 since you already need a voltage divider, reusing that for parallel termination seems sensible. the divider also consumes less power than a normal termination would May 22 10:25:35 wolfram alpha gives me 126.9 ohm to ground and 82.5 ohm to vcc (3.3V) to obtain 3.3V->2.0V conversion and 50 ohm termination May 22 10:26:14 and then we'll have to remove C12, R7 and R9. right ? May 22 10:26:44 well, that wont work i guess .. May 22 10:26:45 overall 209.4 ohm from vcc to gnd, giving 15 mA (52 mW) of wasted power, which isn't hugely bad May 22 10:26:57 the part there ... NC7SVU04 May 22 10:27:01 is an inverter May 22 10:27:08 *unbuffered inverter May 22 10:27:15 hold on please I'm just looking at the datasheet, not the evm May 22 10:27:25 okay May 22 10:27:37 page 24 of dsheet May 22 10:27:44 *23 May 22 10:28:11 there is the same schematic May 22 10:29:41 it also seems they actually prefer 3V I/O, although allowing 3.3V also May 22 10:30:23 at the clock input ? May 22 10:30:28 I/O May 22 10:30:39 and analog supply too actually May 22 10:30:59 (VDD, OVDD) May 22 10:31:31 see table "digital inputs and digital outputs" on page 4 May 22 10:31:43 and power requirements on next page May 22 10:31:53 yep. was on that page. May 22 10:34:03 and they have nothing said about max on CLK May 22 10:34:55 so no voltage divider i guess. May 22 10:35:13 and then serial termination would be better . yes ? May 22 10:35:18 page 19 May 22 10:35:36 first paragraph May 22 10:35:47 (and the rest of that section) May 22 10:36:00 input range ? hahaha ! I thought that was for the previous section May 22 10:36:11 oh] May 22 10:36:16 you're right my bad May 22 10:37:51 okay, then they havent said anything about the input at CLK, except high>=2V May 22 10:37:56 supplying it with 2V swing would actually fail the input specs unless you AC-couple and rbias it May 22 10:38:05 *rebias May 22 10:39:34 okay. so again, series termination . right ? and removing all those caps and resistors. just a 50 ohm resistor in series. May 22 10:39:34 is it ? May 22 10:39:58 how do you intend to generate the clock to begin with? May 22 10:40:20 toggling pru gpo May 22 10:40:31 ok May 22 10:40:31 at the required sampling rate.. May 22 10:41:26 ? about termination ? May 22 10:42:23 "The noise performance of the LTC2238/LTC2237/LTC2236 May 22 10:42:23 can depend on the clock signal quality as much as on the May 22 10:42:26 analog input." May 22 10:43:12 so that's why they're being quite fussy about it May 22 10:44:19 a terminated line being toggled by pru would be a clean enough clock source. isnt it ? May 22 10:44:35 hard to say May 22 10:45:07 the output drivers aren't very strong, and there's plenty of opportunity for noise to couple onto it May 22 10:45:19 a bigger problem probably it not the am335x not the bbb May 22 10:45:31 *but the bbb May 22 10:46:25 so some caps to filter out the noise ? May 22 10:46:46 grounded caps. May 22 10:47:26 on one side. May 22 10:48:04 if you have the tools/knowledge to properly design an analog filter for this purpose, sure. and then you probably still need a clock buffer to resquare it May 22 10:50:36 okay. May 22 10:51:14 btw, also keep an eye on the data signals back to the pru since those are expected to be high-impedance and low-capacitance May 22 10:51:43 and of course use appropriate series termination at the adc side May 22 10:52:16 the problem with using series termination for the clock is that you can't actually place a resistor there (next to the am335x) May 22 10:52:38 output from the buffer 74VCX16373MTD ? or ADC ? May 22 10:53:30 output = data signals back to the pru, that you said are Hi-z and low-cap May 22 10:53:46 if you don't need LCD/HDMI output you could borrow the pixel clock output which does have series termination (PRU can be configured to be clocked from the display PLL, which makes LCDC and PRU run synchronous to each other) May 22 10:54:39 okay. Will ask mentors about that. May 22 10:55:19 yes, "high-z and low-cap" are properties of the load and do not affect the need for series resistance at the driver side, unless those drivers already have the correct output impedance for your line May 22 10:55:46 note that high-z + series resistor is still high-z May 22 10:56:16 unfortunately "correct impedance" is a bit complicated by the fact that you don't have a clean transmission line all the way to the am335x May 22 10:56:51 the expansion headers of the beaglebone aren't exactly made for high-speed signals. still, data is less critical than clock May 22 10:57:08 (w.r.t. timing) May 22 10:57:44 the high-z/low-C is because otherwise the adc experiences sudden jumps in current draw, which affects all the analog stuff May 22 10:58:33 even though they have separate supplies, that isolaton won't be perfect May 22 11:00:15 there are probably also ready-to-go clock cleaning chips May 22 11:01:53 don't forget to also pay attention to delays introduced... data still needs to arrive at the pru at the right time (relative to its clock) to be sampled cleanly May 22 11:02:32 alternatively you could use the parallel capture functionality to reduce the burden somewhat May 22 11:02:47 but this complicates code May 22 11:03:27 it would however allow for using an external clock generator May 22 11:05:54 how about using an external clock ? and pru in 16 bit parallel capture mode ? May 22 11:06:10 oh yes May 22 11:06:19 same. May 22 11:06:28 I was looking at the manual. May 22 11:06:32 pru manual May 22 11:06:50 complicate code, so as to detect the clock ? May 22 11:07:07 yeah I suppose it doesn't complicate much May 22 11:07:23 instead of instructions to generate the clock, you wait for the clock bit instead May 22 11:09:04 2 clock cycles for each check. to jump and and check. May 22 11:09:08 you could even put use a clocked buffer on your pcb, then the adc is basically fully connected to local components only May 22 11:09:13 no that's one instruction May 22 11:09:37 quick-branch does test and jump May 22 11:10:00 they even made wait-for-bit pseudo instructions (which are qbbs/qbbc under the hood) May 22 11:10:04 okay. May 22 11:10:16 only annoying part is that you need to make sure the clock went low before testing it's high again May 22 11:11:09 hi, I have a water flow sensor connected to a GPIO May 22 11:12:06 you could even go as far as putting a clocked buffer on your pcb to ensure the adc's stringent demands are met and hopefully prevent any crap from the BBB affecting it May 22 11:12:10 we will be sampling max at 20MHz May 22 11:12:15 I setup the GPIO to have a pull up using the device tree and I sense a level change when water is flowing May 22 11:12:26 ok, then the demands are getting much lower May 22 11:12:52 so that 1 clock cycle instruction will do i think May 22 11:12:56 I get an event when ever the sensor is triggered, and if I count 5 such events, 1 litter had flowed May 22 11:13:23 I want to graph the ammount of water flow. any advice? May 22 11:13:28 ZeekHuge: not really, there's a risk that if you can process the data quickly, the clock line is *still* high rather than high *again* May 22 11:14:14 I first tought of using a graphite setup, I will send to the carbon deamon the sesor triggers, and will use graphite to see the graph May 22 11:14:43 yep. so somewhat complicated code. May 22 11:14:46 ZeekHuge: using buffers to isolate the bbb however might be a good idea anyhow, since too heavily loading by the bbb (if it does, didn't check) or noise being coupled back from it can still affect the quality of your adc May 22 11:14:55 well no, two instructions May 22 11:15:04 wait for low; wait for high May 22 11:15:22 yep. May 22 11:15:29 got it. May 22 11:16:20 I see their demo board has a split ground plane... yikes May 22 11:16:35 the adc EVM has a buffer on the data side though. May 22 11:16:45 ah they do? :) May 22 11:17:24 so they're basically doing exactly what I suggested: isolate the adc from direct contact with the external digital stuff May 22 11:17:33 yep. May 22 11:17:42 So its the clock now. May 22 11:17:45 you can nicely control the impedance of a pcb trace May 22 11:18:00 but once you reach the expansion header of the bbb, all bets are off May 22 11:19:12 btw about the split ground plane... from everything I've ever read, while split planes *can* be beneficial in some cases if you really know what you're doing, they're also easy to mess up and just end up being big noise-antennas May 22 11:25:33 anyhow, I need to do stuff, good luck with your project May 22 11:26:36 yep. Thank you zmatt :) May 22 11:26:57 pay very close attention to signal integrity... having high-speed digital signals and high-speed sensitive analog stuff combined is certainly not making it an easy project :) May 22 11:27:25 * ZeekHuge This is becoming more frequent, that he is realizing that there is a lot lot lot lot lot of things to learn about. May 22 11:27:56 yeah. Will try my best, for sure. :) May 22 11:28:17 the basics of transmission line theory are definitely good to know in this and most other applications May 22 11:28:32 okay. May 22 11:28:59 like, when still though you needed to level-shift to 2V, do you have any idea how I calculated those resistor values? :) May 22 11:30:53 it also helps to remember something very basic about electronics that somehow people tend to forget again in digital logic May 22 11:31:04 that an electrical circuit is a closed loop May 22 11:31:57 that matters especially with high-frequency currents, where you want to minimize this loop area since it'll otherwise become an antenna May 22 11:33:18 hence the use of a solid ground plane below high-speed traces May 22 11:37:02 lot of interesting stuff here also -> http://speedingedge.com/home/related-articles/ although much of them concerning much much much higher speeds then you are May 22 14:41:46 I already know that beaglebone can be boot via usb, but is there any chance to boot a flash disk with bbb? May 22 14:46:10 I think you have it backwards. If you mean if the BBB can boot from a USB connected flash drive. "It depends". Not as first stage boot loader, but most certainly the rootfs can live on USB. May 22 14:46:30 SDIO connected flash of course works, it's called micro-SD cards May 22 14:46:45 also the BBB comes with a eMMC flash disk built in May 22 15:05:55 hey does anyone know if you can read multiple pins simultaneously on beagle May 22 15:06:23 im not an EE so idk if it's called parallel ports May 22 16:09:05 Guest83581: you can read all pins from the same gpio bank simultaneously May 22 16:09:24 (there are four gpio banks) May 22 16:10:47 @zmatt how May 22 16:10:48 also, all GPI of a pru core can be read simultaneously (by the pru core, or if it is halted then they can be read by other cores such as the cortex-a8 May 22 16:11:05 im using the pybbio lib May 22 16:12:09 well I normally directly access peripherals from userspace May 22 16:12:47 I noticed there are /dev/gpiochip* devices now too (at least in recent kernels), maybe those allow it too May 22 16:13:23 so have a external clock powering a 16bit counter, and i want to read 4bit of that counter output to beagleboard May 22 16:14:03 i just want to read the binary 1 and 0s from each pin May 22 16:14:17 how fast does the counter update? May 22 16:14:20 on regular mc you can do that with port and or it with stuff May 22 16:14:27 the clock is 5mhz May 22 16:14:33 you can do it like that on a BBB also May 22 16:14:36 bit 0 has freq of 2.5 mhz May 22 16:14:49 ya i couldnt find how to using python May 22 16:14:54 in both cases there's a hazard of reading the data inconsistently though May 22 16:15:00 why is that May 22 16:15:02 unless you specifically trigger on bit 0 change May 22 16:15:07 metastability May 22 16:15:15 ok. May 22 16:15:23 i thought it would just be high low high low May 22 16:15:23 basically the chip might sample the values exactly when they're changing May 22 16:16:01 thats the part im testing, i want to see how fast beagle can sample, my project require a specific sampling speed May 22 16:16:31 PRU samples at 200 MHz May 22 16:16:40 im going to adjust the pin im reading until it matches cpu speed., bit 0 is 2.5mhz, bit 1 is 1.25, so on May 22 16:17:05 so the 5 mhz might be too slow? May 22 16:17:21 do i need a faster clock May 22 16:18:27 I used a simple test where a PRU program just copied an input to an output... with synchronization delays and internal propagation combined the total delay was iirc about 25 nanoseconds May 22 16:18:58 do you mind sharing how you did it May 22 16:19:17 my advisor needs to see the process before they trust it May 22 16:20:38 just ran a PRU program that did nothing but copy a GPI to a GPO (so I probably did something like LSL r30, r31, 1 May 22 16:20:54 didn't even bother with a loop, I just filled its entirely IRAM with that instruction May 22 16:20:59 *entire May 22 16:21:51 then connected a clock signal to that input (I used the 24.576 MHz audio clock since it's not at all synchronous to the PRU) and measured input and output simultaneously on a scope May 22 16:24:06 I think the range was 20-25 ... I should have recorded it properly but it was just a quick test May 22 16:24:08 idk anything about pru programs do you have a good tutorial or anything you can direct me to May 22 16:25:10 PRU's documentation unfortunately seems to be in a messy state, with multiple versions of the reference guide which largely overlap yes all of them have some stuff that's not in the other ones May 22 16:25:22 the instruction set is mostly quite simple and clean though May 22 16:26:03 as is the instruction timing: any instruction other than load/store (or "halt" of course) takes exactly 1 cycle May 22 16:26:45 any reference link you can share? May 22 16:27:02 https://github.com/beagleboard/am335x_pru_package May 22 16:27:05 for example May 22 16:27:07 sorry im completely clueless on this, dont even know what to look May 22 16:27:53 beware that there are two competing kernel mechanisms for loading pru code... remoteproc and uio_pruss May 22 16:28:06 the latter is older and far more widely supported by tools and tutorials May 22 16:28:23 the former however is default in 4.1-ti series kernels May 22 16:28:33 how do you change it May 22 16:29:43 I'd suggest switching to a -bone kernel unless you need specific stuff that's only in the -ti version May 22 16:30:50 PRU is the only place where you can get deterministic timing basically May 22 16:32:06 my project requires me to collect data at a .6mhz rate and time tag them as they come in with micro sec acuracy, we are trying to figure out if beagle is capable of it May 22 16:32:38 from a hardware point of view, easily May 22 16:32:45 software? May 22 16:34:42 depends. the actual data reception needs to be handled by DMA or PRU May 22 16:35:14 whats dma May 22 16:35:16 what do you mean by time tag it btw? I mean, if it's collected at a fixed rate you know the timing simply by counting the samples May 22 16:35:27 they wont come in at a fixed rate May 22 16:35:31 we need to know when they come in May 22 16:35:40 the peak is 6mhz is what im told May 22 16:35:47 what exactly is the data format? May 22 16:36:05 / protocol May 22 16:36:20 just 8bit binary data May 22 16:36:50 or 4, they werent specific or sure about it. May 22 16:36:57 so, 6 MHz is not much per se... I've done 16-channel 32-bit audio streaming at 48 kHz sample rate, that's 24 MHz May 22 16:37:26 but there all low-level details are handled by the audio peripheral (McASP) May 22 16:37:44 which also pokes the DMA controller (EDMA) to transfer the data from or to memory May 22 16:38:00 basically the counter i connected to beagleboard will simulate data coming in May 22 16:38:20 linux therefore only needs to deal relatively infrequently with chunks of data May 22 16:38:59 but you said "they wont come in at a fixed rate"... that suggests there's something that indicates when data is valid or something May 22 16:39:20 there's apparently a protocol, perhaps something simple but that's still a protocol May 22 16:39:25 its more like trigger May 22 16:39:36 ok so you have data + trigger ? May 22 16:39:37 how beagle x15 is different from this board? http://www.ti.com/tool/TMDSEVM572X#1 May 22 16:39:41 it looks exactly the same May 22 16:40:15 price seems somewhat different May 22 16:40:38 mrx1_: the development of the x15 was closely tied to that of the evm572x... except the evm572x has an additional board that plugs into the expansion headers May 22 16:40:57 including touchscreen May 22 16:41:01 the apparatus that will detect when the event happens and, ideally beagle should get those data as they happen May 22 16:41:04 they dont always happen May 22 16:41:21 but they could have a peak time when we require high sampling rate May 22 16:41:24 zmatt: ok, thx May 22 16:41:54 Rickta59: and what is the price of x15? May 22 16:42:11 Guest83581: so to confirm, you have data + a capture trigger? May 22 16:42:15 sorry I just saw the price on that board and didn't know there was a new x15 beagle May 22 16:42:21 i don't know May 22 16:42:37 yes May 22 16:43:38 Guest83581: the data is synchronous to that trigger then I presume/hope May 22 16:43:41 ? May 22 16:44:14 yes May 22 16:44:20 im not sure since the other team is building that May 22 16:44:47 what are you doing with all this collected data? Guest83581 May 22 16:44:48 Guest83581: well it better be since otherwise data transfer is inherently subject to race conditions May 22 16:45:00 Guest83581: PRU has a 16-bit parallel capture mode May 22 16:45:02 its a research project May 22 16:45:15 cant really reveal too much export controlled and all that May 22 16:45:30 i mean are you writing to a network .. storing it in memory for a short period of time .. writing to disk May 22 16:45:47 storing it in memory until we can dump it May 22 16:45:50 Guest83581: so it'll sample the data lines on the configured edge of the trigger line May 22 16:45:55 we only do data dump at specific interval May 22 16:46:16 thus ensuring a consistent data snapshot May 22 16:47:28 zmatt do you have an email you dont mind sharing so i can contact you outside the chat room for help if you dont mind May 22 16:47:29 the amount of PRU code needed would be tiny May 22 16:48:45 I do mind, I'm not your personal assistant. public discussion helps to allow others to pick up and/or contribute knowledge as well May 22 16:49:19 and consider setting an actual nickname, using /nick desirednick May 22 16:49:38 note that this is a big irc network, so many nicknames (especially short/simple ones) may be taken already May 22 16:49:58 ok thanks May 22 16:51:03 thanks for all the help, at least now i know what direction to look May 22 16:51:12 i was completely clueless May 22 16:51:23 you could probably also have this done by EDMA (there are external DMA request lines, and EDMA can read from the input register of a gpio bank and write that to memory) May 22 16:51:37 but it wouldn't achieve the performance PRU could May 22 16:51:50 mostly limited by the roundtrip time for reading the GPIO May 22 16:52:21 so if we just want to collect data and add few time tagging bits PRU would be better May 22 16:53:54 yes May 22 16:54:41 the pru subsystem timer modules you can use as source for timestamps May 22 16:55:57 btw, about python... I've actually been working on code that makes it easier to access peripheral directly (like you would on an MCU) from python code May 22 16:56:41 I'm not actually experienced python programmer, I normally do such stuff in C/C++, but it seemed an interesting thing to do to make it more accessible to a wider audience :) May 22 16:56:59 https://github.com/mvduin/py-uio still in a fairly early stage though May 22 16:57:41 qep-test is probably the best example currently, although you need external hardware to be able to actually test it May 22 16:58:48 awesome ill take a look at it, i have to go now thank you so much for all the info May 22 16:59:05 our advisor recently changed from mc to beagle and we know nothing about beagle May 22 16:59:06 the low-latency needs you have however exclude doing this from linux, let alone from python :) May 22 16:59:43 well you *can* also use the am335x just like a microcontroller May 22 17:00:18 I have a fair amount of baremetal C++ code, which unfortunately I'm not allowed to release May 22 17:00:57 I do have this tiny example written in pure assembly which also explains various ways of getting your program onto the BBB: https://github.com/mvduin/bbb-asm-demo May 22 17:01:42 and some of my baremetal headers can be found here: https://github.com/dutchanddutch/jbang/tree/master/include May 22 17:02:25 there's a scarcity of good examples though May 22 17:02:40 how do you run c++ in bbb May 22 17:02:54 i mean where do i find the header file referrences and all that May 22 17:03:14 what do you mean? May 22 17:03:34 like whats the name of this port and stuff May 22 17:04:03 on msp430 launchpad you do stuff on the code composer May 22 17:04:15 on bbb do you just run the c++ on terminal? May 22 17:04:43 linux C/C++ applications can be compiled natively or cross-compiled May 22 17:04:53 baremetal applications are obviously cross-compiled May 22 17:05:00 cross-compiling is much faster anyhow May 22 17:05:19 on debian there are ready-made cross-compiler packages, so you just install those then you're done May 22 17:05:20 ill look that up May 22 17:06:02 as for register maps and such, I still make those by hand whenever I need them. usually they start out as a way to take notes while I read the docs and try to understand the peripheral, and then expand from there May 22 17:06:23 like I said, some of my headers can be found in https://github.com/dutchanddutch/jbang/tree/master/include May 22 17:06:50 e.g. the Power, Reset and Clock Manager: https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h May 22 17:07:34 beware that I write a slightly eccentric dialect of very modern C++ (requires gcc 5) May 22 17:07:37 :) May 22 17:09:47 thank you again, big help! May 22 17:09:57 have a great day ill prob be back May 22 17:37:16 ah, these /dev/gpiochip* devices are already very useful indeed May 22 17:38:00 you can use them to obtain information about the gpios... basically the a subset of what you can already get via debugfs :P May 22 17:53:23 How can I tell if my gpio pins are working properly? I cn no longer get am2302 temp/humidity readings after powering am2302 from external 5V supply. May 22 17:54:28 the BBB is _not_ 5V compatible May 22 17:55:09 try reading the pin(s) affected in input mode (e.g. by exporting via sysfs) May 22 17:55:38 use a resistor (say 100 ohm - 10K) to try to pull the line up or down May 22 17:55:59 see if this affects the value read from the pin May 22 17:56:41 a common consequence of overvoltage damage is that an integrated esd protection diode turns into a short-circuit to ground or vdd May 22 17:57:39 in which case the value read will obviously be stuck at that level May 22 17:57:53 I am a little confused as I used an external power source to the am2302 and had only the data feed connected to the gpio pin P8_11. May 22 17:58:27 yes, that's already a bad idea even if the supply had the right voltage May 22 17:59:35 you should have used the 3.3V supply of the beaglebone itself (P9 pins 3-4) May 22 17:59:36 Is there a good way to check if I damaged the gpio pin P8_11 or others gpio pins? May 22 17:59:49 there is, I just explained it May 22 17:59:57 in fair detail May 22 18:00:46 instead of using external resistor it is also possible to toggle the internal one, but there's no easy way to do so in linux, so using an external resistor is probably easiest May 22 18:01:06 Orry Matt, I was typing in a response before I saw your complete answer. I will try that. May 22 18:03:57 first thing I tried when I started to play with the Beaglebone May 22 18:04:52 JK_: viewing the state of pins (as seen by linux) can btw also be done nicely done with my pin utility: http://gerbil.xs4all.nl/show-pins-v3.pl.tgz May 22 18:05:02 I originally used the 3.3V beaglebone supply and it was working fine. I tried external supply, as I was going to add two sensors and additional items later. I though I would test off-loading some of the draw from the beaglebone. May 22 18:05:16 ( pipe output though sort to get it sorted by expansion header pin) May 22 18:05:32 JK_: the datasheet seems to suggest the sensors don't draw much power May 22 18:06:14 we are powering everything over the BBB - except the motors May 22 18:06:19 works fine May 22 18:07:15 in any case, it's absolutely forbidden to apply a voltage to an I/O pin that exceeds the supply voltage by more than 0.3 V or so May 22 18:07:46 the supply voltage being 3.3V for most pins, 1.8V for the ADC inputs, and if the BBB is off then it's 0V for all pins May 22 18:08:32 the only exception basically is the serial debug port, which has an isolation buffer May 22 18:10:18 As a beaglebone nubie, I read the am2302 as supplying only 1-1.5mA to the data I/O pin. May 22 18:10:50 I suppose this means I need a new beaglebone due to the damaged header? May 22 18:11:27 have you confirmed yet whether the pins are indeed damaged? May 22 18:11:40 Not yet, i will check that shortly May 22 18:13:32 actually, the datasheet doesn't specify much about the I/O driver May 22 18:13:47 in fact, they specify no electrical characteristics of the I/O driver at all May 22 18:15:28 a weak pull-up reduces the chance the bbb would get damaged since current will flow through internal protection diodes hence reduce the voltage on the line... but it's not guaranteed this is sufficient to prevent the voltage from exceeding absolute maximum ratings May 22 18:16:27 on https://cdn-shop.adafruit.com/datasheets/Digital+humidity+and+temperature+sensor+AM2302.pdf I read current supply measuring as 1-1.5mA as the data I/O current May 22 18:16:28 (the protection diodes are mainly meant for esd protection) May 22 18:16:52 afaik that's the current drawn during a measurement May 22 18:16:58 there's no communication at al during a measurement May 22 18:19:25 I have a lot to learn as a nubie here. I have managed a lot of IT systems, but not at the hardware interface/electrical level May 22 18:20:09 yes, it would definitely be useful to have a CAPE dedicated to providing highly abuse-resistant I/O May 22 18:20:45 the expansion header pins on the BBB connect directly to the processor pins... which reduces the complexity and price of the bbb and is good for high-speed stuff May 22 18:21:43 Is there a recommend cape that provides that? May 22 18:22:04 but the am335x is a fairly modern cpu fabricated on 45nm technology... a small mistake can easily damage it as a result May 22 18:22:38 unfortunately, although the usefulness of such a thing is discussed here with some frequency, none is available yet as far as I know May 22 18:24:00 Thank you zmatt for your wisdom. I will try your suggestion to check the pin. May 22 18:24:02 it helps a lot to just stick to the rule of powering external stuff from the BBB's own 3.3V supplies (or 1.8V for stuff connecting to the adc) May 22 18:24:32 otherwise you're creating another power domain and signals crossing between them, and that's always tricky May 22 18:25:46 My project will eventually entail objects with 12V. I assume I will need to use a 3.3v switch to ensure the power does not feed back to the header? May 22 18:26:12 IE. like a typical thermostat does May 22 18:26:32 you can amplify outputs of the BBB of course May 22 18:26:49 e.g. with a FET May 22 18:28:53 I will look into that. May 22 18:29:04 12V -> device -> -> GND May 22 18:29:11 with BBB connecting to base of the N-FET May 22 18:29:32 wait, I might have source/drain wrong way around May 22 18:29:38 I do May 22 18:30:09 makes sense, since it drains the current flowing from the device May 22 18:46:25 I have done the following: root@beaglebone:/sys/class/gpio# echo 45 > export root@beaglebone:/sys/class/gpio/gpio45# echo in > direction root@beaglebone:/sys/class/gpio/gpio45# cat value 1 Should I now connect a 100ohm resistor between P9_3 and P8_11? May 22 18:46:50 no, to ground May 22 18:47:04 then check whether value then reads as 0 May 22 18:47:34 So P9_2 and P8_11? May 22 18:47:57 better to test them one at the time May 22 18:48:28 Not sure I understand. May 22 18:48:44 P9_2 is gnd May 22 18:48:49 oh May 22 18:49:35 call gnd "gnd", if I see "P9_something" I assume you were talking about some I/O... I didn't look closely enough to notice it was a ground pin May 22 18:50:09 Ah. OK May 22 18:50:33 looking for resistor now May 22 19:00:39 using 5500 ohm resistor, it looks like it still reads 1 May 22 19:01:16 just to check: you have nothing else connected to the pin right? May 22 19:02:06 nothing else connected May 22 19:02:25 5500 should have no trouble pulling a line to logic-low May 22 19:02:55 so it seems you did indeed fry the pin (most likely the internal esd diode from the pin to vdd) May 22 19:03:25 So maybe i should check another pin? May 22 19:04:12 yeah lucky enough you apparently only killed one pin instead of the whole processor May 22 19:08:20 How do I unexport? May 22 19:08:34 echo 45 > unexport May 22 19:10:02 duh. I used echo gpio45 > unexport. LOL May 22 19:19:15 OK. When I use P8_9 (gpio69) it toggles between o connected and 1 disconnected May 22 19:28:42 that would be normal behaviour for a pin that has internal pull-up enabled May 22 19:29:29 (the utility I linked to earlier shows how internal pulls are configured; you can also find the reset-default values in my spreadsheet @ https://goo.gl/Jkcg0w ) May 22 20:06:12 Now when I connect to gpio69 (P8_9) there is no error, but there is no data pulled either when using the am2302 python script May 22 20:20:53 the python script for reading temp/humidity from DHT22/am2302 works when I export pin May 22 22:01:59 hi there, what's the current state of power management on the beaglebone black? May 22 22:03:06 my research indicates that the mainline kernel doens't even have a cpuidle driver for the am33xx soc, so the soc always burns maximum power May 22 22:03:15 or did I miss something? May 22 22:11:28 sidreams: running 4.5.x i've got the cpufreq_dt module loaded May 22 22:12:02 last i looked, it drew maybe 1-2 watts May 22 22:12:17 though i haven't tried it under heavy loads May 22 22:12:17 does this change depending on cpu load? May 22 22:13:05 i've been wondering, because I couldn't find the driver specific to the am33xx soc May 22 22:14:46 seems like only ti's fork seems to do pm properly May 22 22:15:04 unfortunately, it's really outdated (3 years old) May 23 01:52:39 hello everyone,my tpm_tools hasn't tpm_bind,what should I do May 23 02:12:23 yer what who **** ENDING LOGGING AT Mon May 23 02:59:58 2016