**** BEGIN LOGGING AT Fri Aug 16 03:05:29 2019 Aug 16 06:08:32 please let me know which AQEMU config is the most nearest to the BBB? Aug 16 06:08:40 how to emulate it? Aug 16 06:17:34 none Aug 16 06:21:16 -M beagle Aug 16 06:21:40 in qemu-linaro Aug 16 06:21:42 totally different board Aug 16 06:22:19 that's the omap3-based beagleboard Aug 16 06:26:20 adding qemu support for omap3 in general and beagleboard in particular was indeed some work in progress a while ago (I have no idea how far they got or how well it works), and that work got merged into linaro's branch of qemu, which seems to have been abandoned more than 5 years ago Aug 16 06:27:50 making qemu able to emulate the AM335x would be a mountain of work, and I doubt much can be reused from the omap3 work (even if we ignore for a moment that that work is more than 5 years old) Aug 16 06:28:06 at most some minor peripherals I think Aug 16 06:29:12 BBB is OMAP4? Aug 16 06:29:34 AM3358 Aug 16 06:34:39 it does inherit some stuff from OMAP4, but it's still very very different Aug 16 06:34:58 (it more closely related to the DM814x) Aug 16 06:40:27 but why do you think it is more secure than X86 P1-P3? Aug 16 06:44:33 I never made such a blanket statement because it would be a meaningless one. what do you mean by "secure" ? Aug 16 06:47:18 x86 in general however is a mess of complexity (which is generally not great for security). more problematic however is its system management mode, running supremely privileged code outside of sight of the OS, with said code provided by BIOS and known to be often quite crappy Aug 16 06:47:58 also with P1-P3 do you mean Pentium I-III ? those are ancient processors, which also means you'd be using an ancient motherboard and ancient BIOS. yikes Aug 16 06:49:57 at least in recent times there has been quite a bit of research into BIOS vulnerabilities and pressure on BIOS vendors to fix their shit Aug 16 06:55:53 yes, Pentium 1 (1995) - Pentium 3 (about 2001) Aug 16 06:56:14 there are a few boards supported in open source FreeBIOS Aug 16 06:56:31 at least it is possible to review what happens their Aug 16 06:56:36 *there Aug 16 06:57:03 for a newer platforms like Core2 Duo/Quad there is Libreboot Aug 16 06:57:11 completely open source too Aug 16 06:58:38 I am worried about newer chips, because they have to complex and large microcode Aug 16 06:58:46 most likely with a trojan Aug 16 06:59:16 add here IntelME Aug 16 06:59:25 device firmwares, etc. Aug 16 06:59:37 all top secret blobs Aug 16 07:00:03 Pentium 1 microcode is too simple compared to current CPUs Aug 16 07:00:45 and there are some microcode changes only in P2-P3 since Pentium Pro Aug 16 07:01:09 and significant changed towards backdoors and may be even trojans in P4 Aug 16 07:02:18 I don't think there's ever been any (intentional) backdoor found in any processor from Intel or other vendor Aug 16 07:02:32 if you have other information, feel free to to provide a reference Aug 16 07:04:22 as for backdoors there was a god mode even in VIA C3 Aug 16 07:04:34 most likely all X86 have something like it Aug 16 07:04:45 I asked for references, not more unsubstantiated statements Aug 16 07:04:59 As for trojans there is IntelME, though it is not on a CPU? Aug 16 07:05:38 the word "backdoor" implies a mechanism that is both covert and intentional Aug 16 07:06:05 C3 god mode is googled easily on demand, do you expect other X86 miss it? Aug 16 07:06:21 even AllWinner has root escalation Aug 16 07:06:51 just Intel and AMD are more smart to hide it better Aug 16 07:07:03 more complex instruction sequence Aug 16 07:07:08 harder to guess Aug 16 07:07:11 yada yada, again you just seem to be stringing together random things you've read about glued together with rampant paranoia Aug 16 07:07:20 again, provide a credible reference Aug 16 07:07:43 I am not aware of about AMD and Intel regarding CPU directly Aug 16 07:07:44 if a true backdoor were found, it would be a HUGE fucking deal so it should be trivial to give a good reference Aug 16 07:08:03 though anyone knows about IntelME and PSP Aug 16 07:08:17 I know what Intel ME is, I haven't heard of any backdoor in it Aug 16 07:08:25 and AMD seems to have it directly inside its CPU though? Aug 16 07:08:53 It is reported IntelME can be powned via USB Aug 16 07:09:02 09:04 <@zmatt> I asked for references, not more unsubstantiated statements Aug 16 07:09:50 https://security.stackexchange.com/questions/173283/how-to-protect-mitigate-intelme-csme-jtag-attack-over-usb Aug 16 07:12:14 "the researchers manage to debug the IME processor itself via USB DCI, which is pretty awesome, but USB DCI is turned off by default, like one of the researchers states" Aug 16 07:12:48 a debug interface that requires physical access and is turned off by default is not a "backdoor" :P Aug 16 07:13:34 there are so many different spectres, intelmes, etc. that I would prefer to have something without them if even told they all are super secure and to improve all aspects of my life Aug 16 07:14:06 physical access - just connect an android - it is Aug 16 07:14:27 disabled for someones, and enabled for others, that's as always Aug 16 07:15:04 having it right now Aug 16 07:15:09 android connected Aug 16 07:15:15 "enabled for others" => reference? Aug 16 07:15:19 and not happy with it Aug 16 07:15:37 it is most likely too secret, top secret Aug 16 07:15:54 enabled only for those who regulate Intel Aug 16 07:15:59 NSA and above Aug 16 07:16:10 "To provide additional security, the DCI interface is disabled by default per Intel specification and can only be enabled with user consent via BIOS configuration" Aug 16 07:16:28 so you need physical access *and* modify BIOS settings Aug 16 07:16:36 at that point, your machine is fully owned anyway Aug 16 07:17:05 and again I asked for a reference, not your imagination Aug 16 07:17:05 please explain last phrase Aug 16 07:17:19 I am not a native English, just learning Aug 16 07:17:47 I have some experiences of being slightly hacked and cannot explain it Aug 16 07:18:02 how it was possible without hardware backdoors Aug 16 07:18:44 because all software sucks Aug 16 07:18:59 https://medium.com/message/everything-is-broken-81e5f33a24e1 Aug 16 07:18:59 I was on Debian Aug 16 07:19:03 now on Devuan Aug 16 07:19:09 and will try OpenBSD too Aug 16 07:19:25 if OBSD does not help I do not know what to do then Aug 16 07:19:29 may be GUIX Aug 16 07:19:36 Libreboot, Freeboot Aug 16 07:19:38 BBB Aug 16 07:19:54 anyway, I'm really done with this conversation and your confused paranoia in general. I'm going to do something useful. bye Aug 16 07:19:57 even no thoughts about Talos2 Aug 16 07:20:21 I have experienced many attacks Aug 16 07:20:34 and was not ready to defend myself Aug 16 07:20:44 trying to find some methods Aug 16 07:21:34 these attacks were not to destroy everything on my computers, but rather to indicate how weak they are Aug 16 07:21:47 in terms of security Aug 16 07:22:12 now I need at least a secure terminal where to connect keys like Nitrokey Aug 16 07:22:38 and then lets see if anything improves, though I am not sure anymore Aug 16 07:32:08 ok, please lets change topic of discussion Aug 16 07:32:59 can BBB be bricked by writing to eMMC? Aug 16 07:33:11 no Aug 16 07:34:04 say if uboot replaced by incorrect one then BROM is still able to boot from SD after pressing some button, right? Aug 16 07:34:47 just seen it on forums people discusses they were afraid to flash eMMC because of bricking Aug 16 07:35:03 they were wrong therefore Aug 16 07:35:07 I already explained this earlier, I mentioned which boot devices are examined by bootrom in which order Aug 16 07:35:09 yes they were wrong Aug 16 07:35:21 thanks Aug 16 07:35:52 you often tell software is not secure enough Aug 16 07:35:55 and what to do? Aug 16 07:36:11 write own bare metal programs in C? Aug 16 07:36:57 hey, if you consider that to be a good option, go for it :P Aug 16 07:37:28 for most users there's not a great deal they can do other than making sure to install updates Aug 16 07:39:30 anyway, really afk now Aug 16 07:42:37 hm, hopefully OpenBSD finally will end my research tries Aug 16 07:43:27 there were so very few public exploits regarding OBSD Aug 16 07:43:59 unless there are backdoors Aug 16 15:02:06 hi all Aug 16 15:02:39 i am doing example with bbb Aug 16 15:03:05 is it possible for someone help me Aug 16 15:03:38 i want to connect ad5535b (adc)to bbb with spi Aug 16 15:04:00 what is spi commAND javascript Aug 16 15:04:09 thank you in advance Aug 16 18:38:08 I am looking for anybody who understands the ADC system of the beaglebone Aug 16 18:38:19 i.e. the "touchscreen controller" Aug 16 18:38:42 I am using the PRU to cue acquisition in a carefully timed way Aug 16 18:39:04 based on some external trigger or such? Aug 16 18:39:15 yes Aug 16 18:39:27 I have found that when measuring a "constant" signal, I get small extraordinarily systematic undulations on the voltage line Aug 16 18:39:48 the voltage reports numbers between 0 and 4096, and these are undulations of about 40 Aug 16 18:40:04 I would love to show a picture; any pastebin for that? Aug 16 18:40:13 imgur? :P Aug 16 18:40:50 is your sample time sufficiently long? Aug 16 18:41:12 gimme a sec, I'll show you... Aug 16 18:41:54 but yeah I do vaguely recall seeing some non-white noise too when I looked into it, a long time ago Aug 16 18:42:14 here is a particularly long sample: https://pasteboard.co/IsZPdtg.png Aug 16 18:42:31 oh on such a long interval Aug 16 18:42:33 that's really odd Aug 16 18:42:41 what's the adc configuration look like? Aug 16 18:43:03 That dataset is produced by repeating the exact same measurement 16 times; there's usually more noise than that Aug 16 18:43:10 hold on, I have more details Aug 16 18:43:11 :-) Aug 16 18:43:22 how sure are you that the voltage is actually constant? Aug 16 18:43:49 here is a close-up: https://pasteboard.co/IsZPYZA.png Aug 16 18:44:10 what's your sampling interval? Aug 16 18:44:26 here is the same thing averaged over 128 repetitions: Aug 16 18:44:27 https://pasteboard.co/IsZQcRw.png Aug 16 18:44:40 As to your questions Aug 16 18:44:42 wait what Aug 16 18:44:49 you mean this pattern is periodic? Aug 16 18:44:54 with what as reference point? Aug 16 18:45:13 I always get the exact same basic undulation shape for a "constant" voltage Aug 16 18:45:30 lower constant (from a power supply) gives same structure, just lower integers Aug 16 18:46:04 These undulations are apparent when I have "real" data, too Aug 16 18:46:10 again, what's your reference point (in time) to be able to perform 128 measurements and get the same thing each time (apart from noise) Aug 16 18:46:26 My reference point is "the beginning of the measurement" Aug 16 18:46:26 because the pattern itself is clearly not periodic Aug 16 18:46:46 what's the "start" ? (where it's high for a while) Aug 16 18:46:58 well Aug 16 18:47:21 I have a kernel running on a bunch of beaglebones waiting for signals on GPIO Aug 16 18:47:32 the "start" is the moment that another beaglebone sends the click Aug 16 18:47:37 for the first time Aug 16 18:47:59 before we go in too many directions, note the following: Aug 16 18:48:12 my "typical" sampling rate is 50us Aug 16 18:48:32 that is, the clock BB sends blips to cue a single point measurement every 50us Aug 16 18:48:42 but, I get the *exact* same structure if I speed it up to 25us Aug 16 18:48:46 or slow it down to 100us Aug 16 18:48:55 the *exact* *same* *structure* Aug 16 18:49:06 Now for the kicker Aug 16 18:49:13 that's certainly fascinating Aug 16 18:49:14 the first dropoff always occurs around 768 samples Aug 16 18:49:29 the second... 2304 Aug 16 18:49:38 the third: 3072 Aug 16 18:49:46 what was the actual voltage in this case? Aug 16 18:49:53 these are all multiples of 768 Aug 16 18:50:08 * dcmertens checks scope Aug 16 18:50:38 about 1.25V Aug 16 18:51:15 ehh, so these numbers are also waaay too low, even at the "high" level ? Aug 16 18:51:48 wait wait Aug 16 18:51:56 no, they are right on Aug 16 18:52:07 it appears that my BBs have a nonzero intercept in the voltage system Aug 16 18:52:22 ehh what? Aug 16 18:52:26 about 100mV Aug 16 18:53:07 When I feed in an oscillating signal that runs from about 200mV to 1.7V, I can measure withe my scope and with the BBs Aug 16 18:53:32 and it turns out that the BB voltage system measures linearly, but a reading of 0 on the BB would occur for nonzero voltage Aug 16 18:53:49 so, you mentioned pru is triggering the adc, so I assume pru is also responsible for reading the adc data? Aug 16 18:53:58 correct Aug 16 18:54:18 it reads it into shared memory and cues the CPU every once in a while to copy stuff down Aug 16 18:54:34 so if you instead use the linux driver, what value does it read? :P Aug 16 18:54:44 haha, good question Aug 16 18:54:49 lemme check Aug 16 18:55:14 the fact that the pattern is independent of your sample interval strongly suggests something weird is going on with software Aug 16 18:55:40 I'd also be interested to know what your adc configuration is Aug 16 18:57:09 Hmm, bother, I haven't read the voltage via Linux in a long time and can't quite drum up the right command Aug 16 18:57:35 look in /sys/bus/iio/devices Aug 16 18:57:45 yeah... Aug 16 18:57:46 there's probably only one iio device, which would be the adc Aug 16 18:57:55 which has attributes for each input Aug 16 18:58:04 from which you can read the raw value Aug 16 18:58:45 When I try, it says "cat: in_voltage2_raw: Resource temporarily unavailable" Aug 16 18:58:52 that's odd Aug 16 18:58:56 probably because the PRU claimed it Aug 16 18:59:05 although it should have let go by now Aug 16 18:59:07 ehh Aug 16 18:59:25 if the linux driver for the adc is loaed, pru must not touch it Aug 16 18:59:30 *loaded Aug 16 18:59:48 what? Aug 16 19:00:14 that's like effectively using two drivers for the same peripheral at the same time :P Aug 16 19:00:39 that never came up in my reading Aug 16 19:01:05 ? Aug 16 19:01:09 well Aug 16 19:01:19 yes, but if only one is using it at a time Aug 16 19:01:25 why would it be a problem? Aug 16 19:01:41 I *never* use the Linux driver, so I don't imagine there would ever be a conflict. :-) Aug 16 19:01:43 linux would still receive interrupts from it Aug 16 19:02:05 that might explain what I'm seeing Aug 16 19:02:23 How do I unload the linux driver? Aug 16 19:02:41 there's a config var in /boot/uEnv.txt to disable the adc, you just need to uncomment it Aug 16 19:02:58 but doesn't that disable ADC entirely? Aug 16 19:03:05 * dcmertens reads /boot/uEnv.txt Aug 16 19:03:36 okay, I see it Aug 16 19:03:40 that does mean you'll need to enable it yourself before configuring it, or maybe a nicer solution is a miniscule custom overlay that force-enables the ADC (so you don't have to worry about its powermanagement) but without any driver Aug 16 19:04:20 Hmm... Aug 16 19:04:41 I don't mind enabling it if I know what bits to flip on the PRU Aug 16 19:05:13 I could look that up, or I could make that 4-line overlay for you... it might be better to not mess with prcm settings behind the kernel's back Aug 16 19:05:36 it probably won't find out, but if it does found it it does get a bit angry iirc Aug 16 19:05:43 *does find out Aug 16 19:05:59 no, I can just disable it on Linux side via /boot/uEnv.txt Aug 16 19:06:15 I see it, I think, IRQWAKEUP Aug 16 19:06:21 ? Aug 16 19:07:24 according to the technical reference manual, page 1850, IRQWAKEUP register controls "Wakeup generation for HW Pen event." Aug 16 19:07:34 whatever the hell that means Aug 16 19:08:07 it's to request the system to wake up from suspend when it detects a pin touch on the touchscreen (when used as touchscreen controller) Aug 16 19:08:12 *pen touch Aug 16 19:08:30 that's sorta what I thought. Hrm. So that's not the right register, then Aug 16 19:08:47 anyway, try this: grab https://github.com/mvduin/overlay-utils and create a file "adc-force-enable.dtsi" containing this one-liner: Aug 16 19:08:57 &tscadc { ti,no-idle; }; Aug 16 19:09:41 ok Aug 16 19:09:57 then do "make adc-force-enable.dtbo", optionally copy the dtbo to /lib/firmware, and configure it into e.g. the dtb_overlay variable of /boot/uEnv.txt Aug 16 19:11:45 Bah, "dtc: not found" Aug 16 19:11:49 soo... how exactly did you (re)configure the adc for your use? Aug 16 19:11:59 apt-get install device-tree-compiler Aug 16 19:12:00 I programmed it in the pruasm Aug 16 19:13:00 gimme a sec, I'll paste it for you Aug 16 19:13:02 yes, but more details please... since the linux driver would have already initialized and enabled it, and iirc reconfiguring can be slightly trickier than configuring it the first time (especially since there's no way to reset the adc) Aug 16 19:14:01 https://nopaste.xyz/?df3ecfa655cacc59#GADFDdGmIUmlumV/tbrPTzNWAcV8kYmFpmVQzJndnRQ= Aug 16 19:14:03 unless it keeps the adc disabled by default (until needed), that's possible I guess, haven't really looked at the linux driver much Aug 16 19:14:59 why would you want to toggle between the two fifos? o.O Aug 16 19:16:12 to make sure I don't overwrite my data while copying it Aug 16 19:16:24 ??? Aug 16 19:16:59 I think that's the only way to reliably get high sampling rates? Aug 16 19:17:06 I don't quite remember Aug 16 19:17:16 I wrote this a year ago Aug 16 19:19:10 yeah Aug 16 19:19:35 you mean a fifo overflow? each fifo is 64 samples, is that not enough? Aug 16 19:19:35 the idea was that I wanted to give myself as much time as possible to copy the data from the fifo Aug 16 19:19:48 no, not fifo overflow Aug 16 19:20:10 then what? Aug 16 19:20:20 let me try to explain the basic flow Aug 16 19:20:43 as soon as I get the external trigger to read data, I turn on the ADC for one-shot Aug 16 19:20:54 then I wait until I have data Aug 16 19:21:08 the only reason for two fifos is because the adc support two independent sampling sequences (one software-triggered, one hardware-triggered) Aug 16 19:21:47 well, I can tell you why I did it---it was to drive the sampling rate as high as possible Aug 16 19:22:01 whether it actually achieves that, or rather if I'm a moron, I don't much care Aug 16 19:22:04 it works Aug 16 19:22:12 if it worked, you wouldn't be here Aug 16 19:22:18 that's not true Aug 16 19:22:21 I can acquire data Aug 16 19:22:29 and I can subtract the undulations Aug 16 19:22:35 because they are 100% systematic Aug 16 19:22:55 I'm here because my data will be easier to process if I can figure out those undulations Aug 16 19:23:09 switching between fifos seems to be to be a red hearing Aug 16 19:23:16 herring Aug 16 19:23:31 the linux driver seems a better bet Aug 16 19:23:52 but as for configuration, that's in SEQUENCE PROGRAMMING section Aug 16 19:23:58 then the disable/enable portions Aug 16 19:24:27 if I wanted to turn on power, I would add a small bit the stop of my code Aug 16 19:25:25 I remember from my experiments that the adc is pretty fussy about how or when you mess with its settings, and it can get terribly confused otherwise Aug 16 19:25:48 as I re-read my programming, I am recalling what I did. Aug 16 19:26:03 In the TRIGGER NEXT section, I cue reading on one of the fifos Aug 16 19:26:38 for exampling clearing the enable bit is not permitted unless the stepenable bits have been cleared and the fsm has reached idle state Aug 16 19:26:44 as soon as I kick that off, I copy data from the *other* fifo Aug 16 19:27:05 this gives me (almost) the whole acquisition time of one of the fifos to copy the other fifo's data Aug 16 19:27:24 that, in turn, lets me reliably achieve higher sample rates Aug 16 19:27:40 I believe the system can pull four samples as quickly as 5us Aug 16 19:27:42 but you can't acquire more than 16 values in a one-off acquisition, while the fifo has space for 64 values, i.e. four acquisitions Aug 16 19:28:01 that's fine Aug 16 19:28:08 it's the timing I care about Aug 16 19:28:12 ?? Aug 16 19:28:15 you're not making sense Aug 16 19:28:36 I'm sorry Aug 16 19:29:05 what I'm trying to say is that, as far as I can tell, this allows for the fastest externally triggered effectively continuous sampling rate Aug 16 19:29:08 there is absolutely no reason to use two fifos, I'm pretty sure you can with more than 1 MHz sample rate with zero effort with a single fifo Aug 16 19:29:27 ehh that sentence failed a bit, but you get what I meant to say :P Aug 16 19:29:49 in fact, using two fifos would make that infinitely harder Aug 16 19:29:59 eh, I guess that's not true Aug 16 19:30:02 in your case Aug 16 19:30:05 since you're manually triggering anyway Aug 16 19:30:17 it does however add a lot of unnecessary complication Aug 16 19:30:57 well, almost certainly it was a case of over-engineering at the outset Aug 16 19:31:22 but it's not actually much more complicated Aug 16 19:31:32 you have to disable the ADC between reads Aug 16 19:31:36 no Aug 16 19:31:42 if you want to control the sample rate exactly Aug 16 19:31:58 suppose I tell it to pull 64 samples at some specific rate Aug 16 19:32:14 how do I ensure that the *next* 64 samples start at the exact right time? Aug 16 19:32:57 that would force me to grapple with two timing systems: the ADC's internal one, and my external trigger Aug 16 19:33:10 but, if you do one-shot, you only have one timing system: the external trigger Aug 16 19:33:14 it's more modular Aug 16 19:33:17 if you do one-shots Aug 16 19:33:24 I don't know what you mean. when using the adc with a trigger (rather than continuous mode) each programmed step will run only once, hence you can acquire at most 16 values per trigger Aug 16 19:33:41 correct, and in my case, I get four Aug 16 19:34:30 that's the one-shot Aug 16 19:34:33 right? Aug 16 19:34:34 exactly, so you'd just set those four stepenable bits each time you trigger Aug 16 19:34:40 since those auto-clear after execution Aug 16 19:34:49 (in non-continuous mode) Aug 16 19:35:14 right (I think that's what I do) Aug 16 19:35:16 and after the trigger you'd have plenty of time to read old data Aug 16 19:35:28 which old data? Aug 16 19:35:35 wouldn't it be actively overwritten? Aug 16 19:35:42 no? Aug 16 19:35:43 it's a fifo Aug 16 19:35:45 first in Aug 16 19:35:46 first ouit Aug 16 19:35:48 *out Aug 16 19:36:07 well that much I understand. :-P Aug 16 19:36:10 :-) Aug 16 19:36:46 I guess at the time the structure of the fifo was not clear to me Aug 16 19:36:47 unless you get a fifo overflow (i.e. you let 64 samples pile up without reading them) you will never lose data Aug 16 19:36:56 *more than 64 Aug 16 19:36:59 yeah Aug 16 19:37:19 * dcmertens looks through the fifo section of the reference manual Aug 16 19:37:24 however the big problem is your toggling of the enable bit Aug 16 19:37:51 since clearing that bit also resets the fifos Aug 16 19:38:30 why is that a problem? Aug 16 19:38:36 which means the subsequent lbbo is a fifo underflow Aug 16 19:39:13 and probably asynchronously races against data getting overwritten and/or causes state to mess up in unpredictable ways Aug 16 19:39:45 if you checked the irqstatus register you'd see the overflow errors :P Aug 16 19:39:57 *underflow Aug 16 19:40:07 given that this was my first expedition into assembly programming, I didn't do that Aug 16 19:40:25 :-/ Aug 16 19:40:26 :) Aug 16 19:40:48 well you could have inspected it from linux using /dev/mem Aug 16 19:41:28 inspected what? the irqstatus? Aug 16 19:42:40 anyway, before disabling the adc (during initialization) you should clear all stepenable bits and wait until the adcstat indicates STEP_ID is "idle", after initialization you enable it and then never touch that enable bit again Aug 16 19:42:44 yeah Aug 16 19:42:48 wait a second... you're suggesting that instead of disable/enable, I could use a "software trigger Aug 16 19:42:49 brb, need to get some food Aug 16 19:42:50 ? Aug 16 19:42:52 k Aug 16 19:43:01 writing stepenable is the trigger Aug 16 19:43:09 ok Aug 16 19:43:29 once steps are enabled, the adc will start working Aug 16 19:44:15 (and assuming the steps aren't configured as "continuous", each one will be cleared after the step has been performed, and finally the adc returns to idle) Aug 16 19:44:31 (each one = each stepenable bit) Aug 16 19:44:34 anyway, brb Aug 16 19:44:44 ok, thanks, get food! Aug 16 19:44:45 :-) Aug 16 19:53:15 zmatt: https://xkcd.com/763/ Aug 16 19:53:31 I think this ^^ conveys how you feel looking at my code Aug 16 19:59:18 lol, it's not *that* bad Aug 16 20:02:43 I'm happy using the fifo the way it's supposed to be used, but how do I tell the fifo I've read four values? Aug 16 20:02:50 Does the LBBO do that automatically? Aug 16 20:03:37 that seems too easy Aug 16 20:11:17 Or do I not worry about that? In that case, where do I look for data? is it a ring buffer? Aug 16 20:12:02 one advantage of disabling and re-enabling the ADC is that I always knew where to get the data. :-) Aug 16 20:16:12 dcmertens: https://pastebin.com/DiSGi9z0 this would be my suggested outline btw Aug 16 20:16:25 you always read the oldest values Aug 16 20:16:45 * dcmertens checks Aug 16 20:17:21 the fifo port doesn't behave like memory, every read basically returns fifo_mem[read_ptr++ & 63] or something like that Aug 16 20:18:06 ah Aug 16 20:18:34 I suspect that anybody whose done assembly already knew or would have guessed that Aug 16 20:18:42 now I know Aug 16 20:18:43 often a fifo port just looks like a single memory location you have to read repeatedly. the adc has a 64-word memory region so you can do a multi-word read burst, but the actual index within that 64-word region is ignored Aug 16 20:19:06 doesn't have anything to do with doing assembly, it's just about being familiar with memory-mapped peripherals :) Aug 16 20:19:34 fair enough. I never had to play with memory-mapped peripherals before Aug 16 20:19:53 but I get the impression this is the *only* way to play with peripherals when using assembly Aug 16 20:21:11 uhh no, I usually use C++, but python is a fine option too Aug 16 20:21:18 so instead of initiating an ADC read with with ADC enable, I do it with STEPENABLE Aug 16 20:21:45 zmatt, I meant that if you're programming in assembly, your only option is memory-mapped peripherals Aug 16 20:21:52 not at all Aug 16 20:22:00 well, shows what I know/ Aug 16 20:22:04 ;-P Aug 16 20:22:21 your deal with memory-mapped peripherals if and only if you deal with memory-mapped peripherals :P Aug 16 20:22:28 OK, so your hypothesis is that if I clean this up, then the undulations may disappear? Aug 16 20:22:53 I gotta head home, but perhaps on Monday I'll be able to give you an update Aug 16 20:23:03 well I have no good idea what's causing the "undulations", but at the very least you won't be making a complete mess of the fifo Aug 16 20:23:34 btw, just in case that wasn't clear: my adc-force-enable overlay should be used in combination with deal with disable_uboot_overlay_adc=1 Aug 16 20:23:45 right Aug 16 20:23:57 ehh, where did that "deal with" come from... copy-paste bork Aug 16 20:24:11 * dcmertens shrugs Aug 16 20:26:25 btw I why you used the structure start sampling; wait until done; loop { wait for external trigger; start sampling; copy data; } instead of the simpler loop { wait for trigger; start sampling; wait until done; copy data; } I'm suggesting Aug 16 20:26:29 zmatt, thanks for your help, or chiding, or whatever. I'm out. o/ Aug 16 20:27:13 however there's no point to doing so: you need to wait until sampling is done before you can deal with another trigger anyway, and copying the data from adc to memory takes negligible time compared to that Aug 16 20:27:49 you're welcome, and good luck Aug 17 02:06:18 Hi, can anyone help me in the Beaglebone Blue GPIO pins? Aug 17 02:06:43 I am trying to use GPIO3_1 or GPIO3_2 Aug 17 02:07:22 But i don’t know the proper GPIO pin Aug 17 02:08:14 By the formula would be the kernel 3*32+1 = 96 Aug 17 02:08:46 But this is a uart pin Aug 17 02:12:14 Skal: you need zmatt 's pin spreadsheet .. Aug 17 02:12:34 https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_Pin_Table.csv Aug 17 02:12:37 This one? Aug 17 02:13:19 hmm good question .. Aug 17 02:13:37 erm not quite Aug 17 02:13:43 zmatt's is nice and coloured Aug 17 02:14:48 https://docs.google.com/spreadsheets/d/1CK5c-Cs8G1RtzGo-J3VJsD9m5K-fp06AncgeYWsdjSU/view#gid=0 <= that one Aug 17 02:14:50 Because that one doesnt help, there isn’t any gpio3_1 or 3_2 Aug 17 02:15:04 Hello everyone. :-) I just bought a Beaglebone Blue for use in a quadrocopter. It's my understanding the max power output on each of the 4 DC motor drivers is 1 Amp. But, I need to drive motors with max power up to 18Amps. Can someone tell me how to accomplish this? Aug 17 02:15:59 Skal: on the BBBlue sheet .. row 70-71 Aug 17 02:16:44 RagnarRainMaker: you need some big transistors .. Aug 17 02:16:49 or driver chips Aug 17 02:17:04 Would connecting an ESC be an option? Aug 17 02:17:31 RagnarRainMaker: like? Aug 17 02:17:52 These are the ones I'm looking at: https://www.amazon.com/gp/product/B07FD4G32J/ref=ox_sc_act_image_1?smid=A1VD6A3M99HONZ&psc=1 Aug 17 02:19:18 I don't need to use those ESCs. I'm just trying to find whatever hardware/software I need to control my motors via the Beablebone Blue. Aug 17 02:20:21 hmm not sure I'm afraid Aug 17 02:20:38 he he he Aug 17 02:28:34 RagnarRainMaker: https://www.amazon.co.uk/VNH2SP30-Power-H-Bridge-Module-Motor/dp/B079H1BLC5 might work .. Aug 17 02:29:04 obviously you'll need more than one :D Aug 17 02:31:49 unless I just want it to go straight up, possibly sideways, and the crash in spectacular glory. :-D Aug 17 02:32:20 Thanks, that looks like the ticket. Aug 17 02:33:07 I also found this on Dronecode's site (they support Beaglebone Blue). https://docs.px4.io/v1.9.0/en/peripherals/pwm_escs_and_servo.html Aug 17 02:34:22 Seems like I will need a power distribution board (PDB) and connect high voltage terminals of the ESCs to the PDB. And the PWM (servo connector) from the ESCs to the Beaglebone Blue. **** ENDING LOGGING AT Sat Aug 17 03:00:04 2019