**** BEGIN LOGGING AT Fri Jul 07 03:00:03 2017 Jul 07 03:04:02 I'm not sure if I ever tried openocd with the am335x Jul 07 03:05:05 I have used openocd with xds100v2, and I've jtagged a BBB, just not sure if I've done both at the same time :) Jul 07 03:07:32 hrm Jul 07 03:07:38 ever heard of a "bus blaster" Jul 07 03:07:46 vaguely Jul 07 03:08:05 im trying to use it to do...something Jul 07 03:08:08 anything Jul 07 03:09:41 does its led turn on? Jul 07 03:10:10 no because our libusb sucks Jul 07 03:10:21 im implementing openbsd_handle_events() right now... Jul 07 03:10:45 you paid $80 for it? it says here it's $35 Jul 07 03:10:56 where Jul 07 03:11:11 https://www.seeedstudio.com/bus-blaster-v3-p-1415.html?cPath=63_69 Jul 07 03:14:47 oh no Jul 07 03:14:50 this is the bus blaster Jul 07 03:14:54 i paid about 35 for this Jul 07 03:15:03 the TI specific am335x jtag debugging cable Jul 07 03:15:07 the one that plugs into the weird header Jul 07 03:15:42 something something blackhawk Jul 07 03:16:05 an xds100v2 probably Jul 07 03:16:22 looks like the bus blaster v3 is pretty much identical hw Jul 07 03:16:36 neat Jul 07 03:16:39 even the same cpld Jul 07 03:18:29 great Jul 07 03:18:46 i'm so glad that almost all of the real engineering work has been solved and is available to immediately help me with my goal Jul 07 03:18:47 but of course Jul 07 03:19:02 probably if the bus blaster's cpld is suitably programmed and the vid/pid of the xds100v2 is programmed into the FT2232H's EEPROM then even TI's CCS would work with it :) Jul 07 03:19:11 software stands unflinching Jul 07 03:22:07 hah, "This project was inspired by a forum post that linked to a Texas Instruments' XDS100 programmer" Jul 07 03:22:21 well that explains :) Jul 07 03:22:31 geez Jul 07 03:22:34 arent i lucky Jul 07 03:24:10 although the bus blaster guys apparently didn't think it was relevant to include the series resistors for impedance matching Jul 07 03:24:38 pfft Jul 07 03:24:38 ew, and they power the I/O bank directly from V_TARGET instead of using a voltage follower Jul 07 03:24:45 what's the max baud on usb2.0 Jul 07 03:24:47 you're not supposed to draw any power from V_TARGET Jul 07 03:25:15 the throughput of usb is not a limiting factor here Jul 07 03:25:17 its latency is Jul 07 03:25:27 im kidding Jul 07 03:25:40 along with the general crappiness of the FT2232H for JTAG Jul 07 03:26:27 ftdi, lol Jul 07 03:26:44 i'd only think folks'd use it for...serial terminal text transfer Jul 07 03:27:07 it has a synchronous serial / bitbang protocol engine thingy Jul 07 03:27:34 the command set thereof is however not particularly well suited to jtag Jul 07 03:28:04 aye Jul 07 03:28:40 so you end up having to chop up each jtag transfer in an awkward way, and each command to the mpsse (that's the name of the engine) has some overhead where the engine is thinking and therefore the bus is idle Jul 07 03:29:13 at low speeds you won't notice it much, but at the max speed it results in like 50% bus idle when spamming non-stop commands Jul 07 03:30:42 ic Jul 07 03:33:29 pru would probably be awesome at doing jtag Jul 07 03:33:52 what does determinism/hard time guarantees buy you? Jul 07 03:36:01 determinism lets you bitbang the protocol, and most important pru's i/o is extremely low latency Jul 07 03:36:10 ah Jul 07 03:36:13 haha Jul 07 03:36:16 is it even really bit banging at that point Jul 07 03:36:24 yes Jul 07 03:37:10 the latency is also quite important since jtag debugging typically involves lots of small transfers, which can't always be pipelined Jul 07 03:37:32 ah Jul 07 04:53:37 hi Jul 07 04:53:50 I want to ask Jul 07 04:53:58 can I use http://www.ebay.com/itm/XDS100-XDS100V2-JTAG-Emulator-debugger-TI-DSP-ARM9-Cortex-A8-TMS320-CCS4-CCS5X-/291674940747?hash=item43e92e654b:g:S~QAAOSw3ydVvXl2 Jul 07 04:54:04 for jtag debug for BBB? Jul 07 04:58:10 hi Jul 07 04:58:16 I want to ask u a little bit Jul 07 04:58:53 hi Jul 07 04:58:57 calculus Jul 07 14:42:59 hi, I am powering my beaglebone black with a USB battery pack. I would like to be able to send a notification when the battery is getting close to empty. is it possible to measure the voltage being supplied to the usb drive somehow? Jul 07 14:44:46 spuz: you can modify a BBB to directly work from LiIon cells, with full charge control etc Jul 07 14:46:08 regarding your original question. It would not be hard to set up a voltage divider to feed VBus to the BBB ADC Jul 07 14:49:38 yeah i guess that would work Jul 07 14:49:47 i wonder if i have the bits to make a voltage divider Jul 07 14:52:14 You just need a couple resistors. Jul 07 14:53:48 tbr's suggestion to crack open your battery pack only works if it is a single cell batt Jul 07 14:54:31 you can use several cells in parallel if they are not terribly mismatched Jul 07 14:57:10 well the battery i want to hook up is just an 13000mah anker power pack. i figure i'll use that because it can deliver 5 volts which is enough to power the usb wifi plus it is large enough to last a good while Jul 07 14:58:41 Yeah, that has more than one cell. (The bone will handle boosting the voltage if you integrate the 3.7v cell directly) Jul 07 14:58:49 Go with the voltage divider. Jul 07 15:30:56 Hey guys. PRU programming question. I know the TI XDS100 XDS100V2 (https://store.ti.com/TMDSEMU100V2U-20T-XDS100v2-JTAG-Debug-Probe-20-pin-cTI-version-P1848.aspx) is what is called for. Jul 07 15:31:18 However does anyone know if this would work: http://www.ebay.com/itm/291674940747 Jul 07 15:31:47 Try do mention A8 support. But not this ARM specifically. Jul 07 15:32:13 Or Flyswatter2: http://www.tincantools.com/JTAG/Flyswatter2.html Jul 07 15:32:20 Although that's a lot more. Jul 07 15:32:27 Any thoughts or feedback? Jul 07 15:59:15 Note: TI programer is only one that lets you use TI's Code Composer Studio for free. Jul 07 16:34:35 spuz: an usb battery pack will actually take care to output 5V as long as it is able to and then turn off, so there's no forewarning unless you're ready for some hardware hacking Jul 07 16:36:12 Gansemarsch: the bone has no integrated boost converter. if you power it from a li-ion cell (which actually also requires a hw patch if you want to be able to power off safely without disconnecting the battery due to hw bug) then "sys_5v" will actually be at battery voltage and the usb host port will not function Jul 07 16:37:27 the usb host port is the only loss of functionality however, everything else uses 3.3v or lower Jul 07 16:37:57 see also http://elinux.org/BeagleBone_Power_Management#Battery Jul 07 16:41:49 be very cautious about measuring a battery voltage with adc. you're not allowed to connect a nonzero voltage to an adc input whenever the bbb is powered off Jul 07 16:42:43 you may be able to get away with a series resistor and a schottky diode to vdd_adc Jul 07 16:45:01 oh right, the hdmi 5v output would also be affected by the lowered sys_5v, not sure if that matters in practice Jul 07 18:37:38 What voltage does the beaglebone run on? Jul 07 18:37:54 Is there a linear regulator on board to take it to 3.3 or something? Jul 07 18:38:10 perhaps even a mini smps? Jul 07 18:40:31 I have a idea of using a beagle as my everyday PC in a off-grid remote area. Jul 07 18:41:19 it typically uses 5v Jul 07 18:41:54 er, beaglebone black uses 5v, not 100% sure on earlier beaglebone boards Jul 07 18:42:13 phinxy, http://www.ti.com/product/TPS65217 Jul 07 18:43:44 georgem, Thats a battery charger Jul 07 18:43:53 its not whats in the beagle , is it? Jul 07 18:44:02 phinxy: yes. that's what provides power Jul 07 18:44:24 well... I think the USB power is provided by the 5v input Jul 07 18:44:36 look at the schematic for details Jul 07 18:51:19 Seems like it can be powered by a single cell LiIon Jul 07 18:51:33 And perhaps even charge it Jul 07 18:58:07 Very appealing board Jul 07 18:58:21 How soon will the 1GB RAM edition come? Jul 07 19:02:28 phinxy: re liIon cell. IIRC there is nothing to provide power to the USB ports if you do that. Jul 07 19:03:27 https://www.indiegogo.com/projects/sancloud-beaglebone-enhanced#/ Jul 07 19:03:37 A naive answer would be in about $24,000 Jul 07 19:04:01 But reality often makes things take longer and take more expense Jul 07 19:44:28 phinxy: http://elinux.org/BeagleBone_Power_Management Jul 07 19:45:23 phinxy: there's a power management IC which contains 3 smps and 4 ldo's Jul 07 19:46:09 there's also a separate ldo for additional 3.3V power Jul 07 19:49:34 phinxy: the "beaglebone enhanced" has 1GB of ram, but it's not clear if they're actually available Jul 07 19:51:05 still haven't played much with mine :/ Jul 07 20:27:34 can you boot beaglebone without any blob unlike the pi? Jul 07 20:28:05 yes Jul 07 20:31:09 the pi has mandatory binary drivers? Jul 07 20:39:20 guru_: https://github.com/christinaa/rpi-open-firmware Jul 07 20:42:35 agraf`: seems like a massive WIP Jul 07 20:42:40 yu Jul 07 20:42:41 yup Jul 07 20:42:49 is the same true for beagle? Jul 07 20:42:54 no, on beagle it's all stable Jul 07 20:43:19 it's probably one of the most stable and upstream best supported arm platforms I've seen out there Jul 07 20:43:28 but it's a terrible target if you want to do anything GPU related Jul 07 20:43:36 and it's quite bad for anything that needs CPU power Jul 07 20:44:00 if you want to drive I/O - maybe even using the amazing PRUs - then it's the best you can get Jul 07 20:44:10 unless you want to drive fast I/O - then it's bad too :) Jul 07 20:45:30 that's fine long as there's no binary blobs Jul 07 20:46:00 yeah, the only binary blob on beagle that I'm aware of would be the PowerVR drivers Jul 07 20:46:08 and I surely hope you don't want to touch that anyway ;) Jul 07 20:46:31 nope Jul 07 20:46:33 ;P Jul 07 20:47:25 VPU side bootloader? why is that relevant? I mean, I get why it would be nice to have that open source, but then there's still a closed-source ROM bootloader before that Jul 07 20:47:31 (which is true for every SoC I know of) Jul 07 20:53:54 there's no decent platform that's entirely open, and given the resources needed to design and produce a modern SoC that's also not likely to change any time soon. when comparing platforms based on this you should review which parts are open and which are not, and what that means practically Jul 07 20:59:29 agraf`: the cortex-a8 isn't that bad.... software is just bloated and slow ;P Jul 07 21:00:53 zmatt: because the VPU on the RPI is what initializes the CPU. Jul 07 21:00:56 agraf`: "unless you want to drive fast I/O - then it's bad too" ... ehh sorry what? the only thing I know of that can compete with PRU would be an FPGA Jul 07 21:01:01 vagrantc: I'm fully aware of that Jul 07 21:01:02 zmatt: WTF is expected Jul 07 21:01:43 vagrantc: the rpi is a VideoCore processor with an ARM subsystem glued onto its side, not an ARM processor with a GPU Jul 07 21:02:00 zmatt: ok, i guess i was responding why it was relevent Jul 07 21:02:19 that doesn't change the fact that once the ARM core is up then linux completely takes over on the ARM side Jul 07 21:02:44 some people want to push the openness of the stack back as far as they can Jul 07 21:02:48 i guess that's all Jul 07 21:03:27 I can understand that, but as I pointed out it's just a difference of degree of openness: on both the rpi and the bbb there's ultimately still a closed-source bootrom Jul 07 21:03:31 Will Beagle Enhanced come with the "3v3 regulator bug" fixed? ie. a revisited PCB Jul 07 21:04:01 phinxy: the BBE is a heavily modified BBB-derivative Jul 07 21:04:18 zmatt: sure Jul 07 21:05:06 phinxy: I'm not sure if it has the same issue at all, I'd need to dig into its schematics Jul 07 21:07:09 agraf`: see e.g. BeagleLogic, a 14-channel 100Msps logic analyzer implemented using PRU. does that not qualify as fast i/o ? :P Jul 07 21:07:22 I will try contact sancloud and ask if it is possible to get hands on a test batch BBE Jul 07 21:25:20 What clock is the external micro running at? Jul 07 21:25:27 how fast can the gpio be toggled on off? Jul 07 21:26:38 Is there hardware SPI on it? Jul 07 21:26:48 RISC? Jul 07 21:26:52 what external micro? Jul 07 21:27:15 you mean the pru cores? they're not external, they're part of the SoC Jul 07 21:28:04 Ah. thats neat. Not many ARM cores has this functionality? Jul 07 21:28:25 not many SoCs you mean... Jul 07 21:28:36 Doesnt ARM apply? Jul 07 21:29:02 ARM has nothing to do with it, the PRU core is a design by TI Jul 07 21:29:31 So the SoC contains ARM plus something owned by TI Jul 07 21:29:33 the SoC contains an ARM Cortex-A8 core (the main cpu), two PRU cores, and a cortex-M3 used for power management Jul 07 21:29:43 plus a GPU and a ton of peripherals Jul 07 21:29:54 Who decided on this mix Jul 07 21:29:56 TI Jul 07 21:30:18 TI didnt create this SoC just for beagle did they? Jul 07 21:30:24 of course not Jul 07 21:30:41 it targets industrial and automotive applications Jul 07 21:30:44 mainly Jul 07 21:31:49 for details on what's in the SoC, see its TRM => http://www.ti.com/lit/pdf/spruh73 Jul 07 21:34:25 other documentation can be found here => http://www.ti.com/product/AM3358/technicaldocuments Jul 07 21:51:26 uhhhhh wtf Jul 07 21:51:56 * zmatt just looked at what the 3v3 situation is on the BBE Jul 07 21:52:35 they actually managed to make it much worse Jul 07 21:57:01 I do like that they used an smps instead of an ldo Jul 07 22:00:36 just get rid of that slave rail Jul 07 22:00:54 they used vsys as enable -.- Jul 07 22:20:12 Isnt 8kb instruction ram + 8kb data ram a limitation on the PRUs Jul 07 22:20:37 mainly the instruction ram Jul 07 22:21:48 there are actually three data rams in the PRU subsystem (8K + 8K + 12K) and both cores can access all of them. they can also access external ram, albeit at a severe performance penalty Jul 07 22:22:40 then again you'd be surprised how much you can still do within those limits :) Jul 07 22:25:49 the small size of the instruction ram is probably also because it needs to have extremely low access time Jul 07 22:26:56 (to support operating the non-pipelined PRU core at 200 MHz) Jul 07 22:27:28 i often think about the PRU Jul 07 22:28:16 I've finally started working on a nicer lib for working with pru via uio Jul 07 22:29:46 (libprussdrv is pretty awful) Jul 07 22:29:52 yes Jul 07 22:45:33 ds2: on the BBE they tied P9.05 and P9.06 to usb_5v instead of the 5v dc jack ... o.O Jul 07 22:45:40 wth Jul 07 22:45:42 beagleboard.org "Blitter Bike" URL links to a polish 404 or something Jul 07 22:45:53 blitter bike? Jul 07 22:56:24 phinxy: btw, if you're considering running on battery, it may also be worth considering that the BBE almost certainly consumes significantly more power Jul 07 22:56:35 compared with the BBB Jul 07 23:14:27 or perhaps the BeagleBoard-X15! Jul 07 23:14:50 now you're talking power-hungry! :) Jul 07 23:16:45 i think the x15 was drawing maybe 7-9 watts under load a moderate load Jul 07 23:38:24 nice, latest TRM includes more details about IEP in PRUSS Jul 07 23:45:49 What makes them industrial? :) Jul 07 23:46:12 Are they robust and well built? Jul 07 23:46:19 hmm? Jul 07 23:46:39 IEP = Ethernet on the PRU (microcontroller in ARM) ? Jul 07 23:47:16 IEP is a peripheral in PRUSS that's basically just a bag of miscellaneous stuff they needed for EtherCAT functionality Jul 07 23:47:45 EtherCAT isn't supported on the BBB, but the functionality of IEP is also useful for purposes unrelated to ethercat Jul 07 23:48:57 How is the data sent with EtherCAT different from say a standard 100Mbps line between a router and a pc Jul 07 23:49:06 see wikipedia Jul 07 23:50:30 You can tunnel regular TCP/Iåp trough the EtherCAT unaffected Jul 07 23:52:04 apparently you can tunnel ethernet inside ethercat... not sure why you'd want to though Jul 07 23:55:04 anyway, ethercat is used for industrial automation, which is where the "industrial" comes from Jul 07 23:56:31 (for more info see also http://www.ti.com/lit/wp/spry187e/spry187e.pdf ) **** ENDING LOGGING AT Sat Jul 08 03:00:00 2017