**** BEGIN LOGGING AT Wed Apr 12 03:00:02 2017 Apr 12 03:11:12 Does anyone look to linuxcommand.org for info. about Linux in general for the BBB? Apr 12 03:14:23 I am asking for two reasons: Apr 12 03:15:53 ...First, can I use BASH scripting for communication to actuators (motors) from the command line? Apr 12 03:16:54 ...Second, does the BBB allow me to use BASH scripts to open HTML pages on specific ports? Apr 12 03:21:25 I'm sure a sufficiently dedicated (read: crazy) person could do anything in bash, that doesn't necessarily make it a good idea Apr 12 03:23:04 Okay...just checking. Apr 12 03:23:13 I see it has drawbacks. Apr 12 03:23:33 zmatt: What language would you use? Apr 12 03:24:08 for what? Apr 12 03:24:47 HTML running info. from an actuator (motor) attached to the BBB... Apr 12 03:25:01 whats wrong with python .. or .. anything else .. Apr 12 03:25:07 Nothing. Apr 12 03:25:15 I don't really understand what you mean by what you're saying Apr 12 03:25:30 I just wanted to know before I jumped in head-over-heels into BASH... Apr 12 03:25:58 bash is good for process management .. its not a programming language as such .. just a scripting one Apr 12 03:26:30 I was asking b/c Flask through me for a loop. The loop was Flask was good for HTML and GPIO but that servers were not its thing. Apr 12 03:27:02 choosing your tool, is the first step in doing a job .. don't hammer a screw ;) Apr 12 03:27:04 for running a webserver, I'd be inclined to use... a webserver Apr 12 03:28:36 Aw! See, I thought Flask covered it for me. I read and read and read. Finally, I realized that the software was more for other stuff. Apr 12 03:28:58 I mean... Apr 12 03:29:02 * zmatt googles "flask" Apr 12 03:29:14 (since I assume you don't mean the flask security microkernel) Apr 12 03:29:20 Nope. Apr 12 03:29:28 ok, it's some python module Apr 12 03:29:32 Yep. Apr 12 03:31:30 so how exactly did it fail to live up to your expectations? Apr 12 03:32:46 I thought I could use it to control a motor attached to my BBB with remote control or by keyboard. Apr 12 03:32:53 ...via online server. Apr 12 03:33:24 so how exactly did it fail to live up to your expectations? Apr 12 03:33:43 I mean it looks like a simple way to setup a web service Apr 12 03:33:52 Oh? Apr 12 03:34:02 ... Apr 12 03:34:32 (that seems to be its purpose anyway, based on a brief glance at the website and documentation) Apr 12 03:34:38 I got as far as the documentation would allow. It turned into "mySQL" type stuff. Apr 12 03:35:16 For web based pages and things, I think is its goal or their goal. Apr 12 03:35:50 ...Now Apr 12 03:36:18 I could be wrong. Apr 12 03:36:38 ... which sounds like it may or may not be part of what you're asking for... I'm not entirely sure since your problem-statement is still rather vague Apr 12 03:37:23 Okay: I want to use Python to set up a socket to use an online web address to control my motor from the BBB. Apr 12 03:38:14 Tkinter or some other type of module from Python would work but I thought Flask could do it because of it understanding GPIO. Apr 12 03:38:14 I understand the individual concepts you're using, except the way you string them together doesn't make sense Apr 12 03:38:41 in what sense does flask "understand gpio", or have any need to do so Apr 12 03:39:03 Let me use pastebin again. Please hold. Apr 12 03:39:53 I'm assuming you want something like [your computer]----HTTP---->[webservice on BBB]-->[motor attached to BBB] Apr 12 03:40:11 To start! Apr 12 03:40:29 You type very nicely. Thank you, sir. Apr 12 03:40:52 so, flask lets you make a webserver, and lots of people control stuff from python on the BBB Apr 12 03:40:59 Yep! Apr 12 03:41:07 combine the two, and it sounds like you're there Apr 12 03:41:13 Okay...get this! Apr 12 03:42:34 I can use the GPIO on the BBB in the command line of Linux (Debian) to control a normally open switch and get notified via HTML and via e-mail when it opens and stays open. Apr 12 03:43:04 I know...great! But, I do not think it works for motors. Apr 12 03:43:51 sorry, you're deep into vagueness again, and I'm afraid you've run out of support credits with me for today... maybe someone else will help Apr 12 03:44:18 zmatt: Thank you for trying with me. Apr 12 03:49:59 Would I need to use an XBee? Apr 12 03:54:24 ... Apr 12 03:54:33 https://pastebin.com/Zrj0Ph0T Apr 12 03:55:38 ...this is the Door Open, Python script with the "app" from Flask. It uses a normally open door sensor. Apr 12 03:55:43 Now... Apr 12 03:57:16 https://pastebin.com/hf38wyev is the HTML code for the online web address. Apr 12 03:58:00 Could I substitute a motor in place of my door/window sensor? Apr 12 04:01:16 I would need a battery, of course. Apr 12 04:16:39 UPDATED: https://pastebin.com/zFhyV1fu is the Python software for the window sensor attached to the BBBW. Apr 12 04:18:34 UPDATED: https://pastebin.com/TT4pHiFk is the HTML software for the web address at 192.168.7.2:5000. Apr 12 04:29:43 Now... Apr 12 04:30:12 That software works and can be used and found in "Getting Started with Beaglebone." Apr 12 04:30:43 But...can I use it with a motor? Come on, give a brother some permission! Apr 12 05:44:12 Set_: I still don't understand what you're expecting from us... you already seem to have all the ingredients. you want our permission to combine them? blessing? moral judgement? Apr 12 05:46:08 mornin' thinkfat Apr 12 05:48:48 zmatt: I think he just likes to verbalise his thoughts .. like a few too many others I'm finding .. >,< Apr 12 05:49:14 I really dunno why people can't think *in* their heads .. is it really that hard?! Apr 12 05:51:02 hmm, I wonder if I can get away with doing a read() where the "buffer" is actually a memory-mapped fifo port Apr 12 05:51:50 either it'll avoid a superfluous copy, or it cause a kernel panic :D Apr 12 05:52:17 ok I should go wash my brain now Apr 12 05:55:48 or it can just fail with a EINVAL Apr 12 05:56:18 gm Apr 12 05:56:22 ds2: why would it? Apr 12 05:57:04 if the kernel considers it a bad pointer it would be EFAULT Apr 12 05:57:30 but it's a valid pointer Apr 12 06:04:06 zmatt: the omap-sham driver would always use DMA unless it fails to acquire a DMA channel on probe Apr 12 06:04:33 zmatt: is your version using dmaengine? Apr 12 06:08:11 my version? Apr 12 06:08:50 the one from the -bone kernel Apr 12 06:09:07 the one I'm looking at is from the ti-linux-kernel repo on gitorious Apr 12 06:09:07 are there any differences? Apr 12 06:12:14 btw I've been able to identify the wrong answers I got as being unfinalized hashes Apr 12 06:20:28 I figured maybe the hw doesn't support appending a 0-byte final block to finalize the hash, but I've tested it and in fact it does Apr 12 06:23:21 try it Apr 12 06:43:20 ds2: kernel panic, hehe Apr 12 06:44:03 that was just out of curiosity anyway, since there'd be a heap of other potential issues Apr 12 06:47:29 huh Apr 12 06:47:35 that's odd Apr 12 06:47:55 wait I think something else is going on Apr 12 07:03:48 odd Apr 12 07:10:40 resetting the module was causing a lockup... I'll just file it under "quirk" Apr 12 07:12:32 heh, it actually works fine Apr 12 07:12:48 (read()ing into the fifo) Apr 12 07:14:34 even no panic if undersized because the writes are posted hence the bus error just ended up in some L3 interconnect error log that is being ignored, hehe Apr 12 07:14:55 ds2: so, where did your implausible EINVAL hypothesis come from? Apr 12 09:59:25 Hello Anonymous guest Apr 12 11:17:16 hi Apr 12 13:22:00 this article https://en.wikipedia.org/wiki/Write_amplification has information on how to mitigate wear amplification for SSDs. is there similar information (specifically) for microSDs? Apr 12 13:22:01 [WIKIPEDIA] Write amplification | "Write amplification (WA) is an undesirable phenomenon associated with flash memory and solid-state drives (SSDs) where the actual amount of information physically written to the storage media is a multiple of the logical amount intended to be written.Because flash memory must be erased before it can..." Apr 12 13:22:34 sorry, i meant "write amplification" Apr 12 13:25:55 namely, i'm wondering if microSD controllers are implementing some of the same algorithms as those on the SSDs. since the available area of an SSD is much greater than a microSD, the controllers may be less capable. Apr 12 13:55:18 The controllers are less capable Apr 12 13:55:40 You _can_ kill the flash/SD cards with writes, and there is some write amplification, but not as much as for SSD's Apr 12 13:55:59 Most SD cards that I've seen have a 512b sector, you can query that with mmc-tools Apr 12 14:20:04 Spidler: i came up with a model for microsd lifetime that includes WA (write amplification), but the question is, what can i realistically use for WA on a microsd? do you have any ideas on that? Apr 12 14:20:47 actually ssd's seem better on wa nowadays due to various tricks. better meaning at or near 1.0. Apr 12 14:21:13 at least that's what i've read. Apr 12 14:21:30 i was using wa of 10 or 100 for various examples in my model Apr 12 14:21:53 but i just pulled those numbers from where the sun don't shine. Apr 12 14:22:48 also, any word on SLC devices coming down in price? my guess is no. Apr 12 14:33:17 yates: Well.. If we consider that I've got 10+ BBB with dead flash on them due to write errors.. Apr 12 14:33:36 Apr 12 14:34:05 what brand? slc, mlc, tlc? size (are they over-provisioned)? Apr 12 14:34:26 i've read bad things about sandisk's ultra's Apr 12 14:34:30 It's the 4G kingston controller, afaik it's mlc flash, but I'm not too sure as the MMC controller gives crap Apr 12 14:34:39 true Apr 12 14:34:40 It's the built-in flash inside the BBB that's corrupt Apr 12 14:34:58 OH. Apr 12 14:35:10 Problem came, in our case, cause we had all the flash marked as used, even if it wasn't, and didn't truncate empty flash out to the controller Apr 12 14:35:33 This caused writes to happen in a fairly localized space (on the R/W partition) with tons of "empty" space that was marked as "filled" for the controller Apr 12 14:35:45 so you needed the equivalent of a SATA "TRIM" command? Apr 12 14:35:48 This _also_ causes _read_ corruption errors on _other_ and completely unrelated area. Apr 12 14:36:07 The read errors show up as multi-bit faults (20 bits corrupted or more) in a fault Apr 12 14:36:13 And they are _unstable_ in the read Apr 12 14:36:27 So you read & checksum the RO partition, and each time you get subtly different results Apr 12 14:36:37 After a while, it'll stabilize, sometimes even on the correct data. Apr 12 14:36:47 Spidler: is the built-in flash an integrated memory/controller chip? Apr 12 14:36:51 Yea Apr 12 14:37:10 It's a kingston controller that went oops for us. More recent BBB's use a different controller, as that one is out of production Apr 12 14:37:16 running linux? Apr 12 14:37:19 Yes Apr 12 14:37:42 So yes, using `discard` / TRIM on the device will assist and prolong lifetime of these chips Apr 12 14:37:57 I rebooted my beaglebone after removing /uEnv.txt and /boot/uEnv.txt because I want to boot from internal memory and I checked the serial connection to it and the beaglebone is not booting anymore. The lasts line I had in the serial port was : https://gist.github.com/DriesS/93769eaf230d943e043f804a10c7ebe0 Apr 12 14:38:07 serial port is also not replying anymore, what could happened? Apr 12 14:38:26 In our case, what caused it was a small partition with an frequently rewritten SQLite database on it Apr 12 14:38:34 Spidler: is "discard" a command you run on the command-line? Apr 12 14:38:50 Spidler: aha. Apr 12 14:39:04 yates: fstrim Apr 12 14:39:22 yates: fstrim on filesystems, blkdiscard on devices. Apr 12 14:39:35 Spidler: but i thought most controllers nowadays do wear-levelling, which should have mitigated that problem. Apr 12 14:39:38 Mounting ext4/btrfs with the discard mount option too Apr 12 14:39:48 yates: It's the wear levelling that _causes_ the problem Apr 12 14:40:12 how so?!? Apr 12 14:40:18 yates: Rather than returning an EIO or other error to the upper layer when it fails internal ECC due to flash wear, it returns corrupt data. Apr 12 14:40:50 This kingston controller also has a smaller amount of reserved pages than others do ( you see less blocks available from the same flash ) Apr 12 14:41:08 So, it'll be forced to wear level "good" data pages with "bad" ones, causing corruption. Apr 12 14:41:20 well, yeah. Apr 12 14:41:23 Once you overwrite the _rest_ of the device, it works okay. Apr 12 14:41:28 once you're that far gone, all bets are off. Apr 12 14:41:36 So there's a compund set of errors, some of them are bloody stupid. Apr 12 14:41:52 a: when ECC fails in the controller, it returns corrupt data, rather than an Error. Apr 12 14:42:14 b: small buffers, late wear levelling causes read corruption of other pages Apr 12 14:42:57 c: flash controller relying on the system to do ? discard / trim, in order to have a wear-levelling pool Apr 12 14:43:23 d: me, for not explicitly discarding the empty data pages we already had Apr 12 14:43:55 Spidler: well thanks much for sharing your experience. this irc conversation is going into my log. Apr 12 14:45:24 yates: There's some graphs and stuff about it, but the errors come in clusters, some worse than others. They can arrive much sooner than you expect. Apr 12 14:45:32 i'm still a little confused on why wear-leveling wouldn't help, even if you neglected to trim. wouldn't wl switch high-rate-write LBAs with static LBAs (if it is static wl)? Apr 12 14:45:35 1TB on a 4GB device isn't that much. Apr 12 14:45:52 yates: Well, that's the theory, in practice it seems to not work. Apr 12 14:46:12 maybe the controller didn't implement static wl? Apr 12 14:46:25 Could well be Apr 12 14:46:42 As said, the controller in the Early BBB's is discontinued, and they have been replaced with another Apr 12 14:46:51 So others will probably not see the same trouble as me Apr 12 14:47:16 You can also reconfigure the BBB flash to be 2GB SLC mode, which ought to solve it as well Apr 12 14:47:18 yeah, my observation is that this stuff is changing pretty quickly. i would expect significant differences between today's parts and parts 3+ years old. Apr 12 14:47:49 Spidler: i saw that mentioned somewhere online, yes. Apr 12 14:47:51 But seriously, flash doesn't store your data Apr 12 14:47:57 huh? Apr 12 14:48:04 just adds weight to the board?!? Apr 12 14:48:25 You write bytes there, and flash magically recomposes a piece of garbage with tons of interesting algorithms to get something back that's hopefully what you stored Apr 12 14:48:39 Consider that it's built in effect _assumes_ 10-15 bit faults per read. Apr 12 14:48:44 That's.. .tons of error rate Apr 12 14:48:57 Spidler: yes, and that translation is more convoluted with tlc... Apr 12 14:48:57 There's so much error correcting magic in there that I'm scared. Apr 12 14:49:21 So yea, it's not really storing your data. It's reshaping white noise to look mostly like your data, and then filtering it back again Apr 12 14:49:52 i read recently that they often update the controller at the manufacturer, things change so fast and bugs are so prevalent.. Apr 12 14:49:59 the controller firmware, that is. Apr 12 14:50:10 Spidler: ha! Apr 12 14:51:35 i guess the fec techniques are getting pretty sophisticated. probably ldpc codes, inner/outer codes, etc. Apr 12 14:52:07 i've all but forgotten the coding theory i learned at NCSU... Apr 12 14:54:03 Seriously, I thought grey coding was magic when I studied it Apr 12 14:54:30 Erasure coding in general, parchive, etc. Apr 12 14:55:20 grey coding is trivial compared to fec... Apr 12 14:55:30 Mmm Apr 12 14:55:35 block codes, convolutional codes, linear codes, systematic codes, ... Apr 12 14:55:44 Also, modern SSD's use RAIN as well, which is another layer alltogether. Apr 12 14:56:03 well, _some_ do Apr 12 15:03:12 yates: https://cseweb.ucsd.edu/~swanson/papers/DAC2011PowerCut.pdf is also interesting for you Apr 12 15:23:00 zmatt: hmm what could be responsible for L4LS_GCLK being active? Apr 12 15:23:14 * thinkfat working on DS0 support Apr 12 15:23:52 zmatt: I found only ELM as a user of the clock, but that cannot be all Apr 12 15:32:10 ah, ok Apr 12 15:39:52 Spidler: interesting. it could be this trumps all the write cycle issues. Apr 12 15:40:34 L4LS_GCLK ? ... like, a lot? Apr 12 15:42:05 btw, I've also managed to get wrong answers from the kernel sha256-neon driver if I use sendfile() from a file of zero-bytes instead of splice() from a pipe... so possibly there's just something fishy going on with that api Apr 12 15:42:58 meanwhile, a first quick test using uio, just writing 0-bytes into the hw engine, yielded around 160 MB/s for sha-256, possibly more Apr 12 15:50:17 Spidler: btw I noticed another perk of converting the eMMC to SLC mode Apr 12 15:50:19 it's FAST Apr 12 15:51:59 even with the "write reliability" bit set Apr 12 15:53:24 thinkfat: if you have a dump of prcm I can probably point out some likely suspects if you want Apr 12 15:55:29 I'd expect that clock to be one of the last ones to remain active, as it's the clock for the L4LS itself Apr 12 16:11:57 thinkfat: take a look at pm33xx-core.c in latest linux patch series, function am33xx_suspend https://patchwork.kernel.org/patch/9650811/ Apr 12 16:12:22 thinkfat: perhaps that's what is going on? there are also lots of things that could be active inside as zmatt said Apr 12 20:02:03 hmm, what was the typical "ping time" to (L3) peripherals again? around 150ns or something? Apr 12 20:10:58 zmatt: Really? Now youv'e got my attention :) Apr 12 20:13:10 Spidler: hmm? Apr 12 20:15:49 for the life of me i can't figure out why my scopes gnd is so special that my device only works if its connected to the wall warts gnd Apr 12 20:16:02 actually the bbb gnd worked that way too Apr 12 20:16:41 ayjay_t: ? Apr 12 20:16:47 ayjay_t: what do you mean? Apr 12 20:17:30 i have a wallwart, +5V, but the device i'm powering doesn't work if i don't connect some other ground to the wallwarts - pin Apr 12 20:17:40 and i've tried two wallwarts Apr 12 20:18:51 can you clarify your setup a bit more? Apr 12 20:20:02 a wallwart is typically isolated compared to everything else, so it doesn't have a "ground" until you declare one of its pins to be so Apr 12 20:20:35 when interconnecting stuff, always make sure they agree on a common ground potential Apr 12 20:20:54 yeahhh i mean, the wallwart is supposed to power the whole board Apr 12 20:21:07 two smps, 1 for two uC, 1 to drive a backlight Apr 12 20:21:34 if i connect the oscillscope ground to the wallwart ground and boot it up, it works 100% Apr 12 20:21:44 but the wallwart by itself, the whole device isolated, no luck Apr 12 20:22:26 what is the device connected to, besides power? Apr 12 20:23:21 if not grounded in any way the potential may be wildly bouncing up and down compared to e.g. the nearest earth ground Apr 12 20:23:38 Yeah its not connect to anything Apr 12 20:23:47 it's just a 5Vdc to power a couple lcd screens Apr 12 20:25:35 and you're saying you need to tie the negative output lead of that power supply to ground (safety ground / earth) to get it to function? Apr 12 20:26:29 if so, I'd be inclined to slowly back away from that supply :P Apr 12 20:27:47 hahah wait what Apr 12 20:28:04 i mean, as long as its tied somewhere... Apr 12 20:28:26 it actually looks like it's oscillating (i can tell by how the lcd backlight fluctuates) without the oscope ground Apr 12 20:29:18 zmatt: Was wondering about the speed, I was of the idea that SLC would be slower. Apr 12 20:34:42 slower? hah Apr 12 20:36:39 on these latest kingstons (EMMC04G-S100) I measured 10 MB/s write speed in default MLC mode Apr 12 20:39:04 e.g. Apr 12 20:39:05 67108864 bytes (67 MB, 64 MiB) copied, 5.79718 s, 11.6 MB/s Apr 12 20:39:20 using: dd if=/dev/zero oflag=direct of=/dev/mmcblk1p1 bs=4M count=16 Apr 12 20:39:31 where that partition had been previously erased with blkdiscard Apr 12 20:39:41 that's pretty much the optimal circumstances you can make I think Apr 12 20:40:15 now on a BBB where the eMMC, same type, has been SLCified: Apr 12 20:40:22 67108864 bytes (67 MB, 64 MiB) copied, 2.3531 s, 28.5 MB/s Apr 12 20:41:43 this is fully in line with expectations to be honest, the advantage of MLC is capacity, and capacity alone Apr 12 20:49:02 on an unrelated note, I measured a ping time to the hash engine (an L3 peripheral) of 115 ns with cpu running at 1GHz, and 193 ns with cpu running at 500 MHz... Apr 12 20:49:51 if my math is right that means it's spending only 37 ns in the L3 clock domain, and 78 cycles in the cpu clock domain... o.O Apr 12 20:50:09 78 cycles, wtf is that 32-bit read doing all that time, having a picknick? Apr 12 20:57:04 would it be... normal to add a very high resistance between the positive and minus terminals to discharge any lingering charge after the circuits unplugged? Apr 12 21:01:30 i mean thats effecitvley what happens with the connection sensor i guess right? normally it would be grounded until the dc jack is connected Apr 12 21:03:17 depends on application but discharging power rails when disabled is afaik quite common. the outputs of the TPS65217 PMIC on the BBB are in fact discharged by 250-430 ohm to ground whenever they are disabled Apr 12 21:03:32 zmatt: well I found ELM of course, but I guess GPIOs are also in the PER_L4LS clock domain? Apr 12 21:03:54 thinkfat: everything on the L4LS interconnect Apr 12 21:04:10 and the L4LS interconnect itself Apr 12 21:04:30 zmatt: the interconnect is handled by the M3 code Apr 12 21:04:45 of course Apr 12 21:04:52 but yeah basically anything can block it Apr 12 21:06:21 but if you're preparing to power off PD_PER when all of them should be disabled anyway Apr 12 21:07:24 oh, keep an eye on uarts, iirc there was a thing making them not acknowledge idle under some circumstances Apr 12 21:07:40 (the solution was easy though: reset the uart) Apr 12 21:08:45 yeah, if an uart has had DMA enabled at any point, it will no longer acknowledge an idle request until you reset it Apr 12 21:09:01 (advisory 1.0.41) Apr 12 21:14:08 thinkfat: if you can produce a hexdump of the prcm registers (or just 0x44e00000 - 0x44e0014f should suffice) I can give an assessment if you want Apr 12 21:14:38 zmatt: nevermind. looking at your memory map, basically every peripheral on the chip is in the L4LS Apr 12 21:14:45 zmatt: means I need to treat them all Apr 12 21:16:58 well some stuff is on the L3, but most of those are still in PD_PER :) Apr 12 21:17:23 everything except rtc and wakeup-domain peripherals needs to shut down Apr 12 21:20:23 meh i prob need better grounding in general... Apr 12 21:20:32 thinkfat: if you want a quick listing/verification, maybe my prcm header is of use -> https://github.com/dutchanddutch/jbang/blob/master/include/ti/subarctic/prcm.h Apr 12 21:21:47 thinkfat: every Mod and IMod in the peripheral domain should have .status() == Module::idle and every IMod should have .standby() set Apr 12 21:22:25 even if you don't use the header directly, grepping it for the mods and imods is probably the quickest way to produce a checklist ;) otherwise it's easy to overlook an initiator module that's not in standby Apr 12 21:42:08 bbl Apr 12 22:10:56 Hello Apr 12 22:11:57 Hello Apr 12 22:13:04 I have a question about beaglebone black. Is this the right place to ask? Apr 12 22:30:52 Hello Apr 12 22:32:26 Hi, I've had some experience with Raspberry Pi. Apr 12 22:32:26 With Raspberry pi I could control a servo through a digital pin using pwm. For example he used the pin 14, 15, 18 or with any other pin GPIO. Apr 12 22:32:26 I wonder if with beaglebone black I can do the same, ie using any GPIO pin. Apr 12 22:32:26 Thank you Apr 12 22:33:43 Question published in https://groups.google.com/forum/embed/?place=forum%2Fbeaglebone&showsearch=true&showpopout=true&showtabs=false&hideforumtitle=true&parenturl=https%3A%2F%2Fbeagleboard.org%2Fdiscuss&afterlogin#!category-topic/beaglebone/beagleboardorg-beaglebone-black/ktfp1YIaZUw Apr 12 23:04:33 diegoariel: not all pins have native pwm capability Apr 12 23:06:01 there are lots of ways of making more pwm pins if really necessary, but the easiest is to use one of the pins that have "eHRPWM A/B", "eCAP", or "Timer" functions as mux options Apr 12 23:06:11 listed in descending order of fanciness Apr 12 23:06:43 if I remember correctly there are 13 of such pins Apr 12 23:16:02 don't forget M0 and PRUs Apr 12 23:16:03 :D Apr 12 23:16:12 or for extra fun, the LCD pins Apr 12 23:19:30 Clear. With pin p8_13, p8_19 for example it is easy to control a servo. Apr 12 23:21:26 But if for example I want to use p8_16 or p8_18 that are GPIO or any other GPIO it surely is not that simple. I'll have to configure something else I think. Apr 12 23:30:33 diegoariel: what sort of pwm frequency and desired resolution of duty cycle are you looking for? Apr 12 23:32:34 p8.16 and .18 are indeed not the most ideal pins for PWM, but they could still be PWM'd "manually" using PRU or DMA Apr 12 23:33:02 why those specific pins? Apr 12 23:33:26 ds2: s/M0/M3/ ? Apr 12 23:35:10 blah Apr 12 23:35:11 yes Apr 12 23:35:13 the PM chip Apr 12 23:35:24 <--- head buried in BLE at the moment Apr 12 23:35:34 it's not really in the best place for that role though Apr 12 23:36:52 diegoariel: the easiest way to get a whole bunch of additional pwm outputs (that are still accurate and high-frequency) would be using PRU. there are quite a few pins which can be used as PRU outputs Apr 12 23:37:06 if you need a lot of PWMs.... Apr 12 23:37:35 w/o knowing what the PWMs are for, it is hard to make suggestions Apr 12 23:37:40 yeah Apr 12 23:39:36 zmatt: what do you think is the minimal amount of I/O for a barely useful AM335x design? Apr 12 23:39:39 I need to control as many servos as possible for a project that needs more than 10 servos. How much is the maximum number of servants you could control? Apr 12 23:40:13 servos as in RC servos or real industrial servos? Apr 12 23:40:42 this http://www.hobbyking.com/hobbyking/store/__46989__Trackstar_TS_500HD_Analog_Metal_Gear_Racing_Servo_27_3kg_0_22sec_188g.html Apr 12 23:41:04 those things.... that's a pretty slow PWM Apr 12 23:41:37 if you are clever, you can probally run 16 of them off the LCD controller Apr 12 23:41:54 then you got 2 EHPWM channels, each has 2...plus the timer and the regular PWM stuff Apr 12 23:42:10 I think at least 16 PRU pins are free after taking out all those Apr 12 23:42:22 might be able to pull out another 8 from the M3 Apr 12 23:42:25 so... do the math :D Apr 12 23:42:50 and if u must, the SPI ports can be abused for PWM Apr 12 23:43:05 ds2: so .. 30? Apr 12 23:43:29 or are we nearly up to 50.... XD Apr 12 23:43:48 > 50 Apr 12 23:43:49 and that's without multiplexing even! Apr 12 23:43:55 other things can be abused for more channels Apr 12 23:44:08 the PRU can drive other pins...given that you are doing things in 20mS chunks Apr 12 23:44:19 20mS .. wow .. a year! Apr 12 23:44:29 RC servos are slow Apr 12 23:44:33 sure are Apr 12 23:45:40 Well, good quantity. For now the maximum is 20 servos and a pair of sensors. Any tutorial on how to configure the GPIO to control the servos? Apr 12 23:46:28 why are you using GPIOs? Apr 12 23:46:36 https://learn.adafruit.com/controlling-a-servo-with-a-beaglebone-black/overview maybe? Apr 12 23:46:39 use the HW as much as possible Apr 12 23:48:30 I will use EHRPWM. But I can control only 6 with them. Apr 12 23:49:30 I have done this example. Everything went well. Apr 12 23:52:39 yikes angstrom .. Apr 12 23:52:44 abot time they updated that Apr 12 23:52:48 been debian for Years now Apr 12 23:54:44 ok 8 pwm chans via the adafruit lib currently .. Apr 12 23:55:54 ds2: LCD controller is awkward for pwm because of the mandatory sync/blanking periods Apr 12 23:56:30 ds2: it would have been much more versatile if those could have been configured to 0, or some option to keep outputting frame data during blanking and sync Apr 12 23:56:49 ds2: and I don't really understand your question about minimal I/O Apr 12 23:57:09 Yes 8. The problem is that I want to control more servants, that's why I look for which pins are the ones I could use. Apr 12 23:58:24 http://www.embedded-things.com/bbb/wireless-servo-control-part-3-pwm-servo-control-with-the-bbb-pru/ Apr 12 23:59:20 there are 6 eHRPWM outputs, 4 timer outputs, and 4 eCAP instances of which one unreachable (unless you get creative, iirc you can pick it up on the jtag pads) Apr 12 23:59:29 13 hardware PWM outputs easily reachable Apr 13 00:00:09 https://github.com/omcaree/bbb-prupwm - 24 channels?! Apr 13 00:00:27 does it use pru outputs or regular gpios? :) Apr 13 00:00:39 zmatt: haven't looked .. waaaay too tired Apr 13 00:00:48 speaking of .. as its 1am .. think I should log some Zzzz...s Apr 13 00:00:53 * zmatt checks the PRU tab of spreadsheet Apr 13 00:02:20 g/l and happy coding/etc XD nini! Apr 13 00:02:23 yep there are 24 pru outputs exactly on the headers Apr 13 00:02:38 zmatt: yes but for RC servo, that isn't an issue... Apr 13 00:02:39 22 if you want to keep eMMC working Apr 13 00:02:52 zmatt: have you seen the pocket bone? Apr 13 00:03:11 I have, at least some pcb layout thereof a while ago Apr 13 00:03:11 but one of the PRU shares its pins with the LCD signals Apr 13 00:03:34 zmatt: would it be consider "useful" for a board with less IOs brought out then the pocket bone? Apr 13 00:04:05 is the pocket bone useful? ;P Apr 13 00:04:13 it all depends on application in the end Apr 13 00:04:29 e.g. look at the USB Armory... such a terrible waste Apr 13 00:04:50 and yet, it has the I/O it needs for its purpose and a few to spare Apr 13 00:05:34 zmatt: *nod* trying to throw together a 1 layer PCB Apr 13 00:08:15 the question is purpose... e.g. USB Armory has a particular goal in mind and simply uses the I/O it needs for it, whereas the beaglebone is meant as a blank canvas for creating things, hence exports as much as possible Apr 13 00:15:26 Thanks for your help. **** ENDING LOGGING AT Thu Apr 13 03:00:03 2017