**** BEGIN LOGGING AT Wed Nov 25 03:00:55 2015 Nov 25 03:00:59 the actual ground pins are physically "separate" but are all connected with wires so it should be one ground. Nov 25 03:01:50 yyyeaahhsorta... especially when dealing with fast high-current transients, it matters a lot how *exactly* things are grounded Nov 25 03:02:04 also, is either the UPS or the BBB also grounded in another way? Nov 25 03:02:27 (in other words, do you have a ground loop?) Nov 25 03:02:44 No. Like I said literally every ground is connected is connected in someway back to one singular point. Nov 25 03:02:51 I have my bot in front of me. You need a ground for each motor controller. Nov 25 03:03:10 Set up two grounds, one for each motor controller. Nov 25 03:03:11 Mountainman: ok, star topology of grounding is generally a good thing Nov 25 03:03:57 I cannot believe you made your own motor controllers. That must have been a pain. Nov 25 03:04:38 Soldering, coding, and assembly could make anyone go bonkers. Nov 25 03:06:38 Set: the 298 motor driver IC only has 1 gnd which is connected to every other ground. And honestly it was not very hard. Just 2n2222 bjt, with motor connected to collector, pwm into base, vcc between emitter and collecter. As Pwm is high current can pass emitter to collector. But it kept burning out the bjt so I swapped it for the lm298. Essentially the same thing. Nov 25 03:07:01 Mountainman: why the bjt? Nov 25 03:07:23 ahh Nov 25 03:07:24 nm Nov 25 03:07:28 should have finished reading Nov 25 03:07:48 kept burning out the bjt... so we are talking some serious currents here Nov 25 03:09:15 yea... the load motor is a 12v and the driving motor is a 6v. They are in gearboxs but the torque needed to actually turn the load motor means substantial current draw. Nothing ridiculous but a few amps at least. Nov 25 03:09:24 Damn! Nov 25 03:09:40 I hope you used some thick wires Nov 25 03:10:04 Oh yes. 18 gauge Nov 25 03:10:30 12VDC. Yikes! Nov 25 03:10:46 I must say I'm starting to lean more and more towards ds2's suggestion of using optocouplers for the pwm control signals Nov 25 03:10:46 Is this a enormous bot? Nov 25 03:11:27 especially if you want to be able to read back the sense values via the adc... which is gonna be fun indeed Nov 25 03:11:40 a.k.a hammer thrower? Nov 25 03:12:49 haha Set it actually isnt a robot. It is sort of a small scale version of larger industrial device meant to be a learning tool for system integration and embedded systems. Nov 25 03:13:04 Cool man. Nov 25 03:14:10 I am only using a quadruple set of 1.5v AA batteries for my one motor controller. I have two motors and two motor controllers. Nov 25 03:14:16 without that second part, I would say: make sure the wire between pin 8 of the l298 (which seems to be the signal ground) and the BBB does not share a common segment with the ground for the motor outputs (i.e. different branches of the star), and keep that ground (from pin 8 of the l298) and the pwm signals closely together to the BBB Nov 25 03:14:44 zmatt: I feel like the optocouplers would just make things more difficult. If there is not direct connection i feel like it would be more susceptible to emi and such. Plus wouldnt there be accuracy issues? Nov 25 03:15:16 Mountainman: optical isolation is actually very common in motor control Nov 25 03:15:27 for pwm there shouldn't be any issues, just use fast enough optos Nov 25 03:15:43 but you can try what I mentioned above first Nov 25 03:15:48 but it doesn't combine with ADC readback Nov 25 03:15:59 at least not easily I think Nov 25 03:16:03 it might still Nov 25 03:17:38 So going back to what you said above, DONT have motor controller ground share a ground with the actual motor itself? Nov 25 03:18:19 I think it needs to share it, if I understand the l298 right Nov 25 03:18:52 yea it does. It wont run if they arent tied together. Nov 25 03:19:01 dangit I wish I could easily draw circuit diagrams Nov 25 03:19:57 papaer and pen @zmatt ;) Nov 25 03:20:00 It takes practice. Nov 25 03:20:09 but basically you want the ground to be one straight line: BBB - motor driver (signal ground) - motor driver (output ground) - motor supply Nov 25 03:20:35 I wish I could post a picture.... Nov 25 03:20:48 BBB has an isolated supply I'm assuming? (an AC adapter probably) Nov 25 03:20:53 I also hope _no_ usb connection Nov 25 03:21:10 or serial Nov 25 03:21:15 or really anything except ethernet :P Nov 25 03:21:17 ..... ehhhh mini usb to usb for power and communication via ssh Nov 25 03:21:28 no bueno? Nov 25 03:21:30 ok, so now your BBB is grounded to your computer Nov 25 03:22:01 If all the grounds are tied to the bbb would that make a huge difference? Nov 25 03:22:22 Also could it possible be interference from the motor controller and not the motors? Nov 25 03:22:24 could still be okay if the motor psu is completely isolated from any grounds Nov 25 03:24:41 but if possible, replace the usb by ethernet + an ungrounded psu (i.e. a typical AC adapter, 5V 2A output) Nov 25 03:24:55 ethernet is transformer-isolated Nov 25 03:25:23 ditto the AC adapter, so that avoids any unforeseen ground currents Nov 25 03:25:36 not saying it's necessary, but put it on your list of things to try Nov 25 03:25:58 sigh... I really hope that isnt necessary. I already cut holes and internally wired my enclosure ): Nov 25 03:26:22 before everything was tested as working? :P Nov 25 03:26:36 Well it was working before on the prototype..... Nov 25 03:26:48 interesting, what's the diff? Nov 25 03:27:07 If you have only two wires coming from your motor (one motor), you can connect four wires to your motor controller, i.e. VIN, outA, outB, and GND. Oh and you can use your power source for the motor controller to ground your motor controller. Heh? Nov 25 03:27:30 I still support my statement though, no sane person would use USB in an industrial environment Nov 25 03:27:43 Yea... Nov 25 03:27:47 so if this proto is an example, maybe start by setting a good example ;) Nov 25 03:28:02 isolation ftw Nov 25 03:28:07 Still, it will work for his smaller item that is a replica of a larger industrial machine. Nov 25 03:28:18 idk... honestly. I thought it was the PWM. When I tested the adc functionality on the prototype I used a constant 5v source to power the motor system. Nov 25 03:28:34 Mountainman: it's hard to say at this point Nov 25 03:28:54 I will break while you all figure out something. I will keep thinking. Nov 25 03:29:16 Mountainman: but first, are you sure there's no connection between your grounds and any protective ground / earth ? Nov 25 03:29:20 other than via usb Nov 25 03:30:14 But since the adc doesnt have an issue with pwm on its own i kind of ruled that out. Yea the whole thing is in an antistatic budbox. The kind used for like outdoor power boxes. Nov 25 03:30:31 and the motor supply is isolated? Nov 25 03:31:01 (sorry for possibly asking things I already asked, just want to be sure) Nov 25 03:31:17 All I can say now is I would need a file tree of current that takes place. "A" to "B" and "B" to "C" and etc... Nov 25 03:32:12 Mountainman: if no loops exist, then make sure the ground is a nice linear path I outlined earlier Nov 25 03:33:08 I mean the motor supply ground is tied to the other grounds. But it wont work otherwise Nov 25 03:36:57 I say separate but equal. Nov 25 03:37:04 ok I'm gonna try making a crappy outline Nov 25 03:37:04 is there a place I can just upload a picture for a few seconds? Nov 25 03:37:14 probably... Nov 25 03:37:17 Separate those grounds. Nov 25 03:38:09 Um...there is google docs. Nov 25 03:38:14 good one Nov 25 03:38:29 I think those work. Even if it is a small drawing. Nov 25 03:38:40 Freehand! Nov 25 03:39:50 Or...Friting. Nov 25 03:40:03 Sorry...Fritzing. Nov 25 03:41:28 Um...conceptboard may work. Nov 25 03:42:38 fritzing ... that I can try indeed, Dia really sucks Nov 25 03:43:05 iirc fritzing was pretty limited but at least worked sanely Nov 25 03:43:33 I found a schematic tool a while back. I will look it up again. I will try to remember. Nov 25 03:44:20 yeah thing I never draw schems normally Nov 25 03:44:44 instructions on how to build H-Bridges from MOSFETS or BJT’s are available online in many places. Many companies sell H-Bridge IC’s, sometimes with more than one bridge and often including additional sensor and control lines for the motor. Nov 25 03:44:58 Set_: he's using such an ic Nov 25 03:45:25 I have no clue what IC is. I am lacking common sense. Nov 25 03:45:38 I found that in my notes. I forgot totally. Nov 25 03:45:55 grab a dictionary Nov 25 03:45:59 I have a lot to look up to keep up with you fellows. Nov 25 03:47:29 I just went to BBB.org and found Upverter. Nov 25 03:47:36 I think they have a free developer account. Nov 25 03:49:03 Hey, while he looks up how to clone what he has already done...can you explain how I check pitch on terminals. Nov 25 03:49:05 Please? Nov 25 03:49:51 I am sure there is some tool. I just do not want to hunker down and get it. Nov 25 03:50:02 https://docs.google.com/document/d/1pSzPOC_GBRoIij6tTimj7jjISsepYetm9sZGHyAV9N8/edit Nov 25 03:50:08 can yall access that? Nov 25 03:50:18 I will see. Nov 25 03:50:53 All those alpha-numeric characters looks like my mttq:// location tool for uploading to a specific site. Nov 25 03:52:45 Mountainman: you need to do File -> Share -> advanced -> "Anyone who has the link can..." set to "comment" Nov 25 03:53:51 try it now https://docs.google.com/document/d/1pSzPOC_GBRoIij6tTimj7jjISsepYetm9sZGHyAV9N8/edit?usp=sharing Nov 25 03:54:48 sorry if it looks like shit. Nov 25 03:55:35 The file does not exist. Nov 25 03:55:42 That is what I got. Nov 25 03:56:55 works for me now Nov 25 03:57:00 Dang... Nov 25 03:57:02 says there are two anonymous peeps viewing it Nov 25 03:57:07 Um... Nov 25 03:57:10 Not me. Nov 25 03:57:23 I will try again. Nov 25 03:57:25 i tried. but the great firwall blocks the actual access.. Nov 25 03:58:27 I mean i cant share it anymore than it is. says 3 anonymous people are viewing it Nov 25 03:59:06 Mountainman: btw, it's "L298", not "LM298" ... I found nothing on that latter part code Nov 25 03:59:26 (the datasheet you linked to also says L298 ) Nov 25 03:59:37 ahhh sorry by bad Nov 25 03:59:58 I got a google Docs thing. Nov 25 04:00:10 It was Google I/O coding school or something. Nov 25 04:00:18 Weird. Nov 25 04:00:20 wut... Nov 25 04:00:52 Yep. Nov 25 04:00:55 Mountainman: and stop drawing ground like there's the Big All-Encompassing 0Ω-impedance Ground you can connect to at your whim... the actual grounding matters :P Nov 25 04:01:39 Sorry the reason I did that is because I connected all the ground pins together. I can redraw it Nov 25 04:01:51 Mountainman: they should be, but it matters *how* Nov 25 04:02:51 If you have four connections from your power, you can add battery, VIN, Out, Out2, and Ground to exactly one motor control. Nov 25 04:03:25 Mountainman: the bottom part is a "zoom-in Nov 25 04:03:39 " of the (M) of the middle-diagram ? Nov 25 04:03:49 no wait, different part number Nov 25 04:03:54 It would be like a four way with three items. Nov 25 04:04:04 now sure what I'm looking at then Nov 25 04:05:00 ok, fritzing also gets on my nerves, and debian mispackaged it Nov 25 04:05:04 no first is driving motor connected to motor controller l298, second is load motor conected to divider. I didnt draw shaft coupling Nov 25 04:05:35 ah, "load motor" meaning generator here Nov 25 04:05:37 ? Nov 25 04:05:38 What's the maximum side of microsd card on a BBB? Nov 25 04:05:48 Phagus: size you mean? Nov 25 04:06:08 I tried to write Arch Linux ARM to a 64gb microSD card, and it didn't see to want to boot from it Nov 25 04:06:15 ah for boot Nov 25 04:06:16 hmm Nov 25 04:06:33 yea generator Nov 25 04:06:45 fritzing is broken in sid Nov 25 04:07:01 I'm following this guide: http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black Nov 25 04:08:37 zmatt: Do you know if 64gb is too big for boot? Nov 25 04:09:22 I don't see any reason why it would be Nov 25 04:10:02 those instructions don't make sense to me though Nov 25 04:12:10 according to the TRM an sd card needs a FAT boot partition, the "raw mmc" method (u-boot at fixed offset) supposedly only works for eMMC, not for cards, though I haven't verified myself whether that's actually true Nov 25 04:13:13 but there's afaik no magic limit around 64 GB .. the only magic limit is at 4 GB Nov 25 04:14:21 the comments near the bottom of the instructions also suggests arch deals pretty crappy with the eMMC devices :P Nov 25 04:14:29 stuff like that has been solved in uptodate debian images Nov 25 04:17:57 Mountainman: in any case, give my suggestion a shot of making sure the ground connections are BBB -- L298 pin 8 -- motor ground -- motor supply Nov 25 04:18:20 Mountainman: leaving the adc out of the equation for now, since you have the lockups also if it's not connected so first focus on that Nov 25 04:20:41 the ground from BBB to L298 pin 8, hereby declared "signal ground", is also the return ground for the pwm signals so keep those close together Nov 25 04:21:14 okay. Nov 25 04:21:54 preferably use twisted pairs (harvest from some CAT5 cable) for each pwm signal, with the wire it's twisted with connected to signal ground on both ends Nov 25 04:22:13 that minimizes the possibility of those lines picking up crap Nov 25 04:23:38 Hold the phone how do the ADC pins look internally? Like do they draw current easily? Nov 25 04:24:16 see AM335x datasheet Nov 25 04:24:26 also see AM335x errata! Nov 25 04:24:35 but that's mostly a concern during power-up Nov 25 04:24:46 (the erratum) Nov 25 04:26:10 and add schottky diodes as voltage clamps just in case Nov 25 04:26:44 (reminder that the adc is only 1.8V ) Nov 25 04:26:46 okay cause I just tested it again and it is magically working again. However with a caveat, the generator motor is powering a small light. When the adc is connected the light does not illuminate anymore hinting that the adc is drawing all the current. Nov 25 04:27:15 the adc should not draw significant current normally Nov 25 04:27:26 especially not since you have 10K in series Nov 25 04:27:34 oh wait Nov 25 04:27:40 is that a K ? Nov 25 04:27:44 yes it is Nov 25 04:28:35 Bah dcdd Nov 25 04:28:46 hmm okay so the output is 12v. The light bulb has a resistance of 35 ohms. The Adc has a voltage divider with a total series resistance of 11.73k. So the current that goes to the adc pin should be < current through bulb by simple nodal analysis.... Nov 25 04:29:35 Phagus: you can also get BBBlfs from github, ignore its crappy scripts but compile its poorly named "usb_flasher" tool Nov 25 04:29:51 So now the adc works, but the bulb will not illuminate. Could the previous issue have been a current issue in the adc pins? Nov 25 04:29:51 Phagus: power up the BBB with no sd card inserted but SD-boot button held Nov 25 04:30:11 Phagus: connect to usb, it'll show up as a network interface (rndis) Nov 25 04:30:37 Phagus: bring up the interface (happens automatically if you use NetworkManager, but you might not be) Nov 25 04:30:47 Phagus: then run the "usb_flasher" tool from BBBlfs Nov 25 04:31:21 and now it isnt working anymore..... Nov 25 04:31:44 Phagus: wait a bit, if all goes well it'll show some progress as it boots the BBB into a tiny linux system that makes the eMMC accessible as mass storage device Nov 25 04:32:19 Phagus: once it's done, the BBB's eMMC appears as /dev/sdX and you can try the installation procedure directly to eMMC Nov 25 04:32:31 skipping the SD card altogether Nov 25 04:33:05 since you're apparently an arch user, I'll assume you can take it from there :P Nov 25 04:33:43 the usb_flasher tool, although quite useful, is also quite brittle and seems to rely on initialization already being done by the linux rndis driver Nov 25 04:33:51 hence the need to bring up the interface Nov 25 04:34:51 alternative you can configure dnsmasq to act as BOOTP + TFTP server to accomplish the same thing as the usb_flasher tool (USB boot of the BBB works by appearing as RNDIS device and then attempting to netboot from the host) Nov 25 04:35:24 Getting a little ahead of myself here. Just trying to figure out what this boot button does Nov 25 04:35:29 changes the boot order Nov 25 04:35:31 rather, how it works, when to press it Nov 25 04:35:39 hold it during power-up Nov 25 04:35:45 (note: not mere reset, power-up. ) Nov 25 04:35:58 So its turned on right now from earlier. I press the power off button to shut it off Nov 25 04:36:16 Then I remove the power cable, and plug the cable back in and hold the boot button? Nov 25 04:37:00 hold the boot button while plugging in the cable Nov 25 04:37:18 Should I turn it off first? Nov 25 04:37:30 yes, by unplugging :P Nov 25 04:37:48 clean shutdown isn't very important probably if you don't have a working system yet Nov 25 04:38:15 note that long-pressing the power button will power-cycle or power-off depending on circumstances Nov 25 04:38:20 Well, I read it can damage it Nov 25 04:38:31 and I'm triyng to get into good habits early on :-) Nov 25 04:39:03 if you don't have a running linux system that listens to the power button event and performs a clean shutdown, then you can't perform a clean shutdown anyway Nov 25 04:39:09 u-boot ignores it Nov 25 04:39:38 and the power-cycle/power-off triggered by long-pressing it isn't really much cleaner than a power cut.... well okay maybe a little Nov 25 04:39:51 How long do I hold boot button for? Nov 25 04:40:03 note that it'll probably power-cycle, so you can long-press the power button while holding down the SD-button Nov 25 04:40:06 8 secs iirc Nov 25 04:40:15 Okay so another test, the ADC only locks if the pin is connected for an extended period of time. I.E. if I plug the cable in an unplug it doesnt freeze, also I cant have it connected when it first starts up.. Nov 25 04:40:16 you notice it since the power led goes off Nov 25 04:41:26 after 1 sec it'll either power on by itself or if you are still/again holding the power button Nov 25 04:41:56 this is sufficiently "off" for the SD-button to take effect, so no physical unplugging needed Nov 25 04:42:05 So while I put the power cable in, I hold boot button? Nov 25 04:42:20 or I put power cable in first, then hold boot button? Nov 25 04:42:28 Sorry, this is a bit unclear :-P Nov 25 04:42:39 you hold it pressed while the system powers on, whether due to cable plug-in or due to pressing the power button Nov 25 04:43:02 i.e. the SD-button state is sampled roughly around the time the power led turns on Nov 25 04:43:28 (SD-button, boot button, "S2", all synonyms... sorry for not being consistent :P ) Nov 25 04:43:52 Its okay. Just trying to seriously figure this thing out Nov 25 04:44:07 The LEDs seem pretty unresponsive to the boot button Nov 25 04:44:13 they are Nov 25 04:44:20 power button != boot button Nov 25 04:44:26 Yes Nov 25 04:44:51 So I plugged in cable, held boot button for 8 seconds, and the LEDs are just flashing as they always have Nov 25 04:45:06 going to go check fi my image was loaded Nov 25 04:45:12 ok sorry if I confused you Nov 25 04:45:31 Its cool. Pretty friendly community here at #beagle :-) Nov 25 04:46:06 the power button (nearest to the ethernet connector) only influences power: it works roughly like you'd expect a power button to behave: if the system is off it turns it on, if the system is on it generates an event the OS can react to Nov 25 04:46:44 I was reading that the power button also initiates shutdown Nov 25 04:46:52 if you keep it pressed for a long time the system is supposed to power-cycle (power-off, followed 1 second later by a power-on), although due to technical reasons it often results in power-off instead Nov 25 04:47:10 long time being around 8 seconds, although it's not very precise Nov 25 04:48:13 if the system doesn't boot into linux then most likely it'll power-cycle rather than power-off Nov 25 04:48:34 Cool Nov 25 04:49:06 the system also powers on if a power supply is plugged in Nov 25 04:49:49 How long did it take you to learn BBB to the point of comfort btw? Nov 25 04:49:54 at power-on (regardless of why it powered on) it samples 16 pins to determine its boot config Nov 25 04:50:07 these are set to sensible defaults using 100K resistors Nov 25 04:50:45 but you can override them if you want to via pins on expansion header P8 (the ones labeled lcd_data0-15) Nov 25 04:51:00 the boot-button (nearest to the μSD slot) also overrides one of them Nov 25 04:51:30 (specifically it pulls sysboot2 to ground with a 100Ω resistor) Nov 25 04:51:45 the net effect is that it changes the boot device order Nov 25 04:51:59 default is { eMMC, μSD, uart, usb } Nov 25 04:52:18 with SD boot-button held it becomes { spi, μSD, usb, uart } Nov 25 04:52:43 this is essentially similar to changing your boot device order in BIOS, just a bit more crude ;) Nov 25 04:52:54 and more suitable for things that don't necessarily have a GUI Nov 25 04:53:31 Hmm that method didn't work Nov 25 04:53:36 Debian is still installed Nov 25 04:53:37 the pins are only sampled at power-up, their value after that is ignored Nov 25 04:53:50 I mean Nov 25 04:53:52 so you need to make sure the boot-button is held down during power up Nov 25 04:53:53 Still booted up Nov 25 04:54:10 How should I shut down my device right now then? Nov 25 04:54:24 try briefly pressing the power button Nov 25 04:55:22 reminder: power button = right next to ethernet, SD-boot button = near SD card slot Nov 25 04:55:28 the latter one is an easy mnemonic Nov 25 04:55:42 Oh yes I have the locations down Nov 25 04:55:46 ok Nov 25 04:56:00 So to power it back up Nov 25 04:56:06 I hit power button then boot button? Nov 25 04:56:08 it powered down indeed? Nov 25 04:56:09 no Nov 25 04:56:14 hold boot button down Nov 25 04:56:17 Yeah no LEDs flshig Nov 25 04:56:26 all leds off? Nov 25 04:56:37 ys Nov 25 04:56:45 hold boot button down, keep it held down Nov 25 04:56:52 then trigger a power-up Nov 25 04:56:54 Ok Nov 25 04:57:01 I'm like 15 secs into holding bot Nov 25 04:57:12 like I said, the state of the boot button is sampled right around the time the power led goes on Nov 25 04:57:18 so you need to have it pressed down before that Nov 25 04:57:23 and can let go once the power led goes on Nov 25 04:58:44 I'm holding it down.. It doesnt seem to cause the thing to power on Nov 25 04:58:55 by itself it doesn't Nov 25 04:59:00 you need to press the power button to turn it on Nov 25 04:59:15 So with the device turned off, I hold the boot button down for 8 seconds Nov 25 04:59:18 no Nov 25 04:59:31 Okay.... Nov 25 04:59:37 Well, I powered it off before and its still in the off state Nov 25 04:59:41 read what I said a few lines ago Nov 25 04:59:49 hold the button while you power it on and release it after the power led turns on Nov 25 04:59:51 "the state of the boot button is sampled right around the time the power led goes on" Nov 25 05:00:02 the boot button doesn't *do* anything by itself Nov 25 05:00:16 but its state it checked by the processor when it's powered on Nov 25 05:00:34 hence... what uavcam just said Nov 25 05:02:16 you can power it on using the power-button (if power is plugged in) or plugging in power (if it isn't) Nov 25 05:05:36 This isn't working Nov 25 05:05:52 then just pull the plug Nov 25 05:05:59 No no no Nov 25 05:06:00 I did that Nov 25 05:06:10 but it's still booting? Nov 25 05:06:14 btw, did you eject the SD card? Nov 25 05:06:15 I pulled the plug out, I kept the boot button held down while I put the power back in Nov 25 05:06:28 No, I dont know when to eject the SD card Nov 25 05:06:35 right now, and keep it that way Nov 25 05:06:58 What about my Arch image? Nov 25 05:07:22 first check that the sd boot thingy is working (noticable by the BBB *not* booting from eMMC) Nov 25 05:07:33 Oh sorry, it is Nov 25 05:07:38 I shjould mention that I'm constnatly SSHing in Nov 25 05:07:58 If I see "BeagleBoard Debian Image" on the SSH welcome screen, I know my image hasnt been loaded Nov 25 05:08:18 yeah, so if you the boot-button-thing without any SD card, it shouldn't boot at all Nov 25 05:08:28 since eMMC is taken out of the boot order and no SD card is inserted Nov 25 05:08:32 Oh ok Nov 25 05:08:34 verify that first Nov 25 05:08:36 Let me try that yes Nov 25 05:08:53 I should tip you after this lol Nov 25 05:09:46 so the expected state is power led turning on, and then nothing Nov 25 05:09:55 other leds stay off Nov 25 05:10:13 ok so all LEDs are off now Nov 25 05:10:23 Now I press boot button? Nov 25 05:10:38 just checking: are you powering via USB connection to a computer, or using an AC adapter? Nov 25 05:10:43 ac Nov 25 05:11:00 ok, then all boot methods are failing now so it'll keep cycling through them till it finds one that works Nov 25 05:11:19 Well all the lights are off right now Nov 25 05:11:22 so if you want you can insert the SD card to try it Nov 25 05:11:37 you may need to wait a few seconds Nov 25 05:11:49 The thing is, out of the box, BBB is preloaded with a debian image on the eMMC thing Nov 25 05:12:01 yeah, but eMMC is out of the boot order right now Nov 25 05:12:38 if it still boots into debian, then the bootloader you programmed onto your SD card actually boots linux from eMMC Nov 25 05:12:41 or Nov 25 05:12:55 it loads your arch kernel, but passes the wrong kernel args and ends up using eMMC as rootfs Nov 25 05:13:14 isn't it fun, having so many options :) Nov 25 05:13:25 Yeah I'm still not getting the whole boot button thing Nov 25 05:13:37 ight now BBB is plugged in but no LEDs Nov 25 05:13:42 the boot button merely tells ROM where to look for the stage 1 bootloader Nov 25 05:13:45 I held down boot button and no LEDs lit up Nov 25 05:14:18 like I said, it's like the BIOS config menu on a PC where you can decide the order in which various boot disks are examined Nov 25 05:14:19 I put in SD card, no lights again. with SD still placed inside I held down boot button, device is still not flashing any LEDs Nov 25 05:14:24 Yeah Nov 25 05:14:36 So its like hitting f4 or whatever right at boot? Nov 25 05:14:42 f4/del/f8/etc Nov 25 05:15:00 yeah, except the processor just looks at whether it's pressed or not right at power-on Nov 25 05:15:05 right Nov 25 05:15:07 (about 25 ms after the power led turns on) Nov 25 05:15:22 (iirc) Nov 25 05:15:22 So I need to have button held down before I even turn it on Nov 25 05:15:26 yes Nov 25 05:15:29 they should used a jumper... Nov 25 05:15:30 and you can let go immediately after Nov 25 05:15:32 This is hard Nov 25 05:15:35 uavcam: you can Nov 25 05:15:39 I wish I had two more arms Nov 25 05:15:48 Phagus: but you're in the right state right now Nov 25 05:15:51 so keep it that way Nov 25 05:16:07 Phagus: I wish everyday that I had 4 arms.... or telekinesis or some shit. Nov 25 05:16:39 Four arms + TK, I'll take that Nov 25 05:16:48 uavcam: you can connect a resistor between P8.43 and ground, has the same effect as pressing the boot button Nov 25 05:17:05 I have a little jumper wire with a resistor in it for exactly that purpose :) Nov 25 05:17:21 YESssssssssssssss it works Nov 25 05:17:26 Okay cool Nov 25 05:17:32 You're my saviour here zmatt Nov 25 05:18:01 I seriously will tip you for this, lol Nov 25 05:18:08 Phagus: note that if you want to use BBBlfs (which is a very useful tool to have in your toolbox), the procedure is similar, but instead of inserting an SD card, connect it to USB Nov 25 05:19:30 I can also strongly recommend getting a serial console cable if you don't already have one... it's never fun to be blind when having boot issues Nov 25 05:20:06 Phagus: btw, define "it works" ... did it actually boot from the card? Nov 25 05:20:16 serial cable = miniUSB-to-USB cable? Nov 25 05:20:19 no Nov 25 05:20:27 ethernet cable? Nov 25 05:20:32 http://elinux.org/Beagleboard:BeagleBone_Black_Serial Nov 25 05:20:35 I mean serial Nov 25 05:20:41 Oh interesting Nov 25 05:20:55 hey so I am still having issues with the adc. It only happens when the pin is connected for certain time and when it is connected it draws current from the load. If I connect and disconnect it continually it never freezes. Any ideas on a solution? Nov 25 05:21:00 it works = I SSHed into the arch image having been loaded Nov 25 05:21:26 Interesting Nov 25 05:21:37 Phagus: that's fascinating... means the AM335x TRM is wrong Nov 25 05:21:37 I've seen one of these before Nov 25 05:22:25 Phagus: so apparently a FAT boot partition isn't needed for SD cards either, didn't know that Nov 25 05:22:30 since your card doesn't have one, right? Nov 25 05:23:13 Ahh... I'm not sure Nov 25 05:23:25 btw, tip: those installation instructions put the ext4 partition at 1 MB from start of disk (sector 2048) Nov 25 05:23:33 put it at 4 MB from start (sector 81920 Nov 25 05:23:33 the tutorial looks like there is none Nov 25 05:23:51 since 4 MB is the erase-block size of the eMMC Nov 25 05:24:43 hence starting a partition at 1 MB is effectively "misaligned" Nov 25 05:25:19 I think for performance tuning there's also some ext4 option to tell it the raid stripe size is 4 MB (never mind it's not raid, that's apparently still the best way to inform it) Nov 25 05:26:57 Phagus: btw, another fun fact about the power button: it is incapable of waking the system from suspend Nov 25 05:27:17 brilliant little hardware design screw-up Nov 25 05:27:40 the interrupt signal from the pmic is wired to a pin that's not capable of waking up the system Nov 25 05:28:30 I see Nov 25 05:28:57 lol my lab is a mess. Nov 25 05:29:10 you can wake it up in a ton of other ways, just not the power button Nov 25 05:30:23 uname on my ssh, confirmed to be ARCH armv7l Nov 25 05:30:28 woo Nov 25 05:30:40 congrats... I guess ;P Nov 25 05:30:55 4.3.0-1-ARCH Nov 25 05:31:00 eah Im following the part 2 now Nov 25 05:31:01 ok, so not a -ti kernel Nov 25 05:31:07 You were asaying something earlier about part 2 Nov 25 05:31:10 so you don't have working power management anyway Nov 25 05:31:23 (probably) Nov 25 05:31:37 yeah the steps 4 and 5 sound quite odd Nov 25 05:31:58 but the root cause is that linux enumerates mmc devices in whatever order is happens to encounter them Nov 25 05:32:22 TI made their own kernel? Nov 25 05:32:31 it doesn't care that the hardware and bootloader always consider the μSD slot to be mmc0 and eMMC to be mmc1 Nov 25 05:32:47 they have a branch with patches that haven't made it to mainline yet Nov 25 05:33:21 no shock there, most distros also use branches of the kernel with their own patches Nov 25 05:33:46 Well, yeah. I just would have thought they had stroger control over the BBB upstream I guess? Nov 25 05:33:59 debian systems normally use kernels with beaglebone-specific patches ("-bone" kernels) and optionally also the TI patches ("-ti" kernels) Nov 25 05:34:00 or maybe arch-arm made some uncanny dev decisions Nov 25 05:34:13 lately the -ti kernels are default on bbb debian systems Nov 25 05:34:18 they simply work better atm Nov 25 05:34:28 however there's no 4.3-ti kernel :) Nov 25 05:34:54 Oh yes, welcome to Arch Linux's bleeding edge philosophy ;-) Nov 25 05:34:55 for some reason they were stuck at 4.1 for a while, and recently I spotted a 4.4-rc1-ti kernel Nov 25 05:35:19 I'm all for bleeding edge Nov 25 05:35:41 except bleeding edge mainline may still lag behind 4.1-ti when it comes to hardware support specific to TI processors Nov 25 05:35:55 so then you have to choose which edge you consider more important Nov 25 05:36:45 I mean, if you have valid criticism against Arch-Arm on BBB, by all means let me hear it. I'm not wedded to the idea of using it Nov 25 05:36:55 "nobody uses it" Nov 25 05:37:03 if you ask questions here, you'll run into that problem Nov 25 05:37:08 I do like the customizability Arch gives me. I'm planning on using this BBB as a stripped-down appliance Nov 25 05:37:10 virtually everyone runs debian Nov 25 05:37:21 I see Nov 25 05:37:29 How about this Angstrom thing? Nov 25 05:37:36 museum piece Nov 25 05:37:36 acient Nov 25 05:38:02 I think I'll do that then Nov 25 05:38:06 lol Nov 25 05:38:09 I'm sure I will encounter problems Nov 25 05:38:17 So Debian it is Nov 25 05:38:20 Phagus: since you're used to arch, consider debian sid Nov 25 05:38:29 otherwise you'll be OMG WTF IS ALL THIS ANCIENT CRAP Nov 25 05:38:32 alll the time Nov 25 05:38:54 Oh nah, I have Debian servers still running Wheezy Nov 25 05:39:02 ew Nov 25 05:39:37 Phagus: I don't use anything older than stretch myself Nov 25 05:40:14 there are no premade stretch images, but it's easy enough to download the latest jessie console image and then directly upgrade to stretch Nov 25 05:42:15 what I was saying about "step 2" earlier Nov 25 05:42:58 the last two points on the page (4 and 5) sound like mess that has been solved in the debian images Nov 25 05:43:04 Will I encounter lag issues with Debian? Nov 25 05:43:12 I mean, I don't need a lot of preinstalled things Debian normally comes with Nov 25 05:43:20 linux enumerates mmc devices in whatever order it encounters them Nov 25 05:43:23 just get the minimal images Nov 25 05:43:54 so hardcoded root=/dev/mmcblk0p1 will cause trouble Nov 25 05:44:00 debian switched to using UUID Nov 25 05:44:17 For eg, I don't konw f'n Java runtime do I? Nov 25 05:44:23 None of my apps use Java Nov 25 05:44:26 Phagus: grab a "console" image Nov 25 05:44:31 those are really minimal Nov 25 05:46:01 https://rcn-ee.com/rootfs/bb.org/testing/2015-11-21/console/ Nov 25 05:46:27 These are small Nov 25 05:46:46 the BBB-eMMC-flasher-*-.img.xz is something you can xzcat right onto your SD card, boot from it and it'll reflash your eMMC Nov 25 05:57:27 Thanks Nov 25 05:57:31 Doing these things. Nov 25 06:03:06 Phagus: there are still some unnecessary packages though, but it's *reasonably* clean Nov 25 06:03:27 you can right away purge any packages with "dra7xx" in the package name Nov 25 06:03:54 ditto tiomapconf Nov 25 06:04:50 Alright Nov 25 06:06:44 Okay, I think its flashing Nov 25 06:07:01 I see the lights moving in an ordered fashion, 1,2,3,4,3,2,1 Nov 25 06:07:01 etc Nov 25 06:07:05 yes that's flashing Nov 25 06:07:12 all leds on = done Nov 25 06:08:07 I'm currently nosing around in the same image to see what's there (except I couldn't be bothered to flash it so I'm using systemd-nspawn to browse it) Nov 25 06:08:36 You've been extremely helpful zmatt Nov 25 06:08:44 qemu does seem to make some things a bit laggier, although disk I/O is obviously snappier than eMMC Nov 25 06:08:47 Seriously, at the very least I owe you a beer Nov 25 06:08:56 heh, I don't drink beer but thanks :) Nov 25 06:09:22 Haha. Or whatever. Nov 25 06:09:32 Cool so I think that did it Nov 25 06:11:44 yepp Nov 25 06:12:22 we in busnierss. So quick question. Can you just patch into a BBB without a router? Nov 25 06:12:30 using an ethernet cable Nov 25 06:12:42 it expects a dhcp server Nov 25 06:12:50 you can change that to static config of course Nov 25 06:13:10 also popular is usbnet (that's enabled by default in the big images but not in the console image) Nov 25 06:14:16 note that if you feel like ditching the old ifupdown and use systemd-networkd instead (I did and consider it an improvement) you need to upgrade to stretch first since jessie's systemd is too old Nov 25 06:14:17 plugin the cable, get a static ip in the same net and you should be able to connect Nov 25 06:14:29 uavcam: "without a router" Nov 25 06:14:43 Phagus: actually, it'll still be reachable via ipv6 in any case of course Nov 25 06:14:55 yay for stateless ip autoconfiguration Nov 25 06:15:18 what the hell is dmidecode doing on an arm system Nov 25 06:15:30 lol Nov 25 06:18:06 yeah without a router. just connect two devices with a cable and they should be able to communicate via ethernet without any router/switch/hub/whatever inbetween if the ip conf is right Nov 25 08:00:13 i'm gettin https://www.refheap.com/112053 on my beaglebone black booted with the image from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console it's unclear to me what i should do. how do i get that executable? Nov 25 08:00:54 how do i get the executable arm-linux-gnueabihf-gcc Nov 25 08:06:50 whate are you trying to do? Nov 25 08:56:40 are you trying to compile something? Nov 25 08:57:27 or better: what software are you trying to setup? Nov 25 09:00:57 Element14 had that fellow Jkrinder on the site making presentations yesterday. Nov 25 09:02:12 Here it is: http://www.element14.com/community/docs/DOC-78585/l/beaglebone-black-webinar-series?ICID=hp-top10download-ban Nov 25 09:02:26 Cool! Nov 25 09:04:53 It said be careful before sharing but I thought twice. Enjoy. Nov 25 09:11:02 jk essentially _is_ bb.org Nov 25 09:12:28 Oh. Nov 25 11:11:54 cool, I can almost sort of boot a bbb console image in an systemd-nspawn container (implicitly using qemu-user) Nov 25 11:12:20 there's just the, ehm, slight issue of qemu-user not support netlink sockets Nov 25 11:12:26 *supporting Nov 25 11:18:15 hi Nov 25 11:18:36 can anybody help me with installing fswebcam on beaglebone Nov 25 11:18:38 ? Nov 25 12:26:48 zmatt: that google doc of the subarctic pins with all the tabs is quite nice :) Nov 25 12:29:27 only thing that would be nice to add would be pinctrl addresses, as those are nice for reference when doing dts creating/modification Nov 25 12:58:26 0x800 + 4 * pin Nov 25 12:59:08 for dts, use a macro Nov 25 13:02:40 e.g. this is what a dts fragment looks like in our codebase -> http://pastebin.com/SuR8h7hk Nov 25 13:44:56 hi all Nov 25 13:45:09 I have a question Nov 25 13:45:25 somebody can answer me? Nov 25 13:46:05 About analog input of beagleboard green Nov 25 13:46:30 is there anyone? Nov 25 13:49:02 EPATIENCE Nov 25 14:13:34 tbr: that error crashed his IRC client I guess ;) Nov 25 14:34:05 Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along Nov 25 14:35:24 ? Nov 25 14:37:52 what would you like to do? Nov 25 14:44:16 i would like choose Beagleboard.org for gsoc so what should i do ? Nov 25 14:45:19 ? Nov 25 14:46:17 look at the project ideas page Nov 25 14:46:47 look at the gsoc student handbook how to develop from an idea or create your own idea Nov 25 14:48:36 Thank you tbr Nov 25 14:56:06 I would like to do a project using Beagle board,but my mentor is asking me to do it using an arduino.can someone suggest a project for a beginner which can only be done using a beagle board and not using an arduino Nov 25 15:03:19 I have done many projects using arduino and would like to start with Beagle can you suggest some beginner projects that can only be done using beagle and not using an arduino Nov 25 15:05:03 * pheonix_ slaps pheonix_ around a bit with a large fishbot Nov 25 15:05:24 * pheonix_ slaps pheonix_ around a bit with a large fishbot Nov 25 16:41:32 I have done projects with arduino and i'm new to beagleboard.Can someone help me get started Nov 25 16:43:09 Exwife: http://beagleboard.org/getting-started Nov 25 16:44:49 @wmat Tah] Nov 25 18:05:59 why is my beagle so picky about booting? Nov 25 18:26:09 xer0x: why are you so vague about your problem Nov 25 18:26:53 tbr: partially because the problem is vaguely in my head Nov 25 18:27:53 so you don't know which part fails? or if its sd or emmc? Nov 25 18:28:18 More specifically, I wanted to flash a new OS onto my BBK's internal memory but my BBK doesn't like booting from the emmc Nov 25 18:28:54 I can hold down the button and boot up with what's on the SD, then copy that over Nov 25 18:29:08 but it then it won't boot it Nov 25 18:29:37 I've been trying this headless which hasn't helped debug it either :( Nov 25 18:36:55 xer0x .. have you tried downloading a Flasher image from the official page at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian ? Nov 25 18:37:24 I suggest the 2015-11-03 section a good starting point Nov 25 18:37:35 veremit yes, i could get that one to work Nov 25 18:38:05 then i got cocky and started to try other projects like Alpine linux Nov 25 18:38:42 you'll have to refer to their documentation as to how to flash other linuxes to it Nov 25 18:39:04 its not quite as simple as 'boot and copy' Nov 25 18:42:47 hi All Nov 25 18:44:09 any idea how to enable bootup logs on console on latest TI BSP kernel Nov 25 18:50:54 rkc .. do you have a serial debug cable to attach to the header? a lot of information comes up there ... Nov 25 18:53:59 @veremit... oh yes, and it was working fine Nov 25 18:54:29 but recently I switched to TI kernel, there it does not Nov 25 18:54:39 I have a thread going on, here: Nov 25 18:54:57 https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/IaFR3VueUrk Nov 25 18:54:59 ah. Nov 25 18:55:16 just got a reply from Robert Nelson Nov 25 18:55:36 * veremit peers at the nicklist .. Nov 25 18:55:44 nope, ok cool :] Nov 25 18:56:32 with omap2plus_defconfig it works fine.... this new serial driver change has switched from ttyO0 to ttyS0 Nov 25 18:57:36 But he seems to suggest that bootup logs will be available on ttyO0 and later on with getty we should use ttyS0 Nov 25 18:57:43 strange !!! Nov 25 18:57:55 unless I missed his point Nov 25 19:02:40 no .. the serial port using the 8250 driver will appear as ttyS0 Nov 25 19:02:54 only the omap driver still uses the legacy ttyO0 Nov 25 19:03:15 how uboot handles it I'm not sure Nov 25 19:03:28 but the physical port should be the same .. Nov 25 19:16:21 yeah... that looks to be the case Nov 25 19:17:08 any idea how to build just the kernel and not all the modules Nov 25 19:17:36 I make a samll change in TI BSP and it goes on to build whole set of modules Nov 25 19:17:45 which I anyway do not use Nov 25 19:25:19 'make' should only rebuild what is necessarry.. if you're using a script you will have to dig deeper into it Nov 25 20:15:21 veremit: using ttyO0 is safer however, since it'll merely emit a warning when used with the 8250 driver, while using ttyS0 with the omap-serial driver will not work Nov 25 20:27:11 who still uses the omap driver, anyways!? :D Nov 25 20:27:28 ohai zmatt ... Nov 25 20:28:10 I s'pose if its a TI kernel ... Nov 25 20:32:53 I still don't understand why we're moving to another driver at all Nov 25 20:35:11 -shrug- integration and simplification is good? Nov 25 20:36:04 maybe arm should give linus the two-fingers and fork off .. we can have thousands of variants then ... ;) Nov 25 20:36:06 lol, simplification... add even more special-cases to a driver that it's already such a mess that no sane person would touch it with a ten foot pole Nov 25 20:36:39 given that any improvement on your target might break stuff for one of the numerous other incompatible variants of the peripheral Nov 25 20:36:39 eh, its still one driver .. who cares that its a load of spaghetti ?! Nov 25 20:37:35 I do, I regard the backward compat (strong emphasis on "backward") with 8250 to be a relic that should be killed in its sleep rather than cherished Nov 25 20:37:57 it's a horrible interface Nov 25 20:38:23 some would argue .. why are we still using serial? Nov 25 20:38:37 but then you can just look at musb in the am335x .. and that sends ME running ... Nov 25 20:38:50 because it works fine for many applications Nov 25 20:39:01 right Nov 25 20:39:39 and it's highly ubiquitous Nov 25 20:40:03 indeed Nov 25 20:40:43 which is why I'd much rather would have had a *good* peripheral interface rather than that horrid crap from the 80s or whenever this cruft clawed its way into this world Nov 25 20:40:57 surely then, you'd expect it was possible to make some form of 'unified' interface to it .. rather than a per-device implementation?! Nov 25 20:41:51 sure, if all vendors suddenly decided to cooperate for the same of allowing code to be ported from their devices to that of their competitors :P Nov 25 20:41:56 *for the sake Nov 25 20:42:22 in practice I'd rather have the chip I'm working with have an actual *good* interface Nov 25 20:42:49 note that this doesn't preclude a backwards compatible interface being present also... but I wouldn't touch that part Nov 25 20:43:07 lol Nov 25 20:43:18 nuff said I think :) Nov 25 20:44:31 yeah, there are downsides also to writing a driver for the omap-serial peripheral specifically... mine turned out to be *too efficient* Nov 25 20:45:02 for some reason the uarts on am335x can't handle more than about 8-10 bytes written consecutively, even if there's plenty of fifo space Nov 25 20:45:20 I need to insert dummy writes to slow down the rate Nov 25 20:45:22 :P Nov 25 20:46:07 I guess other drivers are already too inefficient to trigger the problem Nov 25 20:46:24 that's pathetic Nov 25 20:46:37 its .. unusable Nov 25 20:46:39 probably a clock domain crossing issue of sorts Nov 25 20:46:59 more crappy dma issues? Nov 25 20:47:06 actually it's easy to work around, just write some harmless register in between two byte writes Nov 25 20:47:15 no actually I think using dma would also fix the problem Nov 25 20:47:19 haven't tested that yet Nov 25 20:47:45 so writing to the fifo buffer .. what happens? it drops bytes or blocks or what? Nov 25 20:47:59 why have a fifo?! Nov 25 20:48:06 * veremit head-desks Nov 25 20:48:19 an edma TC can't have more than 4 writes outstanding, and since the uart doesn't allow any efficient mechanism to write data into its fifo, the dma controller has no option but to use single writes for each byte Nov 25 20:49:15 ok what about "inefficient means" .. Nov 25 20:49:46 I'ma stick to microcontrollers lol .. writing assembly fifo's seems somehow 'more' efficient .. Nov 25 20:49:47 it seems to muck up pointers or counters... results in the last byte written being repeated many times (I think 64 minus the number of bytes written since the overflow, or somerhing like that) Nov 25 20:50:05 you don't want single-byte transfers Nov 25 20:50:21 well not single -byte writes no... Nov 25 20:50:45 but wtf. why is there a fifo if you can't write to it .. and wtf doesn't dma work .. Nov 25 20:50:52 dma works fine Nov 25 20:50:52 its like the device is a bit of swiss cheese! Nov 25 20:51:18 well .. let me rephrase .. it IS A bit of swiss cheese . just a few bits of it work "well enough" lol Nov 25 20:51:29 but the 8250 interface only has a single-byte data-write register Nov 25 20:51:44 there's no way to write more than one byte to it in a single transfer Nov 25 20:51:46 Really?! Nov 25 20:52:12 there's no multi-byte interface .. ? Nov 25 20:52:15 no Nov 25 20:52:30 like .. you're never gonna need more than 640k of ram .. you won't ever write more than 1 byte on serial!? Nov 25 20:52:32 hello? this interface probably dates back to 8-bit microcontrollers :P Nov 25 20:52:51 what crack-head came up with that idea? Nov 25 20:52:57 * veremit mutters Nov 25 20:53:18 you think this is bad? hahahahaha Nov 25 20:53:33 this is a minor inconvenience compared to the horrors of the 8250 interface Nov 25 20:53:49 well .. I should know better than to scratch the surface of linux drivers ... Nov 25 20:54:18 where I have, on good authority, tis written "don't fuck with this, t works...." Nov 25 20:54:22 well the linux driver is even worse since it attempts to support many uarts with roughly-but-not-really-quite-compatible register interfaces Nov 25 20:55:01 that is invariably going to be a fudge when you work with a number of different implementations of varying 'compliance' .. Nov 25 20:55:19 veremit: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/379360/1342615#1342615 Nov 25 20:59:23 veremit: I nowadays take the short route "reset" -> all the way to the bottomleft, do config there, move to "operational / fifo config" and stay there Nov 25 20:59:45 wow that looks ... horrible .. Nov 25 21:00:25 * cybernaut hands out the clubs to allow people to "reset" their hardware "appropriately" Nov 25 21:00:56 * veremit accepts gladly Nov 25 21:01:06 if there's any need to move back to config mode (any flavor), just reset the uart and perform the same procedure again... keeps things simple Nov 25 21:01:11 ... ish Nov 25 21:01:42 veremit hit the hardware engineer first it will make you feel better ;) Nov 25 21:01:48 note that "reconfiguring" includes things like enabling/disabling hardware or software flow control Nov 25 21:01:57 cybernaut .. methinks bashing self is not recommended .. Nov 25 21:02:12 since you can't access that register unless in the bottomleft circle Nov 25 21:02:25 but doing so kills the uart clock and corrupts any character in transit Nov 25 21:02:42 sounds altogether overcomplicated to me .. Nov 25 21:02:45 hence you may as well just reset the thing Nov 25 21:03:01 the interfaces is highly modal Nov 25 21:03:18 to the point that navigating it becomes sort of a puzzle-adventure game :P Nov 25 21:03:29 except .. not a fun one .. Nov 25 21:03:50 correct Nov 25 21:03:57 the irq structure is equally horrid Nov 25 21:05:17 a lot of that may be legacy IP they decided to recycle from former years of brilliant planning. Nov 25 21:05:46 and there's really no excuse... I refuse to believe that allowing direct access to the registers (at different addresses) would be problematic Nov 25 21:06:23 note also that the uart doesn't put an id/version register at the start of its address space like nearly every other peripheral does Nov 25 21:06:45 instead its fifo read/write register is there Nov 25 21:06:48 it's probably not an arm peripheral Nov 25 21:06:55 none of these are ARM peripherals Nov 25 21:07:07 I would say there is the first mistake. Nov 25 21:07:12 the uart has plenty of TI in the mix though Nov 25 21:07:41 but mostly just adding stuff, not any kind of cleanup or refactoring Nov 25 21:07:54 it's still the same ancient uart interface Nov 25 21:07:57 the whole reason to use ARM peripherals is because they are almost standardized (IE easy to work with and configure based on existing libraries) Nov 25 21:08:06 complete with support for 5 data bits and 1.5 stop bit Nov 25 21:08:17 in case you need to interface with a 45 baud teletype Nov 25 21:08:18 :P Nov 25 21:08:55 no 110 or was that 50.. can't remember in EBDIC encoding or whatever it was. Nov 25 21:09:06 cybernaut: I don't have much experience with ARM peripherals, but I've seen ARM make plenty of bad choices in peripheral design Nov 25 21:09:09 baudot Nov 25 21:10:10 that was designed for a mechanical switch system to select the character to print out. It was all mechanical in that day and age. Nov 25 21:10:59 you're gonna tell me, that we still have to interface to mechanical computers? in the 21st century? Nov 25 21:11:10 somebody PLEASE extinguish that crack=pipe lol Nov 25 21:11:54 cybernaut: for example you can't inspect the configuration of the system timer on the Cortex-M3 without also reading the event-bit which is set when the timer hits zero Nov 25 21:11:57 zmatt I don't disagree but reinventing stupid with weird interfaces for a PC on an ARM machine doesn't make sense. Yes they were smokin' but to quote a baseball player "in one word 'you-never-know'" Nov 25 21:12:22 cybernaut: and that bit clears on read Nov 25 21:13:14 zmatt.. why does that matter? Nov 25 21:13:20 which means that if you want to check the system timer config, if you wanted to do anything with the event bit you're forced to do it right there and then even if that makes no sense in your code flow, since it's been cleared by the read Nov 25 21:13:47 (in general, "clear on read" registers DIE DIE DIE) Nov 25 21:14:04 flags are often 'clear on read' Nov 25 21:14:12 almost never luckily in modern peripherals Nov 25 21:14:18 that a common hardware occurance Nov 25 21:14:22 used to be Nov 25 21:14:29 in microcontrollers still is probably Nov 25 21:14:42 although explicitly writing a 0 has some merit .. I think clear-on-read is simpler Nov 25 21:15:06 veremit: except when that bit is packed together with non-status-bits in one register Nov 25 21:15:22 or if you need different status info at different locations in your code Nov 25 21:15:25 well thats just poor design :) or implementation... Nov 25 21:15:33 my point exactly Nov 25 21:15:56 I don't imagine you're short on address space in this age .. Nov 25 21:16:12 I've seen plenty of registers with 'unused' bits and addresses Nov 25 21:16:14 clear on read also sucks for debugging, though if you're lucky the peripheral doesn't clear if the read is by the debugger (if it can notice that) Nov 25 21:16:30 zmatt a tale of TI, they did the same thing with the msp430 SPI serial controller it can be a pain too. Essentially you can get an overflow condition if you don't read the receive register when using DMA with the output buffer. You have to read the read register each DMA cycle therefore. Furthermore you can received SPI DMA without writing SPI data with DMA so you have to do weird things to use DMA on the processor. Oh did I mention Nov 25 21:16:30 that the registers although 8bit have to be accessed as 16bit or you reads and writes get messed up? Nov 25 21:16:33 how would it1? Nov 25 21:16:45 veremit: metadata bit in the request Nov 25 21:17:10 cybernaut: lol Nov 25 21:17:21 zmatt: designed??!!!! Nov 25 21:17:35 veremit: yes, MReqDebug in OCP-terminology Nov 25 21:18:00 sucj inconsistency, much confusion. Nov 25 21:18:02 you can also configure the on-chip firewalls to allow or deny access based on it Nov 25 21:18:18 zmatt yeah I know that problem it happens in the MSP430 when debugging when you want to know the state of something it's automatically cleared and your program can't work correctly. Nov 25 21:18:20 vrey headache lol Nov 25 21:18:45 veremit: but actually I consider it a good thing is debugger-reads never alter the peripheral state Nov 25 21:18:54 so you can actually safely dump registers Nov 25 21:19:11 too bad it's not actually consistently implemented in peripherals Nov 25 21:19:12 zmatt: well that could really cock things up, so it is desireable... Nov 25 21:20:03 does TI disable DMA when the debugger is active on the AM35XX? Nov 25 21:20:35 DMA itself? no. many peripherals have a suspend-signal though, with varying effects Nov 25 21:20:56 and it's programmable which core's debug-suspend they react to Nov 25 21:21:27 so e.g. you could have a timer used by PRU freeze while the PRU is halted in debug Nov 25 21:21:41 well on one of their parts they disable DMA completely so you can't debug DMA code without poke and hope. It's hard to see what the behavior is and their documentation is abysmal on DMA often. Nov 25 21:22:20 cybernaut: DMA stays fully operational, though of course a suspended peripheral will probably cease to generate new DMA requests Nov 25 21:22:44 with DMA I mean EDMA in this case of course Nov 25 21:23:44 debug suspend will halt integrated DMA that some peripherals/subsystems have of course (if they support debug suspend), although that never affects the ability to inspect Nov 25 21:25:07 veremit: I also think clear-on-read made more sense on microcontrollers which generally had simpler overall logic, and doing an additional write was an unnecessary expense Nov 25 21:25:22 on a SoC like the AM335x the write is pretty much free, especially compared to the read Nov 25 21:26:13 zmatt.. its a fair point, but depends where the logic is coming from... where TI is concerned .. who knows! Nov 25 21:26:15 (since the write just goes into a queue, while for a read the cpu really needs to sit and wait a full ping-time to the peripheral) Nov 25 21:26:53 yeah, most recent or semi-recent TI peripherals have abandoned clear-on-read registers Nov 25 21:28:21 zmatt that is because of bugs in compilers where the volatile keyword wasn't adhered too by the code generator. It created a lot of bugs in software that 'certain' companies blamed on the programmers but where the compilers fault. Nov 25 21:28:34 don't get me started Nov 25 21:28:49 C/C++ is really horrible for dealing with memory-mapped I/O Nov 25 21:28:51 * cybernaut grins. Nov 25 21:28:57 which quite sucks, since there isn't really a better alternative Nov 25 21:29:45 I would really appreciate being able to slap attributes onto things to explain to the compiler what the constraints and semantics are Nov 25 21:29:55 that's why they introduced the volatile keyword but MS and intel compilers and "certain" others optimized proper reads and writes out as 'redundant'. Nov 25 21:30:08 volatile is a very blunt instrument Nov 25 21:30:16 I often don't want to make stuff volatile Nov 25 21:30:40 for HW registers that's a must unfortunately. Nov 25 21:30:56 actually most registers of many TI peripherals can be treated like memory Nov 25 21:31:17 with an occasional compiler barrier where necessary to enforce ordering Nov 25 21:31:40 there are a few really obnoxious ones though Nov 25 21:31:57 like some ARM peripheral supports 8-bit and 32-bit access, but not 16-bit access Nov 25 21:32:30 Heh or some peripherals "allow" 8bit access but not really ;) Nov 25 21:32:39 without volatile, evaluating (foo.x & 0xffff) gets optimized to a 16-bit access if you don't slap on a "volatile" Nov 25 21:32:55 but volatile often triggers many unnecessary accesses Nov 25 21:33:29 and the ping time to a typical peripheral on the am335x is about 150 clock cycles iirc Nov 25 21:34:33 I'd much prefer to be able to tell the compiler "hey, this is pretty much memory-ish, but just don't use 16-bit access, okay?" Nov 25 21:36:46 hmmm you can't define it as "volatile uint8_t this_reg;" and "#pragma LOCATE(this_reg, XYZ)" ? Nov 25 21:38:13 the point is that the registers 32-bit and not uncommonly actually contain 16-bit fields, i.e. when modeling the peripheral as a structure I'd normally use want to use u16 Nov 25 21:38:21 except I can't Nov 25 21:39:26 and as I said, I actually normally avoid unnecessary use of volatile... this sort of peripheral behaviour unfortunately doesn't leave any choice currently Nov 25 21:40:22 but volatile is the other extreme... it takes every ability to optimize away from the compiler Nov 25 21:40:58 indeed it's hard to avoid because the back end optimizer doesn't know anything and could switch access to 16bit or 32bit or 8bit. The optimizer is completely ignorant of how the peripheral is used is a reality. Nov 25 21:41:10 while most of the time I deal with almost-but-not-quite-memory where most optimizations would still be valid. But I hvae no way to explain this to the compiler Nov 25 21:41:31 like I said, I really wish for some attributes for that Nov 25 21:41:46 or a better language Nov 25 21:42:40 since C/C++ seem to be getting more obnoxious to use for systems programming all the time Nov 25 21:43:25 the only good move in C++ lately has been better metaprogramming support (although still mediocre) Nov 25 21:43:47 optimizers make choices that are based on patterns of register and memory access use. unfortunately this is not always valid with peripheral usage. Nov 25 21:44:08 that's what attributes are for Nov 25 21:45:06 if they can make crazy shit like [[carries_dependency]], they could also add some attributes to model the constraints of memory-mapped I/O :P Nov 25 21:45:26 afk for a bit Nov 25 21:45:56 I believe that is what the #pragma operator in the precompiler was designed to do however ... it's compiler specific. Nov 25 22:42:23 i guys i'm havin some problem to update the kernel of my BBB Nov 25 22:42:48 when i try to run it at the end he give me this error Nov 25 22:42:58 Resolving rcn-ee.net (rcn-ee.net)... 64.111.100.114 Nov 25 22:42:59 Connecting to rcn-ee.net (rcn-ee.net)|64.111.100.114|:443... connected. Nov 25 22:42:59 ERROR: The certificate of `rcn-ee.net' is not trusted. Nov 25 22:42:59 ERROR: The certificate of `rcn-ee.net' hasn't got a known issuer. Nov 25 22:43:18 i have already update the date at today Nov 25 22:43:40 any tips for solve it? Nov 25 22:47:56 hmm Elray that rings a bell Nov 25 22:48:26 a good bell or a bad one? Nov 25 22:48:43 something to todo with curl Nov 25 22:50:30 check out derek molloy Nov 25 22:50:34 http://derekmolloy.ie/fixing-git-and-curl-certificates-problem-on-beaglebone-blac/ Nov 25 22:50:53 yah the date is good to check.. Nov 25 22:52:45 [C[1;3C/win 32 Nov 25 22:57:08 ah cool i solved doing git pull Nov 25 22:57:19 in cd /opt/scripts/tools Nov 26 00:49:07 Turkey day and the BBB? Are there people out there that are building this Thanksgiving? Geaux BBB! Nov 26 00:51:01 Oh and has anyone connected their BBW/BBB/BBG to an appliance, GE preferably? Nov 26 01:29:24 To the people last night who were looking for ways to share schematics, please view: http://www.digikey.com/en/resources/design-tools/design-tools?WT.z_vanity=designtools Nov 26 01:29:40 ... Nov 26 01:30:06 They have Scheme-It, PartSim, and pcbWEB to view and use. Nov 26 01:30:41 You can also share easily with some of those free programs. Nov 26 02:20:45 How do I connect my BBB to a computer with just ethernet? Nov 26 02:20:51 No router/switch Nov 26 02:21:38 buy a cheap switch. Nov 26 02:21:42 its much easier Nov 26 02:21:50 I was reading this is still possible Nov 26 02:22:01 possible, yes, but its complicated Nov 26 02:22:06 I want to reduce the number of devices I need Nov 26 02:22:14 much the same as doing internet sharing via usb Nov 26 02:32:37 Is there any gsm module which I can use without getting into board design myself ? like those are available for arduino Nov 26 02:35:42 weox, like this .. http://www.yantrr.com/products/m2m-cape-for-beaglebone ? Nov 26 02:36:31 stt_michael: exactly . Nov 26 02:37:42 this is my first time to buying and programming these modules. Do I have access to raw data ? I mean , imagine, GPRS is my physical layer . if I want can I mess with data layer in top of that in these modules ? or they only can used to send and receive sms Nov 26 02:38:09 I assume you can do whatever you like. Its a modem afaik .. Nov 26 02:40:48 http://www.ettus.com/ you can get something like that. should be hardware plug'n play. but the software will be on you... but i think the tracking cape will give you some support on the softwareside too Nov 26 02:40:48 stt_michael: thank again , you made my day . do you think do I need contact the manufacturer about my question ? writing and receiving raw data right on top of GPRS antenna . Somet hing like we do ordinary in linux for example with raw socket . or writing Ethernet driver. Nov 26 02:43:40 weox, take a look at the documentation on their site Nov 26 02:43:49 they look good, actually Nov 26 02:44:41 opensource tools for that are availeble for linux. the hardware documentation should help you to get them running Nov 26 02:45:35 mm sdr Nov 26 02:45:54 uavcam: this is exactly what i want . I am just careful about their if they have such weird constraint.Because theoretically talking they can , and they should provide such access for programmer in (at least in kernel level) Nov 26 02:47:07 weox, if you have specific questions I'm sure you can email them Nov 26 02:47:42 for that kinda module, that kinda price is very reasonable Nov 26 02:47:56 the ettus one? Nov 26 02:48:00 for a COTS solution Nov 26 02:48:11 the tracking cape is out of stock. Nov 26 02:48:11 no, the one I linked :P Nov 26 02:48:17 SDR is another whole game Nov 26 02:50:35 the cape was perfect . I am reading their datasheet to see if there is material about how can I talk board the way i want. Nov 26 02:50:45 about whole SDR thing . I am little confused / Nov 26 02:50:50 what's that Nov 26 02:51:13 its where you do radio decoding/transmission/etc all in software Nov 26 02:51:29 rather than dedicated hardware and analogue rf circuitry Nov 26 02:52:08 stt_michael: oh yeah , that is exact level of complexity I want module hide from me . but also provide me a way to program right on top of physical layer. Nov 26 02:52:34 stt_michael: in network terminology we can call it physicall layer I think , Am i correct ? **** ENDING LOGGING AT Thu Nov 26 03:00:38 2015