**** BEGIN LOGGING AT Tue Dec 08 03:00:19 2015 Dec 08 03:05:38 ssk: http://beagleboard.org/latest-images Dec 08 03:06:31 ssk: http://elinux.org/Beagleboard:BeagleBoneBlack Dec 08 09:53:35 please tell me how to analogread in C++ language Dec 08 09:54:19 * jugger_ slaps thaytan around a bit with a large fishbot Dec 08 09:58:44 .oO(we should have a bot that autokicks on slap) Dec 08 09:59:17 lol Dec 08 10:00:34 And a 'lmgtfy' too Dec 08 10:35:52 Hi;) Dec 08 10:37:43 I'm a R&D engineer, devoloping several different projects. I'd like to have a platform with a lot of IO, fast CPU and lots of ROM/RAM. Should the BeagleBoard XD be a good option? Dec 08 10:46:20 JohnIng: why are you considering the XM and not the BeagleBone Black/Green Dec 08 10:51:07 Hi @firemanxbr, how'r u? Thanks for your point, let me see the difference... I'd like to have an high-performance platform. And what about tooling? Can I write C-code on it? Does it has a compiler/programmer included? Dec 08 10:52:25 JohnIng, yes, no problem, C, or C++ or Go lang, anyway! Dec 08 10:52:44 JohnIng: high performance of _what_? Dec 08 10:53:21 and yes, hardware runs software, for decades now. Especially if it has a linux kernel available. Dec 08 10:55:32 Thanks firemanxbr, I'm sorry, did read the answering persons name wrong, should be tbr, but anyway, performance because it should run a lot of calculations, at the same time it has to control difference communication lines, and while doing those consuming things, also control +/- 150 actuators Dec 08 10:56:56 Calculations needs performance and datamem, communication lines needs free IO on the beagleboard, actuators are part digital (communication lines), part analog IO Dec 08 11:02:44 well, you should look at the Beaglebone Black then Dec 08 11:12:13 150 actuators .. how fast? Dec 08 11:17:35 might need some gpio expanders Dec 08 11:39:33 hi . i have problem using eqep0 on beaglebone green . I am using latest debain image and 4d system 4.3 LCD cape Dec 08 11:39:54 i am getting period as 0 Dec 08 11:40:32 are you sure you have it set up properly in DT and it's muxed? Dec 08 11:40:34 Hi @tbr why the black version? Dec 08 11:41:23 JohnIng: because the BB XM is rather old and if you don't need anything that's very specific to its OMAP3-ish SoC, then the more recent BBB is a better choice. Dec 08 11:41:42 I'm not even sure if the XM is still being produced Dec 08 11:42:03 not to mention its 1/8th of price Dec 08 11:42:43 What tooling should I use the best? We're using microchip products at the moment, so ARM's going to be a whole new way for me. For example I saw Keil as compiler, but cause of this is new for us and thereby more or less a "test", we'd like to start with a good free editor. Or is this included with the BBB kit? Dec 08 11:43:09 JohnIng: what are your timing constraints? Dec 08 11:44:38 Hm, I'd like to do calculations within 10 seconds, but some sensors (for example IR/spectra) has to be analyzed per x ms Dec 08 11:45:21 so you should be aware that by default most people run Linux on those larger boards Dec 08 11:45:22 Maybe I doesn't need the 2000MIPS at all, but I'd like to have a platform which I can more and more build up, without changing from board to board, cpu to cpu etc. Dec 08 11:45:34 which means that you can't do hard realtime Dec 08 11:45:57 Yes I know about Linux, but first of all I'd like to start at the bottom, just C. Dec 08 11:46:11 there are some ways to do that though on the PRUs Dec 08 11:46:55 So I can learn the ARM cores as much as possible, when we've moved to ARM for little devices too, which can't run Linux, I haven't to learn C, core and libraries again Dec 08 11:47:02 And, thereby, some projects are realtime Dec 08 11:47:03 do you mean bare metal? running binary ARM code without a kernel? Dec 08 11:47:07 Which mean, <1ms Dec 08 11:47:41 Yes, binary C Dec 08 11:47:47 Without kernel Dec 08 11:48:10 there is no such thing as "binary C". C source code can be compiled into a binary though. Dec 08 11:48:21 It's my internet searching which brought me up to this beaglebone board;) Dec 08 11:49:07 You can run bare metal code on the SoC. Dec 08 11:49:19 if you are into it then TI has their own set of tools for that Dec 08 11:49:42 Yeah I know, I mean "binary C" as agree on your binary ARM code Dec 08 11:49:53 though most people find it easier to run Linux and offload hard realtime tasks to the PRU cores (they are like micro controllers) Dec 08 11:50:54 the linux kernel can do some realtime things too if it's patched for that. Dec 08 11:51:04 Ah okay... Linux is absolutely a nice one though...the more because the end product should have a heavy GUI and Webinterface Dec 08 11:51:31 then you certainly don't want to reinvent the wheel/OS Dec 08 11:51:36 But again, I'd like to start at the bottom, than slowly move up to more advanced coding and kernel/OS/etc. Dec 08 11:51:56 get a BBB, knock yourself out. you can do all that Dec 08 11:53:25 I see, thanks! Do you maybe have tips to start with a smooth start? ;) Like: use that or that type compiler/editor or etc? Dec 08 11:54:45 for bare metal maybe zmatt can give you some tips Dec 08 11:54:45 I have a list of compilers/editors I've found on the internet, so my quesion isn't ment as to bee the lazy programmer Dec 08 11:55:07 but more to start well adviced Dec 08 11:55:10 also have a look at that TI StarterWare thing. that's their bare metal foo Dec 08 12:05:32 @tbr i have configured Dec 08 12:05:58 i am using https://github.com/Teknoman117/beaglebot/blob/master/encoders/dts/bone_eqep0.dts Dec 08 12:06:27 Okay, who's zmatt exactly (professional[ity]?), or how is he/she involved with the beagleboard? Dec 08 12:07:32 Ment to figure out all guys here and their roles, to has a clear sight on who've I can ask a certain question ;) Dec 08 12:10:37 hi . i have problem using eqep0 on beaglebone green . I am using latest debain image and 4d system 4.3 LCD cape Dec 08 12:10:48 can anyone help? Dec 08 13:04:46 @abhilash I'm sorry, n00b here... Good luck! :) Dec 08 13:36:28 what is the supposed way to load an overlay with mainline kernel? i'm using 3.16.0-4-armmp Dec 08 18:50:48 hi all Dec 08 18:52:30 I'm installed ubuntu into beaglebone black Dec 08 19:04:54 <[Butch]> Quickie question: Where are the least expensive BBB’s to be found? I need to order like five of them, and I don’t want to break the bank if I can help it. :-) Dec 08 19:28:56 how can modify ubuntu lxde to create kiosk mode? Dec 08 20:05:32 <[Butch]> For those of you lamenting the loss of the USB networking gadget under Mac OS X “El Capitan,” give this a shot: http://nyus.joshuawise.com/HoRNDIS-rel8pre1.pkg. Dec 08 20:05:35 <[Butch]> It worked for me. Dec 08 20:06:05 you can also switch the BBB to a different usb network mode Dec 08 20:22:56 <[Butch]> tbr: Why was I not informed? :-) Dec 08 20:48:11 Hi Dec 08 20:49:38 I have a BBB with kernel 3.8 on the eMMC. I disabled hdmi and enabled spi. I can read/write registers of my spi hardware. Dec 08 20:50:21 but when I boot on the latest debian kernel 4.1, after enabling spi, the hardware doesn't respond to my ioctl. Dec 08 20:50:42 Is there any noticable change with the SPI conf between 3.8 and 4.1 ? Dec 08 20:51:18 I think there is, actually. I don't remember the details. Dec 08 20:56:57 some info about the capemgr slots between 3.8 and 4.1 http://pastebin.com/uWDr2bCY Dec 08 20:58:13 wrong copy/paste. new link http://pastebin.com/Zg5KGt3M Dec 08 21:22:28 I've done lots of poking around on the 'net for PRU resources. I see pruss_remoteproc is loaded, but I can't find any info on virtio, except I think slots may be leveraging that already. A gentle nudge in the right direction would be cool. Dec 08 21:33:40 how do you plan to use the PRU? Dec 08 21:33:47 remoteproc is just one of the ways of using it Dec 08 21:37:27 I'm planning on using the PRU to talk to some hardware ADC for data acquisition that's read by Linux and exposed via a web API. My understanding is remoteProc is suitable for loading the code and virtio is likely the leanest interaction mechanism, without digging into interrupts and suchlike. Dec 08 21:37:58 sort of... remote proc lets you transfer limited size messages. In the background, it does the interrupting Dec 08 21:38:20 so as long as your data rate works with the packets size/rate limitations... Dec 08 21:38:46 what kernel are you using - when I looked at it a month or two ago, only certain kernels worked for remoteproc Dec 08 21:38:51 Oh. I thought it loaded the firmware as well. More reading, then. I haven't found a lot in the way of non-GPIO examples. Dec 08 21:38:57 4.1 Dec 08 21:39:14 4.1.10-ti-r21 to be exact. Dec 08 21:39:50 it does Dec 08 21:40:16 remoteproc is nothing more then a packet based messaging protocol. the ends are identified by addresses. drivers are attached to names announced on a known service. Dec 08 21:40:23 the TI ones should work Dec 08 21:40:35 Perhaps there's a better way? I'm happy to learn/read whatever, but I haven't found what I'm looking for. My expectation is the PRU will fire an interrupt when it has data and Linux will hook that and read it. Dec 08 21:40:36 remote proc and firmware are 2 different things Dec 08 21:41:17 Ah. Somehow I didn't get packet message protocol from what I've read. Somehow I got that rpmsg was that. Dec 08 21:41:18 yes. there is the older more bare bones way - the uio_pruss stuff. you ahve a processor. you can fire an interrupt when you feel like it. just manage the memory and have an agreement with your Linux kernel driver. Dec 08 21:41:54 remoteproc/rpmsg are tied together, AFAICT. might be a way to seperate out rpmsg Dec 08 21:42:04 All I've read is uio_pruss is significantly slower (latency) than remoteproc, but I would expect a lower-level solution to be faste. Dec 08 21:42:43 try it and see... uio_pruss was fine for xfering video frames for me Dec 08 21:43:00 Okey doke. I'll research uio_pruss then. Thanks! Dec 08 21:43:15 strictly speaking, you are correct though. remoteproc strictly speaking only does firmware/booting Dec 08 21:43:26 but AFAICT, it is tied in with rpmsg Dec 08 21:44:20 I'm also setting up cross-dev on w7, mainly because the JTAG emulator claims it fails with Linux on a VM, and we have no spare Linux boxen about. I'm thinking this may be problematic, or could I tie in the code from the beaglebone git for 4.1? Dec 08 21:44:45 jtag? why do you need jtag? Dec 08 21:45:15 Right. My reearch indicates remoteproc loads the firmware and fires up the PRU, and rpmsg is the packet message, but virtio is faster than rpmsg with soem more work. Dec 08 21:45:49 I don't know that I need it for certain. I just don't want to get stuck in there somewhere and need it, then have to reset the dev environment to use it. Dec 08 21:46:07 other then bootloader stuff, you don't really need jtag Dec 08 21:46:18 Not even for PRU dev? Dec 08 21:46:20 the BeagleBone, BeagleBoards are mini computers Dec 08 21:46:32 some people like to pad's their resume's with "jtag". ;) Dec 08 21:46:43 nope. never needed one Dec 08 21:46:53 If I don't need it it will simplify things, that's for sure. Dec 08 21:46:59 video capture, generation... all done w/o jtag Dec 08 21:47:12 * ticapix is happy. he manages to make spi to work on kernel 4.1 Dec 08 21:47:31 rcn-ee: I believe anything listed on a person's resume is fair game to ask about during an interview }:-) Dec 08 21:47:51 I don't think the GSoC students used jtag either Dec 08 21:47:55 Did you use an IDE or text editor and make files? Dec 08 21:48:03 vi + make Dec 08 21:48:05 nano! Dec 08 21:49:50 remeber the PRU's code size is small. like 2K instructions Dec 08 21:50:04 Yeah. 8k ain't much. Dec 08 21:50:08 it isn't that hard to fill up if you start using macros and unrolling looks Dec 08 21:50:24 there are folks who use C but that's almost overkill Dec 08 21:50:35 s/looks/loops/ Dec 08 21:51:08 Yeah hard to say. I'm only just getting ramped up on this. C seems simpler, but the instucton set is pretty tiny; looks easy enough to learn. Dec 08 21:51:36 the arguement for C is it handles mundane stuff. the argument against C is it obfuscates timing Dec 08 21:52:00 Mmmmm. Dec 08 21:52:39 how fast is your ADC? Dec 08 21:53:15 Not sure. I'm not actually writing that part, other than a sample routine to see the comm working between the PRU & Linux. Dec 08 21:54:23 okay, what kind is it? parallel? serial (SPI/I2C)? Dec 08 21:54:47 trying to find time to throw together a high speed data acq. system myself Dec 08 21:54:51 It's grabbing stereo audio at 16 bits/sample. I expect at least 44khz but it could easily be faster. I kow it's currently tied into McASP1 as serial. Dec 08 21:55:09 Ohhh probally I2S Dec 08 21:55:25 I know the control bus is I2C, yes. Dec 08 21:55:31 rpmsg might work for that... Dec 08 21:55:50 consider writing a rpmsg DAI for ALSA? :D Dec 08 21:56:18 I don't know squat about ALSA at this point, but that doesn't mean I won't by the time I'm done. Dec 08 21:56:36 hehe Dec 08 21:57:23 I know one of the test peeps got ALSA to pull raw data from McASP1, but my thought is that's fatter and slower than I want in the end. Truth tell I haven't benchmarked how long that path takes. Dec 08 21:57:42 if McASP1 is available, use it. Dec 08 22:00:17 I'm still waiting on my ADC hardware board to fiddle with it for real. Afaik McASP1 is a given. How we leverage that is the question. I am under the impression a PRU could do some repackaging and buffereing for us, then Linux could read the data "at its leisure". Dec 08 22:00:44 how sophisticated of a repackaging? Dec 08 22:01:04 the PRU can buffer cuz it has 12K/8K of RAM local to it. the McASP has FIFOs Dec 08 22:01:26 The board is up to eight channels total. Basically making sure what Linux sees is eight buffers, and down the road maybe some compression. Dec 08 22:01:57 Right. That 12k is what I was thinking for buffering. 8 ring buffers in shared memory. Linux doesn't know where it comes from. It's just there. Dec 08 22:02:43 The PRU manages all the actual acquisition, including pulling it from the McASP1. Dec 08 22:05:18 I'm thinking rpmsg (or something lighter) to let Linux know the buffers are updated, and to pass control data back and forth to the PRU. I don't think I need a whole packet, truthfully. Something lighter would be fine with me, but in the end if it works that's the meal ticket. Dec 08 22:13:59 you don't want the PRU to pull it from the McASP Dec 08 22:14:05 that is heavy weight Dec 08 22:14:19 setup DMA from the McASP to host Dec 08 22:14:30 s/host/DDR memory/ Dec 08 22:14:36 Is that because it's not on the fast bus? Dec 08 22:14:43 no, it is a waste of resources Dec 08 22:15:02 you are asking things to be ping ponged around the bus, using 2x the bandwidth Dec 08 22:15:42 McASP -> PRU memory after a poll or interrupt; PRU mem to DDDR using Cortex to memcpy after an int Dec 08 22:15:44 vs Dec 08 22:16:05 McASP signals Sample ready to DMA; DMA writes to DDR; Cortex is notified when DMA packet is done. Dec 08 22:16:35 Hurm. If its DMA to main ram then the PRU really has nothing to do. All the repackaging it would have done would be done by the Cortex. Dec 08 22:17:14 Wouldn't the McASP -> PRU and PRU -> Cortex use different busses internally? Dec 08 22:18:48 My intent was to share some processing with the otherwise idle PRU. Dec 08 22:20:19 no, it is the same L4 Dec 08 22:20:41 now if you need another McASP or if the pins on the McASP is not available... the PRU can work just like the McASP Dec 08 22:21:05 it is the same reason why accesses outside of the PRUSS is nonrealtime Dec 08 22:21:43 Hurm. Maybe that's how to do it, then, so the PRU can manage the data from the various ADC. Or just abandon the PRU route and do it all in Linux space. Dec 08 22:22:32 My thought is the PRU, being closer to the hardware, is a better choice to work on the hardware level. Dec 08 22:23:26 The McASP1 can read the data but not really interact with multiple ADC chips that effectively, afaik. Dec 08 22:25:07 it depends on the ADC Dec 08 22:25:33 IIRC, (verify with manual), you can do multiple ADCs with 1 by using TDM mode assuming the ADCs support it Dec 08 22:26:14 I'll look at the datasheets and see if that works across chips. Dec 08 22:26:23 what is the end app, btw Dec 08 22:29:59 Not entirely certain I'm at liberty to say other than an 8 channel audio recorder. I'll ask Boss Man and if it's ok'd I'll toss more out. Sadly at this exact juncture it's time for me to head home. I greatly appreciate your insights and look forward to being able to help you at some point. Dec 09 00:01:51 p Dec 09 00:04:01 :D Dec 09 00:04:59 I found an odle sandisk cruiser that I can imasculate to install linux on my EEPC ... happy happy. Dec 09 00:05:51 an odle one no-less! Dec 09 00:06:34 yes rare fiend ... err find yesh indeed. (laughs maniacally.) Dec 09 00:06:45 lol Dec 09 00:07:37 The default debian install on the BBB does it use LXDE or KDE for the window mangler? Dec 09 00:08:52 which eePC? Dec 09 00:09:03 my old 1005HA Dec 09 00:09:08 the one I got died in about 9 months Dec 09 00:09:20 is the power supply and track pad still working? Dec 09 00:10:10 yes but that is because I got waylaid and forgot I even had it (other toys I guess) it was $200 investment (new) and well I had other things that had too be done. Dec 09 00:10:46 bbb uses lxde I think .. kde is WAAAAY too heavyweight Dec 09 00:11:03 lxqt possibly Dec 09 00:11:32 veremit thank goodness I was worried suddenly. KDE is nice but processor hungry. Dec 09 00:12:22 yeah only really suitable for a desktop processor Dec 09 00:12:23 blah guis Dec 09 00:12:36 I like it though Dec 09 00:12:36 the X15 might handle KDE just fine }:-) Dec 09 00:13:17 hey jkdridner .. I need to evaluate kde on the x15.. please can I get one ... *grin* Dec 09 00:14:04 slap on a sata raid Dec 09 00:14:14 toss the thing in a giant cooler\ Dec 09 00:15:08 well the only issue I would have is the X15 has only 2G you need 4G with KDE these days. And gnome... forget it it wants 8Gig not to run slow. Dec 09 00:15:26 phuk that Dec 09 00:15:27 The X15 32bit or 64bit? Dec 09 00:15:52 i got better things to do then to run GUIs on my Beagles :D Dec 09 00:16:07 Gnome 2 could run comfy with 2G though. Dec 09 00:16:36 ds2 I was thinking of running matchbox actually. Dec 09 00:17:13 GenTooMan: got a guide to configuring matchbox? Dec 09 00:17:20 too many options Dec 09 00:17:29 and it seems to want to load a whole kitchen sink Dec 09 00:17:52 what about enlightenment? Dec 09 00:18:48 twm/fvwm was about the last wm's that are easy to configure Dec 09 00:20:39 openbox surely Dec 09 00:46:24 openbox hmmm what I need is something simple to configure, and I can export information for an overlay mask and coordinate information. However before I go 'there' I just need something that can work with the small screen such as 800x480x24bit. The BBB can't use a 24bit depth screen can it? Dec 09 00:49:01 I just 'activated' a 3g modem with usb_modeswitch ... I feel .. cheated. Dec 09 00:49:16 comes up as a cdc_ethernet device .. damn thing. Dec 09 00:49:54 on the plus side .. thats *really* trivial to implement lol Dec 09 02:06:05 veremit most people are cheated these days. They just don't feel it yet ;) at least its a simple ethernet adapter that is more useful than a serial port. Dec 09 02:07:12 GenTooMan: definitely Dec 09 02:10:41 veremit can you change it's MAC address? or does the CELL network use the MAC address as a valid pass to use it? I know that connecting to a cell network requires several keys so that may be one of many. Dec 09 02:11:22 GenTooMan: not tried .. it lit up, dhcp'd .. seemed to work, but cant test fully without breaking another net lol Dec 09 02:35:28 veremit If you plan on using it for something useful, I guess that would be problematic then huh? Dec 09 02:35:58 :p Dec 09 02:36:15 test rig aint here **** ENDING LOGGING AT Wed Dec 09 03:00:25 2015