**** BEGIN LOGGING AT Fri Feb 03 03:00:01 2017 Feb 03 04:45:39 Hi. The Raspberry Pi has a serious weakness related to powering off instead of shutting down decently: it can corrupt the SD card. Feb 03 04:45:53 Does the Beagleboard has the same issue? Feb 03 05:33:23 how do I convert sch schematics file to dsn format Feb 03 07:08:13 hi people Feb 03 09:59:19 Hello, Feb 03 10:01:02 Anybody know that where can I download schematic of beaglebone industrial board ? Feb 03 10:36:56 Chew, to be honest, I'd like also to know it Feb 03 10:37:39 Chew, as far I did not find it anywhere. Let me know if you succeed, please Feb 03 10:46:50 lore4, I will update to you later if I got it. Feb 03 10:48:52 thank you Feb 03 11:30:11 afk lunch Feb 03 11:53:42 they're identical to the BBB afaik, except they made sure all components are industrial temperature rated and they finished it off with a conformal coating Feb 03 11:56:03 any one home? Feb 03 11:56:41 how about if i just ask my question... Feb 03 11:57:10 i noticed that something does come over my bbbw's port 80 Feb 03 11:57:42 does my bbbw have an actual accessable web server on it, and if so Feb 03 11:58:06 does anyone know the filesoec of its htdocs directory? Feb 03 11:58:45 filespec* Feb 03 14:29:26 hi Zeekhuge Feb 03 14:33:24 Hi all, I have usbmount installed on my BBB. Every time I insert a USB drive I get this error in syslog: "FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck." I've tried 3 different USB jump drives, formatted each several times... I can manually mount the drive after I insert it, but the drive does not automount. Any clue what's going on? Feb 03 14:48:21 lore4: Hows that ADC thing going on ? Feb 03 14:48:48 The ADC still giving wrong values ? Feb 03 14:49:11 when measuring voltage from pin 1 to pin 5 or 7 on the P9 header, shouldn't i be measuring 5V? Feb 03 14:53:25 5, 6, 7, and 8 should be 5V. Feb 03 14:55:03 clockman: i'm measing just about 3.2 V, powered via USB, with no cape or peripherals attached Feb 03 14:55:43 sounds like your usb cable or usb supply is bad. Feb 03 14:55:46 is it possible that 5V power is not available via USB? Feb 03 14:55:48 oh Feb 03 14:56:05 i'll try with a different cable and power supply, 1 sec Feb 03 14:56:21 zeekhuge, no, finally it is working! The incorrect values were due to an error in scaling circuit! :'( Feb 03 14:56:22 you running off usb from a computer or a wall usb charger? Feb 03 14:56:29 clockman: laptop port, actually Feb 03 14:56:34 so worst possible option =) Feb 03 14:56:48 zeekhuge, on the repo there should be already the working header. The example, must be updated Feb 03 14:57:22 lore4: If you do not mind, where do you want to apply this for ? Feb 03 14:57:42 clockman: when connecting an MAX485 (RS485) IC, should i hook it up to 5V or SYS_5V? Feb 03 14:57:57 zeekhuge, for now it was only investigation on the platform :) Feb 03 14:58:28 zeekhuge: would you like to use it for your beaglescope? Feb 03 14:59:02 and do you ( and others here) think a project that would aim at developing libraries to access other SoC peripherals from the PRU space will be useful ? Feb 03 14:59:29 IMHO, definitely! Feb 03 14:59:44 lore4: actually I was thinking to suggest it as a GSoC2017 project. Feb 03 14:59:47 pins 5 and 6 are tied directly to the DC barrel jack. So it is *always* powered. I think 5V_sys is only once the BB is powered up. But you should test this with a volt meter on sys_5v immediately after powering the device Feb 03 15:00:11 zmatt: ^^ if you could comment on that Feb 03 15:00:26 in fact, I did this as I did not find such library on the web yet Feb 03 15:00:37 clockman: so i guess it would be smarter to connect it to 5V_sys, to have peripherals only powered up once the CPU is somewhat stable/booted? Feb 03 15:00:59 clockman: is it safe to connect to the BBB via usb even though the 5V barrel jack is connected? Feb 03 15:01:08 also if zmatt did a set of headers for his company Feb 03 15:01:29 zeekhuge, that would be very itneresting, imho Feb 03 15:01:34 *interesting Feb 03 15:01:37 yep, I remember that. Feb 03 15:02:07 sgflt, I do not have any clue : \ Feb 03 15:02:23 I think so, though some members may differ about it useful ness. So I am trying to collect some usecases. Feb 03 15:02:40 *its Feb 03 15:03:02 uhm, why do you believe that it would not be useful? Feb 03 15:03:43 not me, some members. Feb 03 15:04:09 Its useful in case we need PRUs as a separate processor. Feb 03 15:04:09 yeah, but why do you believe that some members would not find it useful? Feb 03 15:05:12 to be honest, I believe that they are separate processor (i.e. uControllers ) for "time critical" applications Feb 03 15:05:53 for example .. read this : https://groups.google.com/forum/#!topic/beagleboard-gsoc/IC-NeFHp4T4 Feb 03 15:07:40 other peripherals do not cause much overhead (due to availability of DMA options) so, the case where we want to use PRUs as processing unit (rather than I/O units they are much known for) Feb 03 15:07:57 it will be useful Feb 03 15:08:09 sorry, brb for a collegue Feb 03 15:11:58 uhm that post is too long, let me summarize : Feb 03 15:11:58 I suggested a project that will use the on SoC SPI peripheral and PRUs to offload SPI transactions. But it was ruled out as there is DMA suppport for SPI and produces close to no load on the MPU. Feb 03 15:12:57 I'm looking for some help maping the user leds (mainly heartbeat and cpu0) to a gpio to drive an external led can anyone help? Feb 03 15:27:42 lore4: thanks! Feb 03 16:07:30 back Feb 03 16:08:43 zeekhuge, IMHO the PRU are useful for RT Feb 03 16:09:45 for example, deterministic protocols, control, etc. Feb 03 16:13:12 a practical example can be to sample data from the grid and use PRU to pre-process raw data. Hence, this pre-process could also use include a lightweight control (e.g. there is a breaker, let's do something) Feb 03 16:13:57 zeekhuge, do you see what I mean? Feb 03 16:14:11 yeah, thats what i said. this will be useful when we need to use PRU as a processing unit. Feb 03 16:14:38 Thanks :) Feb 03 16:14:43 definitely Feb 03 16:14:48 welcome Feb 03 16:14:49 ;) Feb 03 16:15:03 I will suggest it for GSoC2017 Feb 03 16:16:14 lol Feb 03 16:16:19 the grid protection? Feb 03 16:16:21 note that once PRU makes accesses outside PRUSS you do lose some determinism Feb 03 16:16:34 you have some delay but still.. Feb 03 16:16:52 oh yes. the L4/L3 connects may cause lag. Feb 03 16:17:11 you'll get jitter due to other traffic yes Feb 03 16:17:57 by jitter you mean delays, right? Feb 03 16:18:09 I mean variable delays Feb 03 16:18:11 delay or latency Feb 03 16:19:48 this may seem obvious, but I've seen mailing list posts where people discovered this to their displeasure since they had expected to be able to rely on cycle-accurate stability Feb 03 16:20:02 still, there should be a table with the max latencies from PRU to peripherals... I suppose that then if they are "worst case times" it is not as variable as in being a non-RT environment Feb 03 16:20:52 hmm, I'm not sure there's a fixed "worst case latency"... or if there is, it will be very difficult to determine (but in any case much longer than the typical delay) Feb 03 16:20:57 http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies Feb 03 16:21:03 those are best-case Feb 03 16:21:04 I mean these tables Feb 03 16:21:05 not worst-case Feb 03 16:22:10 "best-case" cit. Feb 03 16:22:14 T.T Feb 03 16:22:19 it says so in the introduction Feb 03 16:23:15 my fault, i am too used to wcets :P Feb 03 16:23:42 worst-case is much much harder to determine than best-case Feb 03 16:24:09 you need to analyze the behaviour of the components and consider their worst-case interaction Feb 03 16:25:00 best-case is really easy, just do an access while the system is otherwise idle Feb 03 16:26:27 I agree, also easy to obtain from deisgn Feb 03 16:28:05 within pruss you afaik only have to worry about interference from concurrent traffic *to the same peripheral* by the other PRU core or from the L3 interconnect Feb 03 16:29:08 it may still be interesting to check whether it uses hard prioritization or round-robin, and how long one PRU can cause the other to stall in case of concurrent access Feb 03 16:29:33 that would be inteesting, as far as I read, I did not find such information anywhere Feb 03 16:29:37 *interesting Feb 03 16:29:41 (there are also undocumented config registers for the local interconnect, it seems it might be prioritization-related) Feb 03 16:29:59 really? Feb 03 16:32:04 https://hastebin.com/uroduhidok.cc Feb 03 16:32:13 zeekhuge, what's the summary of your GSoC2017? Feb 03 16:32:31 naughty zmatt! Feb 03 16:33:17 if the first four values are indeed fixed priorities per initiator that should be easy enough to figure out Feb 03 16:33:34 how did you find out these regs? Feb 03 16:34:03 they were in an early TRM Feb 03 16:34:40 since there are four 2-bit values and four master ports it's my guess that they correspond to each other Feb 03 16:35:05 the remaining ones may be a 1-bit per target, but I'm not sure what they could mean Feb 03 16:35:43 I guess TI won't say much about those if they are not in TRM : \ Feb 03 16:35:44 so zmatt, would you say that such a project (accessing external peripherals using PRUs) will be useful for the community in general ? Feb 03 16:35:48 perhaps whether to use round-robin or fixed-prio, that would make sense, but it's just wild speculation Feb 03 16:36:46 zeekhuge: I have no idea Feb 03 16:37:18 do you mean in the form of pasm macros? Feb 03 16:37:46 I believe it could be useful, at least I needed to access ADC from PRU. Probably someone else will need it... that's why I putted on the github Feb 03 16:38:09 zmatt, I believe more in the form of c examples :P Feb 03 16:38:22 oh I don't use the pru c compiler at all Feb 03 16:39:36 sorry, my "forma mentis" do not believe in assembler since C was invented :P Feb 03 16:39:47 pru has a nice instruction set and a really spiffy macro-assembler Feb 03 16:39:50 or religion, if you prefer :P Feb 03 16:40:04 haha ! Feb 03 16:40:13 its instruction set is however a poor match to C, so I'd have no idea what that compiler is going to generate anyhow Feb 03 16:40:42 plus you have only 2048 instructions worth of iram per core, that's not much space to waste Feb 03 16:41:07 yep, that's also next investigation Feb 03 16:42:21 and of course you lose determinism, sort of... timings will probably be predictable for one output binary, but you can't rely on them since recompiling with a different compiler version or settings might produce different code hence different timings Feb 03 16:43:08 still, it will be better that a processor with cache, etc. Feb 03 16:43:10 but I suppose it might make sense for some applications that aren't too timings-sensitive Feb 03 16:43:13 ain't? Feb 03 16:43:49 the problem with the cortex-a8 isn't cache, the problem with the corex-a8 is that linux is running on it Feb 03 16:45:25 (cache is only a minor problem, a baremetal application on the cortex-a8 could comfortably run entirely in L2 cache, or at least lock timing-sensitive parts thereof into L2 cache) Feb 03 16:45:59 I have a webserver running on port 8080.... Feb 03 16:46:35 zmatt, if linux is an issue you could go for an RT OS Feb 03 16:46:42 Sorry, that was for woody_ Feb 03 16:47:17 but I believe that if are using linux you need something different :) Feb 03 16:47:19 lore4: well in practice linux is just too damn convenient Feb 03 16:47:45 I agree :P Feb 03 16:47:53 otoh it leads to terrible things.... like nodejs Feb 03 16:49:03 but anyhow, drifting off topic... Feb 03 16:52:27 ahahaha... come on NODEjs is interesting! I mean, it depends always on what you wanna do Feb 03 16:52:36 *need to do Feb 03 16:52:48 goddy, gotta go Feb 03 16:53:02 have a nice weekend zmatt and zeekhuge Feb 03 16:53:03 I think javascript is a terrible language Feb 03 16:53:15 it is just a tool Feb 03 16:53:20 for me ;) Feb 03 16:53:39 Same to you lore4 Feb 03 16:53:41 and nodejs encourages very hard to debug spaghettis of callbacks and/or promises Feb 03 16:53:45 ty Feb 03 16:54:18 that's my impression anyway from the struggles of coworkers Feb 03 16:54:28 I try to avoid touching js Feb 03 16:54:34 I do not want to go down on this path now that i am so close to go out for the weekend :P Feb 03 16:54:44 I agree with you, but still Feb 03 16:54:57 let's say that I stay open-minded Feb 03 16:55:04 Sorry, what makes the BBB attractive for my use is linux.... Feb 03 16:55:05 see you! Feb 03 16:55:23 minnesotags: that's what I said, it's just too damn convenient :) Feb 03 16:55:53 it makes the platform much more accessible for most programmers Feb 03 16:56:39 even though it is at the same time terribly wasteful of resources Feb 03 16:56:41 I can put sensors on and save/collect data in a host of different ways Feb 03 16:58:48 My problem with the board is poor documentation implementation regarding the ADC circuits that has led me to smoke several boards.... Feb 03 16:59:07 But my fault ultimately. Feb 03 16:59:08 huh, the adc seems pretty decently documented to me Feb 03 16:59:58 (note that the chip errata are one of the first things I generally read when getting acquainted with a chip) Feb 03 17:01:11 Well, I'm still trying to figure out if there is a better way to gather analog pin data from the systemiio.... Feb 03 17:01:59 oh THAT... I have no idea how iio works either, I use uio to access the ADC directly and don't load the tscadc kernel driver at all Feb 03 17:03:10 Hmm. where is documentation on that? Feb 03 17:03:12 that's not a problem you're having with the board however, it's a problem you're having with linux Feb 03 17:03:26 Yes. I understand that. Feb 03 17:05:51 The problem I had with the board was not understanding NOT to use any voltage pin but the VDCADC voltage pin because the 3v pins are not well-regulated and can smoke your board. Feb 03 17:06:07 it has nothing to do with "well-regulated" Feb 03 17:06:11 VDDADC is 1.8v Feb 03 17:06:21 3.3V on an adc input will destroy it Feb 03 17:06:57 I know, but I was using a voltage divider to reduce the voltage and it still smoked. Feb 03 17:07:43 then you were somehow doing it wrong Feb 03 17:08:13 Yes. By not using the VDCADC pin and trusting the 3.3 pins. Feb 03 17:08:42 Lesson learned. Feb 03 17:08:43 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:09:14 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:09:42 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:09:45 vdd_3v3b (the 3.3v on expansion header) is a regulated supply, however if you were using that then I'd worry about what happens when powering down Feb 03 17:10:34 Yes. I believe that was the issue. Power up/down. Feb 03 17:10:39 why would you use that anyway instead of vdd_adc ? Feb 03 17:10:46 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:11:04 Sigh.... Feb 03 17:11:17 av500 / denix / whoever: ping? bot running amok? Feb 03 17:11:34 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:11:39 ... Feb 03 17:12:04 ... Feb 03 17:12:17 ... Feb 03 17:12:18 ok, time for /ignore gcl-bot :D Feb 03 17:13:31 minnesotags: vdd_3v3b remains powered for too long during shutdown, this is a known problem Feb 03 17:14:31 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:15:29 minnesotags: I've observed it getting disabled 20ms after it was supposed to Feb 03 17:17:13 https://lh3.googleusercontent.com/-_xHMJGdwpTA/VUKJFjC8koI/AAAAAAAAACc/VmSqofhSmXM/s1600/off-dc-noserial.png (once the shutdown initiates, BAT == sys_5v) Feb 03 17:17:43 Well, I'm not an expert designer, but after three boards I figured that regardless if it "should" work, it wasn't "going to" work. I suppose if I was a pro at this, I would track the voltage on pins through all kinds of cycling before I trusted it. Feb 03 17:18:08 we actually remove the separate LDO they used for vdd_3v3b and instead connect vdd_3v3b to vdd_3v3a Feb 03 17:18:14 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:19:59 of course you should use vdd_adc for the adc input anyway to minimize noise Feb 03 17:20:06 Where is the documentation on the current cap on the 1.8vdc circuit? Feb 03 17:20:29 what do you mean? Feb 03 17:20:51 I mean for multiple sensors on the ADC circuit Feb 03 17:20:59 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:21:39 Here comes the bot again.... Feb 03 17:22:00 I simply put it on /ignore Feb 03 17:23:00 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:23:44 and you mean how much current you can draw from vdd_adc ? not sure, generally I wouldn't expect you'd need to draw much current from it, but ultimately it draws from the main vdd_1v8 so it has a fair amount available (especially if the hdmi framer is disabled) Feb 03 17:25:56 vdd_1v8 provides up to 400 mA -> http://elinux.org/BeagleBone_Power_Management#Power_supplies Feb 03 17:26:15 then you'd need to locate other users of that supply and subtract them Feb 03 17:26:57 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:28:06 the maximum current rating for the 1.8V supplies to the cpu is 175 mA total, if I didn't make any mistake adding them up Feb 03 17:29:06 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:31:55 hdmi framer is specified at max 53 mA for 720p60 and max 77 mA for 1080p60 Feb 03 17:32:39 typ 10 uA in standby Feb 03 17:32:55 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:33:39 ... Feb 03 17:34:10 so that leaves at least 150 mA available on vdd_1v8 under the worst of circumstances Feb 03 17:35:10 ... Feb 03 17:35:33 minnesotags: will that do? :) Feb 03 17:36:33 ... Feb 03 17:40:02 (beware that the hdmi framer is reset-insensitive hence changing uEnv.txt and rebooting does not suffice to disable it, you need to power cycle) Feb 03 17:40:55 If there is a resource hog on this board, it is the hdmi Feb 03 17:41:02 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:41:27 why? Feb 03 17:41:36 I mean, in what sense? Feb 03 17:41:50 All I do is ssh in to it. Feb 03 17:43:00 If I needed a GUI, then VNC Feb 03 17:43:23 I almost never use it either... we have one project that has a gui (dedicated fullscreen app, not a desktop environment) but it uses an external LVDS framer, not the HDMI framer Feb 03 17:44:04 but that doesn't answer what you meant with resource hog... Feb 03 17:44:24 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:44:28 You were talking about linux being a resource hog. Feb 03 17:44:47 a waste of resources was the choice of words, yes Feb 03 17:45:02 if you look at how huge it is (and how slow it often is) Feb 03 17:45:38 Seems like others are always having to work around the hdmi pins, etc. Feb 03 17:46:16 that's just because of video in general though Feb 03 17:46:23 I'm not sure how much that circuitry adds to the cost of the board, but.... Feb 03 17:46:34 Yes. Video in general. Feb 03 17:46:46 just whatever they're paying for the framer Feb 03 17:46:55 it doesn't really have much more than that Feb 03 17:47:16 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:47:58 enough people seem to care about it though Feb 03 17:48:02 dunno why either Feb 03 17:48:42 Look. I'm not an expert, I just need a networkable, low power, embedded linux board to collect sensor information. BBB and the BBB industrial seem like they have the best expansion in that regard, so far. Feb 03 17:49:13 too bad the bbgreen's design suggests they don't know what they're doing, otherwise it would be a nice alternative Feb 03 17:50:13 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:52:12 if you don't use hdmi, then you have at least 225 mA available on vdd_1v8 Feb 03 17:53:12 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:55:03 if you need much more, power stuff separately and use opamps powered by vdd_adc to safely deliver the signals into the adc's power domain Feb 03 17:55:21 use series resistors on the opamp outputs to deal with the adc erratum Feb 03 17:56:04 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 17:58:36 well, "safely" .. if you exceed the input specs of the opamp then you may still blow them up, but then at least it's just an opamp instead of the beaglebone Feb 03 18:00:41 I'm guessing by your lack of response that you didn't need any of this info, I'll shut up now Feb 03 18:01:41 TypeError: 'NoneType' object is not iterable (file "build/bdist.linux-x86_64/egg/gitterpy/gitterpy.py", line 82, in roomIdFromName) Feb 03 18:07:22 sorry. lunch. have a great weekend, zmatt Feb 03 19:53:48 lol, wow clpru produces awful code... at least version 2.1.2 which I had installed, I'll try the latest for comparison Feb 03 19:57:38 yeah no difference really Feb 03 21:41:21 Hi Folks, I am working with a BBB, and I am trying figure out how to configure the McASP for multi-channel I2S input--specifically, for 4 stereo channels in order to interface with 8 digital microphones. It seems like this should be possible from the datasheet, and the code at http://bbb.ieero.com/ shows it being done for I2S output, but I haven't been able to find any good examples for input... does anyone have any experience with/r Feb 03 21:57:06 Hello friends Feb 03 21:57:22 Which is correct to run a java application automatically Feb 03 22:02:18 When Debian is initialized Feb 04 00:52:48 * zmatt . o O ( "multi-channel I2S" is a contradiction ) Feb 04 00:53:15 (assuming "multi-channel" is taken to mean > 2 channels as usual) **** ENDING LOGGING AT Sat Feb 04 03:00:02 2017