**** BEGIN LOGGING AT Thu Jul 09 02:59:58 2015 Jul 09 03:03:32 is there a core software that is not linux to run beagle as embedded real time Jul 09 05:14:48 beagleny: like freertos? Jul 09 06:03:51 Hi, Can anyone help us out on the pin mux settings Jul 09 06:09:25 we have configured the user led pins as gpmc pins using our dts file, even then the pin mux lists those pins as user led group Jul 09 06:09:55 Also, these user leds are still blinking Jul 09 06:10:41 how do we ensure that these pins are configured only as gpmc pins? Jul 09 08:45:03 guys I'm in trouble with an motion sensor, a PIR. if I wire a circuit with a led, it does dim up and then off after 1-2 seconds. If I wire it to the beaglebone, checking with a python script, the pin remains high... what should I check? Jul 09 08:50:39 nyo: do you own a multimeter? Jul 09 08:51:35 yes Jul 09 08:51:55 if I check the output it goes 3.3v from the sensor and after some seconds it goes to 0 Jul 09 08:51:56 then measure the voltage between the output pin and ground Jul 09 08:52:12 so the sensor seems ok Jul 09 08:52:15 ok Jul 09 08:52:35 what about the gpio pin? is it properly muxed as input? Jul 09 08:53:10 the python script does configure it for input, anyway, give me some seconds and I'll measure it Jul 09 08:54:08 yes pin does put out 0 volts while python script is running... Jul 09 08:54:36 and if the sensor is not attached to that pin, then the script returns 0? Jul 09 08:54:43 yes Jul 09 08:54:58 the script just say ready without any further action Jul 09 08:55:15 ... Jul 09 08:55:17 if I attach the sensor it goes line by line telling me motion detected... without a stop Jul 09 08:56:12 I double checked the behavior of the sensor with a led and a multimeter, it works right, if i put my hand over it, it puts out 3,3v for 2 seconds then stops when I remove hand Jul 09 08:56:18 is the output pin maybe noisy? noisy power supply? Jul 09 08:56:34 it is powered by usb... Jul 09 08:56:38 I can try to power it alone Jul 09 08:57:06 try this: connect the bbb input pin to the 3.3V rail on the BBB Jul 09 08:57:10 but if noisy it should put out 3,3 even without a sensor... Jul 09 08:57:36 but without any resistor? Jul 09 08:58:56 yes Jul 09 08:59:15 connection 3,3v with pin, tells motion detected Jul 09 08:59:30 once? twice? forever? Jul 09 08:59:39 every time I touch that pin Jul 09 08:59:52 but not like when you connect the sensor? Jul 09 08:59:54 should I leave it connected? mmm ok Jul 09 09:00:58 it says motion detected only 3 times Jul 09 09:01:07 if I leave it connected Jul 09 09:01:47 if i start the python script with pin connected to 3,3v just no output at all Jul 09 09:02:45 I'm going to connect the beagle power supply, without powering it by usb Jul 09 09:02:59 then, I'd say the output of the sensor is noisy. Probably some pulses and spikes. Do you have an oscilloscope? Jul 09 09:04:01 unfortunately not yet, I'm going to buy one soon Jul 09 09:04:07 I really need a scope Jul 09 09:04:13 for various projects Jul 09 09:04:55 a scope is very useful, yes. Doesn't even need to be expensive. For many things something simple and cheap is enough. Jul 09 09:05:55 mmm now I've connected the sensor to Beagle 5v power and it doesn't work... Jul 09 09:06:26 previously I was using a 9v with a voltage regulator L7805 to 5v so Jul 09 09:08:02 wow now works! Jul 09 09:08:15 so the problem was my new usb hub! damn! Jul 09 09:08:21 this BB is very sensitive!!! Jul 09 09:08:39 thank you!!!!!! Jul 09 09:08:43 np Jul 09 10:21:14 ok I've found out that the max 5V that the beagle can supply is 1000mA @ 5v, but if one day I will need to connect more sensore so more amperage, the noise problem will come out again.. Jul 09 10:21:57 actually I was powering 5v sensor with a 9v battery and L7805 voltage regulator, or just a 9v power supply with the L7805 regulator, that was giving out noisy/unstable signal Jul 09 10:22:21 so I've tried adding capacitors on input and output of LM7805 as described by datasheet, no way, still unstable sensors. Jul 09 10:22:55 i've added also ceramic caps that are usually described in similiar configuration to erase noise Jul 09 10:23:16 i've also tried to connect ground of LM7805 to ground of beagle Jul 09 10:23:30 as if somehow that was a solution.. no way Jul 09 10:26:20 going away for 10mins.. Jul 09 11:04:30 ok the LM7805 is noisy by itself. Jul 09 11:21:02 sounds like you are trying to connect something that is relatively senstive to noise, while not understanding noise sources and propagation at all? Jul 09 11:22:20 or your sensor draws too much power Jul 09 12:00:29 PIR sensor 65 micro amps Jul 09 12:00:50 will study that noise source ok Jul 09 12:00:51 thanks Jul 09 12:32:13 Hi - does anyone have experience/examples of how to use the eDMA for transferring data from the McSPI FIFO to ARM? Jul 09 12:51:51 hey, trying to connect a LSM303DLH sensor via i2c. i2cdetect seems to find it, yet i'm not able to read from it with c-code (using the element14 examples). http://stikked.xkonni.com/view/04695cc2 Jul 09 12:52:30 got the address and reg defined after the datasheet... not sure why write seems successful and read is not Jul 09 13:10:40 nyo: get yourself a copy of "the circuit designers companion" and "tietze & schenk" Jul 09 13:12:57 hi koth Jul 09 13:14:33 oook thx Jul 09 13:17:38 way expansive such books Jul 09 15:21:14 hi rcn-ee Jul 09 15:21:20 hey zmatt Jul 09 15:22:13 zmatt, ti has some crypto stuff here: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y looks like you won't have to fully reverse it for the x15. ;) Jul 09 15:24:05 well they usually have *some* crypto accelerators enabled in the kernel (using the very weird and limited omap-aes driver or the buggy-as-shit omap-sham) Jul 09 15:25:37 yeah I see 2x aes, des, sham, rng... with suspicious gaps in the IRQ numbers between them ;-) Jul 09 15:26:01 (looking at dra7.dtsi) Jul 09 15:26:27 but ok, separate accelerators it is then, no DM81xx-style Security Subsystem Jul 09 15:27:29 pka still not mentioned as usual Jul 09 15:27:48 but it'll reside on an L4 so it will be easy to find since the L4 interconnects have built-in memory maps Jul 09 15:28:41 ah, new version of the sham Jul 09 15:30:15 I really should work on a tool which semi-automatically makes a map of a TI SoC... including testing where irq/dma signals show up (if at all) Jul 09 15:30:52 done it by hand so far but it is a bit tedious (and still incurs risk of typos or other human error) Jul 09 15:31:24 might be worth it hack up omapconf, as that has some info already in it.. Jul 09 15:33:25 well the testing I have in mind is best done on baremetal Jul 09 15:33:34 and iirc omapconf has hardcoded tables, but I may remember wrong Jul 09 15:34:04 yeah it's hardcoded tables, based on ip.. Jul 09 15:34:16 I'm was aiming more for "poke here, see where the irq signal / dma event / interconnect error shows up" Jul 09 15:35:44 it's useful for hinting which irq's are reservered therefor first targets for poking at. ;) Jul 09 15:36:10 I'd want to double-check the "known" ones too... wouldn't be unpredecented to find errors there Jul 09 15:36:49 but some target-specific knowledge will need to be included anyhow to know where to begin Jul 09 15:37:04 and some things are too odd to detect without some initial knowledge Jul 09 15:37:35 (the DM81xx secss irq routing comes to mind) Jul 09 15:38:29 mapping the internal topology of the L3 interconnects is also high on my wish-list, but really not going to be trivial Jul 09 15:39:18 basically will have to be done by using latency measurements to see which packet flows share a common path and which ones don't Jul 09 15:41:19 combined with knowledge gained from random sources (e.g. I have seen a partial diagram of the DM814x L3F) Jul 09 15:44:19 in the DM814x I also found mistakes in the initiator/target connectivity matrix Jul 09 15:45:08 all these things taken together, having an automated system to extract (as much as possible) or at least verify such data would be valuable to have Jul 09 15:53:27 rcn-ee: since the sgx driver doesn't use/support DRM or such it probably also has few dependencies in the kernel right? Jul 09 15:53:37 it looks like even fbdev is optional Jul 09 15:54:12 the sgx is pretty free to write to the display directly... Jul 09 15:54:20 right Jul 09 15:54:38 when i last talked to ti, they were thinkign of using dma-buff's to do a real drm driver... Jul 09 15:54:50 of course, he left for another company....... :{ Jul 09 15:54:56 heh Jul 09 15:56:08 the odd thing, sgx had dependices in the da8xx framebuffer driver (which we don't use).. as we use the drm tilcd... so that's a massive hack... Jul 09 15:56:08 I guess most of their target markets use full-screen single-window apps anyway Jul 09 15:56:34 and running android... car infotainment... Jul 09 15:57:10 but... if we use wayland... http://git.ti.com/gitweb/?p=graphics/omap5-sgx-ddk-um-linux.git;a=summary Jul 09 15:57:16 it's all there.. Jul 09 15:57:18 I'm really not familiar how android does compositing... probably in its own androidish way Jul 09 15:57:27 it uses egl, same as wayland.. Jul 09 15:57:36 binary blob Jul 09 15:57:54 yeah that binary blob should be reverse engineered some way Jul 09 15:57:59 it will be, once enough people care Jul 09 15:58:05 hm depends Jul 09 15:58:11 libhybris Jul 09 15:58:24 the sgx "source" was leaked a last year... no one really cared... Jul 09 15:58:24 what the jolla folks do Jul 09 15:58:37 rcn-ee: it was? Jul 09 15:59:17 yeap, htc accidentlly had it in their open source release, so it got mirred on github pretty quickly.. Jul 09 15:59:17 and only for andreno you has a useable stack, thanks to rob clark Jul 09 15:59:37 rcn-ee: hm, but does this stuff also mean you can get wayland compositing on beaglebone with sgx530 ? Jul 09 15:59:44 ohh, link? :) Jul 09 15:59:47 rcn-ee was it complete or for one series? Jul 09 15:59:56 everything needed for the omap4.... Jul 09 15:59:59 sgx530... Jul 09 16:00:20 i then emailed imgtec directly about it, so that we coudl use it.. they said no.. Jul 09 16:00:30 right Jul 09 16:00:37 do not get sued Jul 09 16:00:48 (and since i work for a partner of ti... yeah.. i can't do anything..) ;) Jul 09 16:01:03 the phoronix guy spread some rumor that imgtec is working on an opensource solution Jul 09 16:01:39 woglinde, i think they have to.. their mips/sgx board didn't sell as well as they though.. Jul 09 16:02:16 yes Jul 09 16:02:20 right Jul 09 16:02:24 that was one reason Jul 09 16:02:42 rcn-ee: but... rcn-ee: hm, but does this stuff also mean you can get wayland compositing on beaglebone with sgx530 ? Jul 09 16:03:05 zmatt, yeap... (haven't got it working here yet..) Jul 09 16:03:06 because so far I thought it was fullscreen-singlewindow only Jul 09 16:03:11 ah, "in theory" Jul 09 16:04:16 so far I was going to aim for qt5 eglfs Jul 09 16:04:51 I'm hoping the existing qt5 application is okay with running on eglfs but I don't have much info yet myself Jul 09 16:07:12 it's okay, I don't have much info yet either, zmatt Jul 09 16:07:37 :P Jul 09 16:08:25 ok, I should really kick myself out the door to do some shopping... Jul 09 16:09:42 * myself buys everything on zmatt's credit cards Jul 09 16:17:22 arianepaola: I haven't seen any pull requests in a long time... Jul 09 16:17:28 and I still don't have the links to the binaries. Jul 09 16:17:48 I've got a board to flash today and it'd be great to try it. Jul 09 16:37:35 I am getting ENOENT syscall connect error when I am trying to post data to a service from beagle bone. Jul 09 16:37:40 Can anyone help? Jul 09 17:21:00 pinguins? Jul 09 17:21:05 beer? Jul 09 17:41:25 rcn-ee: awesome seeing the 7-5 snapshot of jessie, 4.1.1 with all the dtbo's I probably care to use :-D Jul 09 17:42:28 rcn-ee: got an error in a url for your image btw, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt ... the 2GB lxqt is malformed (BBB-eMMC-flasher-debian-8.1-lxqt-armhf... instead of lxqt-2gb-armhf...) Jul 09 17:48:59 Thanks Spirilis! fixed the wiki and my generation script. ;) Jul 09 17:58:17 Hello there I need to communicate with another hardware by UART1 with a baudrate of 5760, but I cannot achieve this speed in the Beaglebone, anyone have some idea of what I can do? Jul 09 17:58:39 That is not only really low, but also non-standard. Jul 09 17:59:23 yes but I cannot change the other hardware, it is from another company Jul 09 17:59:51 Tell them to stop using dumb baudrates. Jul 09 17:59:59 Nothing talks 5760 baud. Jul 09 18:00:11 software bitbang it from the pru.. Jul 09 18:00:13 rcn-ee: also "2015-07-06" under "BBB (All Revs) eMMC Flashers" ... both the lxde and console image url's throw 404's Jul 09 18:00:15 They talk, its a fuel pump Jul 09 18:00:56 the microSD/Standalone: (console) url that has '2gb' in it for BBW/BBB (All Revs) also throws a 404 Jul 09 18:01:09 (under 2015-07-06 heading) Jul 09 18:02:05 Derkoski: Yeah, I think at that point your are stuck bitbanging it. Jul 09 18:02:10 I already tried stty, and I was looking to use the setserial with division to achieve the speed, but setserial throws invalid argument for anithing that I do Jul 09 18:02:30 Spirilis, wired... Jul 09 18:02:44 server side they are there.. Jul 09 18:02:45 Yes, because the hardware only supports standard rates, and 5760 is not one of those. Jul 09 18:03:05 rcn-ee: yeah the files are probably there but like the jessie section, I don't see a "2gb" between "lxde-armhf" Jul 09 18:03:13 But how that in windows works Jul 09 18:03:18 Spirilis, drwxr-xr-x just like 2014-05-14 2015-03-01 Jul 09 18:03:31 e.g. "wget https://rcn-ee.net/rootfs/bb.org/release/2015-07-06/lxde/BBB-eMMC-flasher-debian-7.8-lxde-armhf-2015-07-06-2gb.img.xz" Jul 09 18:03:33 Derkoski: The UART your Windows machine has supports non-standard baudrates. Jul 09 18:03:44 Derkoski: That on the beaglebone does not. Jul 09 18:04:09 5760 almost seems like a type of 57600... Jul 09 18:04:15 <_av500_> agmlego: you sure it does not? Jul 09 18:04:16 erp of course putting 2gb in the middle of the url doesn't seem to help, so it might be something else :) Jul 09 18:04:19 typo, I mean Jul 09 18:04:37 _av500_: Based on the symptoms given... Jul 09 18:04:41 <_av500_> usally high baud rates are an issue if the clock divisor is small Jul 09 18:04:51 Spirilis, use: https://rcn-ee.com/rootfs/bb.org/release/ Jul 09 18:04:52 <_av500_> low baud rates should be doable Jul 09 18:04:59 Sure. Jul 09 18:05:26 <_av500_> of course it took years until the kernel learned there exists anything above 115200 Jul 09 18:05:34 Spirilis, doh! that script is still using the old dreamhost host, they are on linode and i don't have a 301 url redict setup on .net yet. ;) Jul 09 18:05:45 root@beaglebone:~# setserial -a /dev/ttyO1 /dev/ttyO1, Line 1, UART: undefined, Port: 0x0000, IRQ: 73 Baud_base: 3000000, close_delay: 50, divisor: 0 closing_wait: 3000 Flags: spd_normal Jul 09 18:05:48 rcn-ee: ah k :) thought it was something simple Jul 09 18:07:19 Spirilis, thanks all fixed... (i rely so much on the automated scripts. ;) ) Jul 09 18:08:10 and that is the output of setserial, perhaps its is not fully implemented in the beaglebone? Jul 09 18:08:52 Derkoski: Is /dev/ttyO1 a device node on your system? Jul 09 18:10:25 I did not understood the question, sorry. Jul 09 18:10:59 Derkoski_: Does the file /dev/ttyO1 exist? Jul 09 18:11:00 this is the output of sstty Jul 09 18:11:02 root@beaglebone:~# stty -F /dev/ttyO1 speed 38400 baud; line = 0; min = 1; time = 0; -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke Jul 09 18:11:34 yes it exists and I can communicate from my pc with this serial port Jul 09 18:13:27 <_av500_> Derkoski: I am pretty sure the hw can do your baud rate Jul 09 18:13:36 <_av500_> the divisor is a 16bit value Jul 09 18:13:46 <_av500_> if baudbase is 3MHz Jul 09 18:13:51 <_av500_> that goes down to 45 baud Jul 09 18:14:15 but do you know how I can configure? Jul 09 18:16:16 <_av500_> http://www.makelinux.net/ldd3/chp-18-sect-3 Jul 09 18:16:20 <_av500_> set_termios Jul 09 18:17:15 <_av500_> thats inside the kernel Jul 09 18:17:20 <_av500_> now to find out what ioctl you need Jul 09 18:18:18 <_av500_> http://www.scs.stanford.edu/histar/src/pkg/uclibc/libc/termios/speed.c Jul 09 18:18:31 _av500_: I will try here, and if work I will return Jul 09 18:19:38 thank you guys. Jul 09 18:19:43 <_av500_> http://man7.org/linux/man-pages/man3/termios.3.html Jul 09 18:20:04 <_av500_> Derkoski: it might be that the libc blocks some baud rates Jul 09 18:20:14 <_av500_> in that case you need to make the syscall yourself Jul 09 18:20:15 hmm Jul 09 18:20:32 ok thanks Jul 09 18:20:44 I will be back Jul 09 18:20:52 <_av500_> also, you might look into e.g. minicom source code Jul 09 18:21:05 hello again Jul 09 18:21:14 <_av500_> recent versions added a lot more speeds Jul 09 18:21:38 ok Jul 09 18:21:53 hm the kernel serial console baudrate saga Jul 09 18:22:28 <_av500_> yes Jul 09 18:22:39 <_av500_> we always come back to serial issues :) Jul 09 18:27:06 <_av500_> so minicom uses termios too Jul 09 18:27:26 <_av500_> bunch of complicated code Jul 09 18:27:31 <_av500_> tl,dr Jul 09 18:29:31 hi Guyz... i have a question regarding gpio on bbb... theomap generic driver gpio-omap.c ... seem to use number based gpio-legacy method... Is that true? because i can see that gpio_desc is part of the gpio_chip structure and the driver uses it extensively... so I am confused Jul 09 18:33:56 humm Jul 09 18:34:07 so I'm guessing with 4.1.1, the new gpio infrastructure, jackmitch/libsoc won't work? Jul 09 18:34:18 it's using /sys/class/gpio/gpio%d/value where %d is the gpio# ... Jul 09 18:34:44 Spirilis, all the &gpiox = &gpio(x-1) Jul 09 18:35:17 yeah but it looks like the sysfs interface is totally different for gpio now... compared to 3.8 which I'm assuming this library was written for Jul 09 18:35:29 it shoudl be the same, other then that.. Jul 09 18:35:51 oh, durr, 'cause I haven't exported anything Jul 09 18:35:56 ok nm :) Jul 09 18:36:54 yeah it's working right now :) Jul 09 18:36:57 I am using 3.14.8 as reference... and although the kernel gpio.txt states that descriptor based gpio should be used a grep for gpiod_get_value list out only few drivers using it.... most references are in gpiolib Jul 09 18:38:53 and now when I diga bit deeper gpio_get_value uses __gpio_get_value(gpio) which in turn uses gpiod_get_raw_value(gpio_to_desc(gpio)) Jul 09 18:39:14 3.14.8 is old? Jul 09 18:39:53 so in a way whether or not we use descriptor based gpio kernel internally uses only descriptor based gpios... after converting from number to descriptor Jul 09 18:40:23 rkc so whats your conclusion? Jul 09 18:42:17 sorry got disconnected Jul 09 18:42:54 rkc so whats your conclusion? Jul 09 18:43:31 no conclusion... actually i wanted to understand how the number based gpio drivers works... I have understood the descriptor based gpios by going through the code Jul 09 18:44:21 if someone could help me understand where doe these gpio numbers are defined... possibly that might help conclude Jul 09 18:44:33 and how are they different from the descriptors Jul 09 18:46:12 gpio descriptors are statically defined : static struct gpio_desc gpio_desc[ARCH_NR_GPIOS]; Jul 09 18:47:19 with each gpio controller provided a continuous range equal to numbers of gpio in the controller Jul 09 18:49:50 My question is how does the number based gpios defined.... are they left to user... then how does the number to actual reg mapping takes place Jul 09 19:10:21 rcn-ee: I think the gpio numbers are just gpio peripheral number * 32 + gpio pin number Jul 09 19:10:43 e.g. gpio 2.1 becomes 65 Jul 09 19:11:08 eh Jul 09 19:11:10 rkc: Jul 09 19:22:31 modulo a possible off-by-one if something is being obnoxious Jul 09 19:22:52 * zmatt hates sudden outbreaks of 1-based numbering Jul 09 19:24:57 I generally just make sure the pins are muxed right in DT and control the actual GPIOs via /dev/mem ... Jul 09 19:37:52 I have a question on Beagle Bone Black Jul 09 19:38:38 Will it also work on my mac book pro using OSX version 10.10.4? Jul 09 19:40:46 define "work" Jul 09 19:47:39 zmatt : sorry was looking through the code for the gpios Jul 09 19:47:55 yes thats true Jul 09 19:48:41 and i figured that gpio descriptors are also arranged in a linear array of structures Jul 09 19:49:01 so they map 1:1 with the gpio numbers Jul 09 19:50:23 tbh I think the linear numbering is really annoying and would much prefer to see them referenced as . Jul 09 19:50:37 moreover we have macros which when provides a number based gpio convert it to corresponding descriptor... and once the descriptor is know we can get hold of all the platform specific gpio related data/registers etc Jul 09 19:55:07 Work meaning, should I use windows in stead of using mac? Jul 09 19:55:28 to develop for linux? Jul 09 19:55:32 guess thats what descriptor based mechanism will do... if we request through gpiod_request instead of something like gpio_request(30, "some name") Jul 09 19:55:33 Yes Jul 09 19:55:58 rkc: I have no idea, I usually bypass the kernel whenever I can get away with it Jul 09 19:56:35 JB_: how much reading have you done on beagleboard.org have you done? specifically have you read the quick-start? Jul 09 19:56:52 Yes, but it doesn't say I should or shouldn't use mac. Jul 09 19:57:12 I can re-read it. Jul 09 19:57:27 does not matter... nice to talk live to someone ... moreover maybe an expert will peek through our discussion and throw some pointers Jul 09 19:57:30 ;-) Jul 09 19:57:45 rkc: I'm used to baremetal coding, so for me the kernel's job is to deal with multitasking and memory management, and let coworkers run their nodejs stuff, but other than that the kernel is an annoying obstacle between me and the hardware that I want to get out of my way ;P Jul 09 19:59:17 so things like the adc, pwmss, gpio, I use directly from userspace Jul 09 19:59:27 in case of the adc even with dma ;) Jul 09 20:00:24 Me too am not in hard core kernel business... come from 8051's... but was developing drivers for rtos based small systems n recently switched to linux drivers Jul 09 20:01:19 guess this stuff is a sea.... so many subsystems... to write a few registers... in baremetal or rtos based system i'd have used 4 lines of code to do that Jul 09 20:01:26 linux kernel dev still has too big an entry barrier for me compared to either baremetal or linux userspace coding... but tbh I'm also not highly motivated to try hard Jul 09 20:01:33 exactly that Jul 09 20:02:14 I mean, I can control a gpio by performing a syscall that will navigate a maze of subsystems to eventually end up performing a write to one memory-mapped register Jul 09 20:02:17 or Jul 09 20:02:25 I just perform a write to one memory-mapped register Jul 09 20:02:39 hahahah oh yeah Jul 09 20:03:09 but i guess the beauty is in complexity ;-) Jul 09 20:03:11 still need to fix the memory region type though... I discovered both /dev/mem and uio map memory regions as Strongly Ordered rather than Device Jul 09 20:03:12 or vice versa Jul 09 20:03:15 which is... bad Jul 09 20:03:54 but it makes so easy for you to work with the hardware.... so many can work without knowing baremetal stuff Jul 09 20:03:56 right ? Jul 09 20:04:23 I don't think the abstractions offered are worthwhile in many of these cases Jul 09 20:04:37 especially when you want to use the specific functionality offered by soem peripheral Jul 09 20:05:14 stuff like networking and such, of course you want the kernel to deal with that Jul 09 20:05:43 but a specialized measurement/control peripheral like eQEP or whatever Jul 09 20:05:44 no Jul 09 20:05:54 consider this.... linux supports so many arch and soc variants.... if they do not have these generic subsystems then the stuff will be millions of LOC Jul 09 20:05:58 there's no useful abstraction there, just overhead Jul 09 20:06:09 linux has no reason to be involved here Jul 09 20:08:26 gpio is middle ground... on one hand it does have a useful generic platform-independent abstraction, on the other hand it is also a huge pile of overhead just to toggle a friggin pin Jul 09 20:08:31 learnt it hard way Jul 09 20:08:33 believe it or not... everyone's moving their systems with silicon becoming cheaper.... atleast non-real time software Jul 09 20:08:50 so finally jumped with eyes closed into the linux sea Jul 09 20:09:04 hm, this is something I've slowly become aware of Jul 09 20:09:26 plus, I have abstraction too... my C++ headers actually allow you to do something like Jul 09 20:09:36 constexpr auto pin = 1.23_io; Jul 09 20:09:39 and then pin.set(); Jul 09 20:10:02 (to set GPIO 1.23 ) Jul 09 20:10:11 seems like while linux boxes aren't pulling the kind of ultra-low-power you can expect from an energy-harvesting 16-bit or 32-bit MCU, it's only a matter of time before they are commanding something "good enough" that folks are using it for tiny stuff Jul 09 20:11:03 we'll revisit this in 5 years when I have a linux powered implant in my skull :P Jul 09 20:11:21 hahaha Jul 09 20:11:55 for sure... by then zmatt will be more angry as abstraction in kernel would have increased 10 fold Jul 09 20:11:58 ;-) Jul 09 20:12:08 yeah Jul 09 20:12:44 rkc: I'm not angry, I just don't use the crap... going through the drivers for things like gpio or pwm is 1. more work 2. more complicated 3. much slower 4. more limited featurewise Jul 09 20:12:53 so why on earth would I choose that route Jul 09 20:13:09 the PHY firmware will be a big linux kernel module doing the realtime stuff while the user plays a laggy game of atc or adventure from their thoughts Jul 09 20:13:52 but you in turn use gpio driver in linux even while using sysfs Jul 09 20:14:21 in case you are using linux on BB Jul 09 20:15:17 rkc: I go through the kernel to config the GPIO pin direction, I'm not going to go behind the kernel's back on that because it may have bookkeeping about it and there are no atomic set/clear registers for that in the peripheral Jul 09 20:15:51 after that I just access the peripheral registers directly Jul 09 20:16:39 (I made a magic lib that lets my baremetal headers work also in linux userspace without modification) Jul 09 20:16:49 which is fine... being a user... i am just trying to learn driver stuff coz that helps in in my career :p Jul 09 20:17:20 smoke break Jul 09 20:17:53 oh no!! Jul 09 20:17:57 * zmatt glues the smoke back together Jul 09 20:35:26 back Jul 09 20:38:28 zmatt: what do you do with your bone ? Jul 09 21:20:18 rkc: varies depending on what The Man with the Paycheck wants to use them for ;) **** ENDING LOGGING AT Fri Jul 10 02:59:58 2015