**** BEGIN LOGGING AT Tue Feb 09 02:59:59 2016 Feb 09 04:30:34 I recently updated to Jessy and am having trouble with OpenCV. It errors out with: CMEM ERROR: Init: Failed to pen /dev/cmem: 'No Such File or directory' the error message goes one, but it looks like the CMEM module isn't installed in the kernel. I have no idea how to make that happen. Anyone wnat to give me a hint? Feb 09 11:10:28 Guys, how to disable HDMI? I dont have uEnv.txt, only nfs_uEnv.txt Feb 09 11:16:47 Oh, im fine. It was necessary to create it. Sorry =) Feb 09 11:25:50 New trouble: i disabled the HDMI, but i cant include overlay due to same mistake: "-bash: echo: write error: File exists" Feb 09 11:26:09 what i do wrong? Feb 09 11:43:08 I also tried create dts file for pr1_pru0_pru_r30_5 with help http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator. Same error. Feb 09 12:22:36 Huh, all this trouble due to BB-BONE-PRU-01 Feb 09 13:20:21 bb Feb 09 13:48:03 hi Feb 09 15:58:16 I'm fixing to move from kernel 3.8.13-bone79 to a newer one. A month or so ago I didn't see 4.4, but now I do. Is that stable enough I'd want to use it over 4.1? Feb 09 15:59:17 hello.. I need to know if now it is available only beaglebone black.. 'cause I need the white version. Feb 09 16:04:41 if you can buy a white, it's available. if you cannot buy it, it's not available Feb 09 16:16:04 Hello Feb 09 16:16:33 Goodafternoon zmatt are you here ? Feb 09 16:16:49 i wanted to ask about that example Feb 09 16:19:09 if you remember me Feb 09 16:19:19 i wanted to measure frequency Feb 09 16:22:55 hey zmatt are you here Feb 09 16:23:49 hi bbw Feb 09 16:23:55 About the beaglebone white.. My provider say me that now I can get only the black version because the white is out of production. Is that true? Feb 09 16:26:51 why you need the white ? Feb 09 16:30:30 ? Feb 09 16:30:52 I produce industrial printing system and my provider develop and provide us a driver card for to control four inkjet print-heads. On this card there are mounted an FPGA and a PIC microcontroller.. and also a BeagleBone card for to conect the main card on the local ethernet and for to manage the printing process. Now we have problem with the last version developed using the black version and he say that it is necessary to work wit Feb 09 16:31:24 ...production. But the one developed with beaglebone white was working well and stable. Feb 09 16:31:51 i see Feb 09 16:32:08 So I'l like to continue to work with the white version until my provider solve all problems with the black one. Feb 09 16:33:27 So, my question is.. The BeagleBone white version is available? Feb 09 16:34:35 I suspect my provider insists to continue with the black for to get experience using me like a cavy. Feb 09 16:34:53 https://groups.google.com/forum/#!topic/beagleboard/5si7w-vuf2U Feb 09 16:35:10 karmananke: you can always ask CircuitCo to make you some white ones Feb 09 16:35:22 since you are an industrial user Feb 09 16:35:27 you can buy there directly Feb 09 16:35:59 ok thank you.. I'll do it Feb 09 16:36:56 and read the above link Feb 09 16:39:22 karmananke are expert with beaglebone ? Feb 09 16:42:13 I'm not expert with beaglebone.. and no expert with programming.. and could be usefull for me to find an expert person on bbw/b.. Feb 09 16:42:37 ..better if in Italy Feb 09 16:42:43 (we are italian) Feb 09 16:43:45 if there is an expert guy on sw/fw and especially bbw/b.. he can contact me on lmihaiu@alfaservice.eu Feb 09 17:31:45 * zmatt is here Feb 09 17:31:55 yet those seeking me an hour ago no longer are :P Feb 09 19:51:55 i want to have X15 Feb 09 19:53:34 Hello, can anyone tell me the period of time of guaranteed availability of these products? Feb 09 19:53:37 and I want a steak sandwich Feb 09 19:53:51 Guy: which specifically? Feb 09 19:54:00 Beagle black Feb 09 19:54:26 ask the two manufacturers Feb 09 19:54:52 What are they typically about 1 year?? Feb 09 19:55:17 though, given that neither sells it as an industrial product, I'd be surprised if you got very long commitments, if at all Feb 09 19:56:07 I'd certainly expect a year to be no problem Feb 09 19:56:40 OK that's what I thought, not recommended for an application that has to be supported for 15 odd years Feb 09 19:56:42 at least in case of element14 Feb 09 19:57:02 ah, so 1 year is not what you are looking for? Feb 09 19:57:19 Well depend on our end user Feb 09 19:57:23 ask element14 about their industrial version Feb 09 19:57:36 So we can use for 1 yr but nothing longer without being at risk Feb 09 19:58:10 https://www.element14.com/community/docs/DOC-78671/l/element14-beaglebone-black-industrial-4g Feb 09 19:58:25 well, if you really needed, you could commission someone to manufacture boards, as the specs are available, if you can source the parts... Feb 09 19:58:29 where can i buy X15 Feb 09 19:58:36 if you need commitment, talk to the manufacturer Feb 09 19:58:44 or invest into stocking boards Feb 09 19:58:50 raj_: they are not on sale yet Feb 09 19:59:20 then how can i get it? Feb 09 19:59:23 good question what's TI's commitment to the AM335x availability? Feb 09 19:59:41 raj_: you can't get it at all at the moment. Supposedly in a month or two it might go on sale. Feb 09 19:59:42 tbr: they're targeting industrial applications, so I expect it'll be around Feb 09 20:00:02 zmatt: that's what I remembered, but I don't have a source at hand Feb 09 20:00:47 i need to wait about a month to get X15, how much do i need to pay to get one Feb 09 20:01:23 raj_: http://www.elinux.org/Beagleboard:BeagleBoard-X15#What_is_the_expected_price.3F Feb 09 20:02:15 tbr: browse the white papers to see what they're aiming at -> http://www.ti.com/product/AM3359/technicaldocuments#doctype9 Feb 09 20:02:44 that's more a thing Guy should have done, but he left Feb 09 20:03:10 if he hadn't, someone could have told him about SoMs and stuff Feb 09 20:04:02 I looked into making an irssi plugin to only hide join/parts of people who haven't spoken in the last screenful of text or so, but that turned out to be very non-trivial Feb 09 20:04:51 yeah, that's the reason I haven't turned it off Feb 09 20:04:51 is X15 under production or the stock is over? Feb 09 20:05:04 raj_: it's not in production yet Feb 09 20:05:25 supposedly the wechat smart-filter can do it though Feb 09 20:07:24 zmatt, just a question, since we had this topic in the past, what are the advantages/disadvantages of the 8250 omap serial driver over the non 8250 omap serial driver Feb 09 20:11:04 filt3r: the omap serial peripheral is backwards compatible with the 8250, but it's a major superset of that (more than 30 year old) uart Feb 09 20:11:37 in principle a dedicated driver has a lot more freedom to take advantage of the actual functionality of the peripheral, though I haven't inspected the driver to see whether it in fact does Feb 09 20:13:25 also, I personally would feel very uncomfortable about making changes to the 8250 driver since they might break things on one of the many many platforms where it is used, while testing changes to the omap-serial driver is much less of a problem Feb 09 20:13:43 if it is on sale where could we buy Feb 09 20:15:04 hmm ok, because one guy at our company added BT support for the wilink8 and somewhere in some ti examples the 8250 driver was used, but the driver crashes the cheap pl2303 usb-uart converters so i would like to go back to the non 8250 driver if the BT still works with them omap-serial driver (have not tested it yet) Feb 09 20:17:03 filt3r: neither driver is used obviously for an usb-serial converter Feb 09 20:18:11 yes i know, but the 8250 driver must be doing something funky with the uart to make the pl2303 crash Feb 09 20:18:54 oh you mean the pl2303 is on the other end? how on earth would you manage to *crash* an usb-serial converter by throwing bits at it? o.O Feb 09 20:19:58 but it's easy enough to try the omap-serial driver... I still use it in all my kernel builds and it seems to perform its job fine Feb 09 20:21:26 yes, it crashes the usb-serial converter, however we use the cheap 1,50 euro things bought in bulk Feb 09 20:21:51 and we already had some issues with them Feb 09 20:21:56 so that might also be a cause Feb 09 20:22:41 i havent really investigated it but if the BT still works with the omap-serial driver we will just switch back Feb 09 20:23:19 raj_: you need a time-travel machine to travel to the future and buy it Feb 09 20:23:24 I don't really expect any difference on the wire, but you can always try Feb 09 20:23:43 are you just using rxd/txd or also flow control lines or such? Feb 09 20:23:44 raj_: or travel to the future by waiting Feb 09 20:24:03 only rxd/txd Feb 09 20:25:07 but we also had issues with xmodem transfers using this cheap converters and we head to use the cp2102 ones Feb 09 20:25:17 filt3r: not much that can go wrong there... (except for TI's StarterWare driver which randomly corrupts the bitstream if you enable/disable any interrupts via its api) Feb 09 20:26:04 ok we are not using starterware anyways Feb 09 20:26:19 I pity those who do :P Feb 09 20:27:00 oh and one shouldn't write too many chars to the fifo consecutively, it flips out... luckily most drivers are too inefficient to trigger that bug Feb 09 20:32:47 (and edma can't burst-write to the uart unless you provide a source buffer that stores each char in an u32, hence it's paced by the limit of max 4 outstanding writes) Feb 09 20:45:43 hmm ok i just tried it at home with a bbb and could not reproduce the issue, but i will look into it tomorrow, because now it sparked my curiosity why the usb-uart adapter crashes :) Feb 09 20:46:44 also interesting, ti considers the omap-serial driver legacy: http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver Feb 09 20:49:56 they managed to have DMA support in the generic 8250 driver yet not in their dedicated driver? ~fail~ Feb 09 20:50:26 well ye that paragraph really confuses me because it seems they mixed up the drivers here Feb 09 20:50:36 http://lxr.free-electrons.com/source/drivers/tty/serial/Kconfig#L1107 Feb 09 20:51:28 so in the kernel the omap-serial driver has dma support ... (apparently) Feb 09 20:52:34 maybe the wiki article is older and now they support dma in both drivers Feb 09 20:52:56 at least it seems like this is the case Feb 09 20:53:02 I wouldn't make much sense to deprecate the omap-serial driver and *then* add dma support to it Feb 09 20:53:22 true Feb 09 20:55:42 it doesn't look like dma is being used for the uart, I'll try switching to a stock kernel to see whether it does then Feb 09 20:59:45 http://lxr.free-electrons.com/source/drivers/tty/serial/8250/8250_omap.c Feb 09 21:00:31 seems to be doing some dma stuff, although this is out of my knowledge, never done anything with dma/edma in linux Feb 09 21:02:25 I'm not seeing any evidence (at runtime) of the uart using dma on stock 4.1.16-ti-r44 Feb 09 21:05:59 I'll try grabbing something more recent Feb 09 21:08:34 http://lxr.free-electrons.com/source/arch/arm/boot/dts/am33xx.dtsi#L229 Feb 09 21:08:47 it specifies some dmas for the uarts Feb 09 21:08:57 doesn't mean it works Feb 09 21:09:13 how can i check if it works/ Feb 09 21:09:14 ? Feb 09 21:09:43 well I have a little tool that checks which edma channels show any evidence of being in use Feb 09 21:11:36 http://gerbil.xs4all.nl/edma-dump.tgz Feb 09 21:17:34 4.4.1-bone5 also doesn't list any channel in range 26-31 (the channels for uarts 0-2) Feb 09 21:20:05 # grep CONFIG_SERIAL_8250_DMA /boot/config-4.4.1-bone5 Feb 09 21:20:05 # CONFIG_SERIAL_8250_DMA is not set Feb 09 21:20:11 that might explain things Feb 09 21:21:07 ha Feb 09 21:21:07 ye Feb 09 21:22:09 too lazy to build a kernel right now, but feel free to try it... with my util you can verify whether it actually seems to be working ;) Feb 09 21:23:21 for my current kernel build this is actually enabled but i cant run the edma-dump tool because my rootfs is using the uclibc, so im rebuilding buildroot with glibc now Feb 09 21:23:34 oh I can compile it static Feb 09 21:23:45 oh ok that also should work Feb 09 21:29:50 http://gerbil.xs4all.nl/edma-dump.o.tgz <-- link against your favorite libc Feb 09 21:30:07 static linking against glibc resulted in a huge binary :P Feb 09 21:32:01 that doesn't surprise me Feb 09 21:32:16 yeah, I used printf, stupid me Feb 09 21:32:32 d'oh! lol no I'da thought other stuff tbh .. glibc is a bit library Feb 09 21:32:40 s/bit/big Feb 09 21:32:52 that doesn't matter if you don't use it Feb 09 21:33:01 shouldn't :) Feb 09 21:33:36 can you really strip sections of library out that aren't used? Feb 09 21:34:27 1. yes if you use -f{function,data}-sections or Feb 09 21:34:53 2. use a seperate c file for pretty much every function, which is what most libc implementations actually do Feb 09 21:35:36 solution 1 also requires some linker option to actually dispose of the unneeded sections Feb 09 21:35:57 solution 2 works simply because the linker won't pull in .o files from the static library unless necessary Feb 09 21:36:33 --gc-sections is the linker option for solution 1 Feb 09 21:38:37 basically it traces which sections are reachable (via relocations) from the entrypoint or symbols marked 'needed'. the compiler options mentioned put each function / data object in a separate section which allows this strategy to be fairly effective Feb 09 21:43:17 i'm trying to get my cell modem running on my beagle-bone-black-like custom board. Feb 09 21:43:39 the modem is a Telit LE910 Feb 09 21:43:54 veremit: note that libc + libm combined (which is what gets pulled in normally) is 1.3 MB, while the statically linked executable was 380 KB (stripped) so it doesn't quite pull in the whole lib Feb 09 21:43:58 i wrote a simple stand-alone util called "lup" that powers up the modem Feb 09 21:44:08 correction: called "leup" Feb 09 21:44:09 veremit: the dynamically linked executable is 5912 bytes (stripped) though Feb 09 21:44:24 with leup, the modem comes up just fine and stays up. Feb 09 21:44:45 zmatt: cool Feb 09 21:44:50 by "up" i mean a) i see the device enumerated in lsusb, and b) i see a /dev/cdc_wdm0 and /dev/ttyUSBx Feb 09 21:45:09 however, with code, the modem comes up for a few seconds, then goes down. Feb 09 21:45:33 i have searched and searched and tested and blah. and i can't find why!!! Feb 09 21:46:01 yates: you got a 4G one?! Feb 09 21:46:12 veremit: of course 380 KB of code just to read a few registers and dump them in semi-human-readable format Feb 09 21:46:16 here is the logs for leup versus the firmware: http://ur1.ca/ohzjd -> http://paste.fedoraproject.org/320485/50543571 Feb 09 21:46:21 yates: usb autosuspend? Feb 09 21:46:41 (which shouldn't kick in if the modem is actually being used though) Feb 09 21:46:51 zmatt: what is that and why would it only happen in the code and now in my leup utility? Feb 09 21:47:01 what do you mean with "in the code" ? Feb 09 21:47:05 s/now/not/ Feb 09 21:47:12 its not usb is it?! Feb 09 21:47:21 a) i see the device enumerated in lsusb Feb 09 21:47:23 my multithreaded application code. Feb 09 21:47:26 I must bring the old Telit module from work Feb 09 21:47:31 veremit: yes. Feb 09 21:47:45 it can be either, we're using the usb interface and the qmi driver Feb 09 21:47:47 hmmkay Feb 09 21:47:52 ok, then no idea Feb 09 21:47:53 on a bbb? Feb 09 21:47:57 lol oook ... Feb 09 21:48:21 no, it's our custom board that is patterned quite like the bbb. Feb 09 21:48:21 * veremit mutters musb Feb 09 21:48:40 yates: assuming am35x ? Feb 09 21:48:43 3 Feb 09 21:48:58 yes, am3352 Feb 09 21:49:05 cheapest.. Feb 09 21:49:06 yes, so musb :) Feb 09 21:49:21 huh? musb? what that is? Feb 09 21:49:32 oh zmatt .. where do we start .. lol Feb 09 21:49:41 yates hasn't heard of musb :/ Feb 09 21:49:41 and again, why in the code and not in the utility? Feb 09 21:49:51 thats a fair point though. Feb 09 21:50:02 * veremit still blames musb Feb 09 21:50:40 i guess the question is: what is causing this line: [ 99.165332] usb 1-1: USB disconnect, device number 2 Feb 09 21:50:53 possibly autosuspend Feb 09 21:50:55 my guess would be musb :P Feb 09 21:50:58 veremit: nah Feb 09 21:51:02 as zmatt suggests .. but I blame musb Feb 09 21:51:05 line 33 Feb 09 21:51:16 you think it's musb? Feb 09 21:51:18 yates: musb is the usb-otg controller used by the am335x Feb 09 21:51:37 (made by Mentor Graphics, that would be the 'm') Feb 09 21:52:16 so it's a separate chip on the bbb? Feb 09 21:52:31 long and short .. if you want it to be reliable .. *don't* use (m)usb Feb 09 21:52:33 two of 'em, each paired with one of TI's very own usb-otg phy and their custom dma engine to form the "usb subsystem" Feb 09 21:52:33 what's the ref des? Feb 09 21:52:49 we don't have any usb controller Feb 09 21:52:50 built-in to processor module Feb 09 21:52:52 the whole bunch have... a lot of personality Feb 09 21:53:08 we wired the data +/- lines from the LE910 directly to the AM3352 Feb 09 21:53:09 it's a subsystem of the am335x Feb 09 21:53:19 oh Feb 09 21:53:37 zmatt: nice way of putting it :D Feb 09 21:53:46 how do you turn the damn thing off? Feb 09 21:53:55 then you wouldn't have usb Feb 09 21:54:18 ok, so i'm stuck with it and there's no fixing this problem??!?! Feb 09 21:54:30 well that depends on the actual cause of the problem Feb 09 21:54:40 which is why i'm here, folks. Feb 09 21:54:41 since you do have a standalone util that works, that's encouraging Feb 09 21:54:47 yes. Feb 09 21:55:00 normally I'd suggest "try inserting a powered hub in the chain" but that doesn't really apply here Feb 09 21:55:21 there are probably also ways to enable lots more debug messages Feb 09 21:55:25 you know, i think i'll screw the firmware le910 code and just put it (leup) in systemd Feb 09 21:56:40 how do you enable more debug messages? Feb 09 21:56:40 zmatt: there should be a musb debug level option no? Feb 09 21:56:58 a disconnect might be triggered by the usb-5v dipping a bit too much (although when I experienced that the driver never recovered at all, but that might be kernel dependent) Feb 09 21:57:02 option where? in kde? :) Feb 09 21:57:09 yates: gnome :P Feb 09 21:57:19 yates: also be sure USB CPPI DMA is disabled in your kernel config Feb 09 21:57:21 yates: kernel command-line ya dope :P Feb 09 21:57:34 zmatt, it seems the dma channel is not enabled for the uart http://pastebin.com/NsjxRi9g Feb 09 21:57:34 zmatt: that occurred to me, since with the firmware running we turn on a couple of other modules. Feb 09 21:57:36 there's actually a neat way to enable messages at runtime Feb 09 21:57:58 zmatt: with uio?! :P Feb 09 21:57:58 yates: people have also observed enabling DMA makes usb _slower_ Feb 09 21:58:05 veremit: no, built into the kernel :P Feb 09 21:58:06 but /proc/config.gz has SERIAL_8250_DMA enabled Feb 09 21:58:48 eww Feb 09 21:59:11 filt3r: *shrug* maybe it needs to be enabled at runtime or something... normally it's not really easy to use dma effectively for an uart since often you want to process each received char anyway, though it should be useful for bulk transmit Feb 09 21:59:48 why are we talking about dma and slow thing? my thingie does WORK. Feb 09 21:59:53 doesn't Feb 09 22:00:04 well ye, currently im too tired to look into it, maybe ill take a look on the weekend Feb 09 22:00:08 liek the Paclids: "Make it go" Feb 09 22:00:10 it was before you came yates :D Feb 09 22:00:25 filt3r: "it"? Feb 09 22:00:34 serial dma topic Feb 09 22:00:39 oh oh oh. Feb 09 22:00:45 yates: it was just general advice, not necessarily a solution to your immediate problem Feb 09 22:00:59 I'm still trying to find that mechanism to enable debug messages at runtime again Feb 09 22:01:01 parse error. Feb 09 22:01:12 interpreter error. Feb 09 22:01:39 last time I found it I was like "whoa! neat!" but I've forgotten again how I got there Feb 09 22:01:42 error error! must analyze a . n . a . l . y . z . e. ..... Feb 09 22:02:10 from Star Trek TOS "The Changeling" Feb 09 22:02:36 in black-and-white.. Feb 09 22:03:06 zmatt: your "5V dipping" theory sounds interesting. Feb 09 22:04:38 aha! /sys/kernel/debug/dynamic_debug/ Feb 09 22:05:27 https://www.youtube.com/watch?v=G6o881n35GU Feb 09 22:05:55 aha Feb 09 22:06:12 echo 'file drivers/usb/musb/* +p' >/sys/kernel/debug/dynamic_debug/control Feb 09 22:07:05 is that fucking neat or what :D Feb 09 22:07:22 not bad for an amateur. Feb 09 22:07:33 zmatt, ok i had the omap-serial driver enabled apperently it does not enable the dma, but when i compile the kernel with the 8250 driver i get a line with 26 (def) [0---] en --- ien looking at the dtsi file this is the uart tx channel dma Feb 09 22:07:46 filt3r: woot Feb 09 22:08:27 zmatt: yikes .. lol. Feb 09 22:08:43 yates: if it's too spammy you can of course enable messages more selectively... musb seems to have quite a lot of debug messages Feb 09 22:08:49 .../debug/dynamic_debug# grep musb control | wc -l Feb 09 22:08:50 158 Feb 09 22:09:20 veremit: if I understand correctly it's implemented by live-patching the kernel (to avoid paying runtime overhead for checking whether messages are enabled) Feb 09 22:09:48 zmatt: that is pretty awesome .. and pretty crazy! Feb 09 22:10:08 yeah someone really had fun Feb 09 22:10:44 I'm not 100% sure about it though, but the kprobes stuff does the same thing Feb 09 22:11:37 https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt Feb 09 22:12:05 you can also enable messages via kernel cmdline or modprobe options Feb 09 22:14:16 ok zmatt, the omap-serial driver has some dma structs, etc. defined but as it seems they are not touched at all, this is on mainline kernel 4.5.0-rc1 Feb 09 22:15:46 veremit: CONFIG_JUMP_LABEL=y indicates dynamic branch-patching is used, and it's enabled on ARM :D Feb 09 22:16:04 zmatt: in mainline or just RN's kernels?! Feb 09 22:16:41 I assume mainline, I don't think he patches things that deep Feb 09 22:18:29 you can try to see where/when CONFIG_HAVE_ARCH_JUMP_LABEL gets set on arm Feb 09 22:23:59 select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU Feb 09 22:24:19 it can't even patch code executing directly from ROM? pfft Feb 09 22:24:38 and poor big-endian users are left out in the cold... Feb 09 22:24:42 (where they belong) Feb 09 22:27:17 haha Feb 09 23:05:49 people and their endianess I tell ya.. erstwhile RISC-V open source core seems to be developing at a steady pace. Feb 09 23:08:03 does that tie into endianness in any way or was it just a random remark? Feb 09 23:09:24 random bit it is little endian actually. Feb 09 23:11:36 which makes perfect sense since the only reason the mistake of big endian exists is because we adopted our numeric system from the arabs without reversing the order of digits to account for the difference in writing direction Feb 09 23:11:56 (hence when doing manual arithmetic you end up writing right-to-left) Feb 09 23:13:05 Well not too many big endian machines anymore are their? Feb 09 23:17:37 nope, though unfortunately the mistake of humans communicating numbers in big endian order is probably unfixable Feb 09 23:17:50 damn those 16th century italians Feb 09 23:17:50 mips is still popular Feb 10 00:30:29 after 35 years in the business, i still get confused by the terms "big endian" and "little endian" - isn't big endian lsb last (starting with the lowest memory address? Feb 10 00:31:14 which is opposite of what i'd think the term meant - "ENDS" with the big values.. Feb 10 00:32:07 yes, i have google at my house. just talking out loud. Feb 10 00:34:46 if i've created a c++ class instance via a pointer, myclass = new MyClass;, then will myclass going out of scope automatically cause the dtor to run? Feb 10 00:35:50 yates: little endian is where *(u32 *)addr == *(u8 *)addr whenever the former expression happens to be small enough to fit in a byte :P Feb 10 00:35:59 no Feb 10 00:36:26 instances created with new need to be explicitly deleted Feb 10 00:37:11 only an instance created on stack ( MyClass foo; ) is automatically destroyed when it goes out of scope Feb 10 00:37:59 zmatt: re: little endian: ok, but why is that called little endian? Feb 10 00:38:18 how does that make sense semantically? Feb 10 00:39:04 /me checks Gulliver’s Travels Feb 10 00:39:26 i would've thunk the the opposite: it ENDS with the LSB. Feb 10 00:39:50 dwery: is that an askance jab at ME?!? Feb 10 00:40:12 yates: the question is, which bit goes out first? Feb 10 00:40:24 the little end of the word or the big end of the word Feb 10 00:40:34 yates: because it serializes numbers by starting with the least significant part (byte, bit, depends on context) Feb 10 00:40:37 i.e. little end first Feb 10 00:40:43 yep Feb 10 00:41:11 the name is derived from that book Feb 10 00:42:06 big endian is often used in networking hw, so it's also called network byte order Feb 10 00:42:07 although big vs little endian does in fact have technical impact (which is why little endian prevails) Feb 10 00:43:34 and of course then there's mixed-endian (aka middle-endian), like pdp-endian or US dates Feb 10 00:44:05 and serializing always starts at the lowest memory address and works up? Feb 10 00:45:06 that is generally the order in which one accesses memory yes Feb 10 00:45:23 I don't think I've ever seen any bus architecture which has decrementing bursts :P Feb 10 00:45:38 you can't do that with EDMA? Feb 10 00:46:21 you could transfer bytes with a stride of -1, but it'll use a separate transfer for each byte Feb 10 00:47:41 also, I retract my statement, "xor" / "interleaved" bursts whose start address is the last address of the burst region effectively become decrementing bursts Feb 10 00:47:57 (these are not supported/used on TI SoCs, but they do exist) Feb 10 00:48:25 even though it is ingrained in the terminology of the field, i still think it would be clearer to simply say "LSB first" or "MSB first"... Feb 10 00:48:34 opinion are like... well, you know. Feb 10 00:49:00 "endian" makes me think of the end. Feb 10 00:49:48 yates: you will often find MSB or LSB first in datasheets of comms devices, as you said, it's cleared. you fill find big or little endian when talking about architectures. Feb 10 00:49:56 *clearer Feb 10 00:50:32 and it is correct that endian makes you think of the end.. but, which end? end is just a convention. Feb 10 00:50:35 yeah there's some ambiguity in that word, it's "end" as in "the ends of a rope", not as in start vs end Feb 10 00:58:14 knowing the reference the Gulliver's Travels makes the terminology a lot more memorable Feb 10 00:58:19 *the reference to Feb 10 01:01:00 (even though it implicitly suggests it is an arbitrary or trivial choice, which is simply not true) Feb 10 01:05:42 so English was a useful class after all! Feb 10 01:07:04 or, you just read about the reference (I haven't read the book) Feb 10 01:09:30 I had to read part of the book for a class, although I don't remember it too well Feb 10 01:14:26 Well endianess perhaps just a perspective. I've never really had trouble with big or little but then again I'm dyslexic so it looks all the same too me. Feb 10 01:16:08 GenTooMan: if a number is just a heap of bytes you're shipping somewhere it doesn't matter... things change however when doing arithmetic; any multiprecision integer library will store its chunks in little-endian chunk-order, since that's the order in which you need to access them (think of adding numbers by hand) Feb 10 01:43:40 zmatt I've not had that much difficulty with it honestly. I always see left low right high byte orders are useless when doing floating point. With integer arithmetic it makes more sense because higher address values are higher order bytes. I've done most of my arithmetic on little endian machines. Well the C51 is practically NO endian (LOL). What a crap architecture. Feb 10 01:48:48 I have trouble parsing what you're saying Feb 10 01:53:49 and doing floating-point in software is probably annoying regardless of how you store the data :P (although the actual arithmetic is not really different from integer, it's mostly the renormalization that sucks) Feb 10 02:10:59 Yeah the normalization part does suck. Anyhow all I was saying is "I haven't had that much difficulty perhaps because I've done it with floating point". Part of that is printing correct decimal numbers for floating point values. I had to research how to do it then do a test of 1 million numbers compared with a standard printf function I found my boss a PITA at that time. Feb 10 02:12:08 ah there are some evil bits there too, like rounding in cases where the rounding may change the exponent Feb 10 02:13:38 The rounding of the mantissa in particular was tricky after you were trying to print all the decimal digits. I got it to work at least in fact it was more precise than the standard printf. I then found out what the standard printf did slight bit of cheating you might say. Feb 10 02:14:14 heh Feb 10 02:16:12 I read some cool articles on the subject matter at least. then I had too make half precision numbers and convert them from single to half and half to single etc. Fun to an extent. Feb 10 02:18:07 dealing with approximations in the 2-adic topology would be so much easier to implement than the usual topology... it's unfortunate it's much less often useful Feb 10 02:55:02 can i take of control of an led (say, usr0) by simply exporting it? Feb 10 02:55:20 away from the default OS control, that is **** ENDING LOGGING AT Wed Feb 10 02:59:59 2016