2012-12-30 00:22 that's pretty clever: http://articulo.mercadolibre.com.ar/MLA-441034519-estacion-de-soldado-fuente-variable-multimetro-zd919-_JM 2012-12-30 00:23 soldering station, multimeter, and power supply, all in one device. nice for crowded spaces. 2012-12-30 00:26 of course ... power supply without current limit. somebody's been very afraid of actually making it useful :) 2012-12-30 00:34 emeb has joined #qi-hardware 2012-12-30 00:38 ah, lovely. from the description of a soldering station: "The whole function suffers the CPU control." 2012-12-30 00:43 hmm. ssh: connect to host projects.qi-hardware.com port 22: Connection timed out 2012-12-30 01:07 pcercuei has joined #qi-hardware 2012-12-30 01:25 urandom__ has quit [Quit: Konversation terminated!] 2012-12-30 02:21 wej has quit [Ping timeout: 260 seconds] 2012-12-30 02:24 pi_ has joined #qi-hardware 2012-12-30 02:24 pi_ is now known as FrankBlues 2012-12-30 02:26 wej has joined #qi-hardware 2012-12-30 02:56 wpwrak: ohh, zd\d{3} model name 2012-12-30 02:56 I have some stuff from that chinese vendor. it's pretty good. 2012-12-30 02:57 the iron and heat gun saved me quite a lot of times. 2012-12-30 02:58 a pistol-shaped desoldering tool which sucks air (not sure of the correct name in English), not as much. I have had much more luck using desoldering wick. 2012-12-30 02:58 through it might be me and not the tool itself. 2012-12-30 03:02 LunaVorax has quit [Ping timeout: 260 seconds] 2012-12-30 03:03 xiangfu has joined #qi-hardware 2012-12-30 03:05 LunaVorax has joined #qi-hardware 2012-12-30 03:07 FrankBlues has quit [Remote host closed the connection] 2012-12-30 03:14 pcercuei has quit [Remote host closed the connection] 2012-12-30 03:14 LunaVorax has quit [Quit: Quitte] 2012-12-30 03:30 whitequark: hmm, a desoldering iron ... applied to SMT circuits ? or to through-hole ? 2012-12-30 03:32 great. the GFW blocked *.qi-hardware.com in beijing. as least I can not access them any more. 2012-12-30 03:34 time to emigrate ? 2012-12-30 03:35 actually, that may be premature. http://qi-hw.com/ doesn't work from argentina either 2012-12-30 03:35 and i know that projects.qi-hardware.com is down 2012-12-30 03:40 projects and wiki on same machine. 2012-12-30 03:40 en.qi-hardware.com working and project.qi-hardware.com not working? 2012-12-30 03:41 checking ... 2012-12-30 03:41 i can't reach en.qi-hardware.com 2012-12-30 03:41 ok. maybe the qi-hardware.com is down. 2012-12-30 03:41 pertain.qi-hardware.com block by GFW. 2012-12-30 03:42 the last hop i see with traceroute is valkyrie.qi-hardware.com 2012-12-30 03:42 not sure what this machine is 2012-12-30 03:42 brimstone has left #qi-hardware ["WeeChat 0.3.8"] 2012-12-30 03:46 (en.qi-hardware.com) traceroute same here. stop at valkyrie.qi-hardware.com 2012-12-30 03:47 traceroute pertain.qi-hardware.com: stop at ChinaUnicom-BACKBONE. 2012-12-30 03:56 let's see ... 2012-12-30 03:56 "pertain" goes all the way to hos-tr1.ex3k15.rz16.hetzner.de 2012-12-30 03:56 ah, or static.233.58.9.5.clients.your-server.de 2012-12-30 03:57 it even answers http: "It works! 2012-12-30 03:57 This is the default web page for this server. 2012-12-30 03:57 The web server software is running but no content has been added, yet." 2012-12-30 03:58 i.e., http://pertain.qi-hardware.com/ 2012-12-30 04:03 http://pertain.qi-hardware.com/~xiangfu/ have something. 2012-12-30 04:03 DocScrutinizer05 has quit [Disconnected by services] 2012-12-30 04:03 DocScrutinizer05 has joined #qi-hardware 2012-12-30 04:04 yeah. here too :) 2012-12-30 04:05 wolfspra1l: en.qi-hardware.com maybe down! 2012-12-30 04:05 so it seems that none of our governments are up to anything unusually evil at the moment :) 2012-12-30 04:06 wpwrak: wolfspra1l can handle the en.qi-hardware.com problem. 2012-12-30 04:06 yeah :) 2012-12-30 04:06 at least that's what we hope :) 2012-12-30 04:07 wpwrak: but for pertain.qi-hardware.com, :( too bad. some of my government people working very hard on GFW. 2012-12-30 04:08 ah, so you can't reach http://pertain.qi-hardware.com/~xiangfu/ ? i see 2012-12-30 04:08 that's bad then :( 2012-12-30 04:09 wpwrak: I still can ssh --> qi-hardware.com --> pertain. 2012-12-30 04:10 but today I cannot reach any qi server. :( 2012-12-30 04:15 well, some are definitely down 2012-12-30 04:16 maybe that confuses the firewall 2012-12-30 04:24 wpwrak: through hole 2012-12-30 04:47 whitequark: for TH, those tin suckers should work quite well 2012-12-30 05:13 they do indeed 2012-12-30 05:13 with SMD, I don't have such problems :) 2012-12-30 05:24 yeah, there solder wick rules 2012-12-30 06:21 qi-bot has joined #qi-hardware 2012-12-30 06:23 thanks for the headsup about the server 2012-12-30 06:23 it's limping along :-) 2012-12-30 06:32 megharsh has quit [Ping timeout: 265 seconds] 2012-12-30 06:46 megharsh has joined #qi-hardware 2012-12-30 07:01 [commit] Werner Almesberger: lpc111x-isp/lpc111x.c: straighten *dialog*() API; radically simplify tracing (master) http://qi-hw.com/p/ben-blinkenlights/eda1135 2012-12-30 07:01 [commit] Werner Almesberger: lpc111x-isp/lpc111x.c (identify): retrieve and print the chip's unique ID (master) http://qi-hw.com/p/ben-blinkenlights/505caf9 2012-12-30 07:01 [commit] Werner Almesberger: libubb/swuart.c (swuart_open): don't call ubb_power (master) http://qi-hw.com/p/ben-blinkenlights/be82db0 2012-12-30 07:01 [commit] Werner Almesberger: lpc111x-isp/lpc111x.c: new option -n to disable powering the device (master) http://qi-hw.com/p/ben-blinkenlights/b2f1310 2012-12-30 07:01 [commit] Werner Almesberger: lpc111x-isp/lpc111x.c: read and dump (to stdout) the entire Flash (master) http://qi-hw.com/p/ben-blinkenlights/5246f5f 2012-12-30 07:01 whee, works again ! :) thanks ! 2012-12-30 07:09 yes. (en.qi-hardware.com) works fine here. 2012-12-30 07:11 megharsh has quit [Quit: WeeChat 0.3.9.2] 2012-12-30 07:12 wolfspra1l: btw, when you announce fpgtools more widely, people will want to know how to join the fun. do you plan to make a demo board ? or a reference design people can implement ? or select (a) 3rd party board(s) you recommend ? 2012-12-30 07:40 emeb has quit [Quit: Leaving.] 2012-12-30 07:52 wpwrak: do you use PWM to control LED brightness with 8:10 card, or it is a simple on/off? 2012-12-30 07:56 hmm, you mean "is there a PWM one could use with UBB" ? 2012-12-30 07:57 and answer to that would be "no". all you have there is the MMC controller 2012-12-30 07:57 you can use it to send finite bit patterns (see ubb-vga) but it's not really a PWM 2012-12-30 07:58 depending on the accuracy you need, you can hack various alternatives 2012-12-30 07:58 e.g., you could do a software PWM in unprivileged user space if you don't mind the occasional scheduling interruption 2012-12-30 07:59 yep, we already had this discussion and just re-read the log :) 2012-12-30 07:59 or privileged user space (with real-time priority) if you don't mind the occasional interrupt 2012-12-30 08:00 or heavily nasty privileged user space (disabling interrupts) if you don't mind cache delays 2012-12-30 08:00 how about various real-time patches to linux kernel? would they help? 2012-12-30 08:00 or use the MMC controller to get rid of cache delays as well, but have an anomaly at block boundaries 2012-12-30 08:02 not sure. i didn't keep track of them 2012-12-30 08:02 ah, more options: use timers vs. bust looping 2012-12-30 08:02 s/bust/busy/ 2012-12-30 08:02 wpwrak meant: "ah, more options: use timers vs. busy looping" 2012-12-30 08:02 so, it turns to be a quite limited GPIO.. 2012-12-30 08:03 yes. if you need resource-friendly tight timing, you need to add some MCU 2012-12-30 08:04 like this critter: http://en.qi-hardware.com/wiki/File:Uart-inserted.jpg 2012-12-30 08:05 maybe one real use case i can think about is using it for keyboard backlight. Not a "back" light, but more like a lamp an night :) 2012-12-30 08:05 yeah, why not :) 2012-12-30 08:06 so, you use gpios to command mcu, and it in turn doesn't the real-time thing? 2012-12-30 08:06 well, basically, it's ben-wpan :) 2012-12-30 08:07 yeah 2012-12-30 08:08 but if your external stuff isn't timing-critical or if it is but you can cheat, then you don't need any of this 2012-12-30 08:08 ubb-vga is one example of cheating 2012-12-30 08:08 swuart is another one 2012-12-30 08:08 taking into account that we can change the firmware of ben-wpan, the board is already ready.. maybe we can even control motor with atben+some h-bridge 2012-12-30 08:09 you could probably even make a low- or even full-speed device or a USB host 2012-12-30 08:09 atben has no firmware. only atusb does, but that's not for the ben 2012-12-30 08:09 yep, so all applications where i don't need determinism, i can cheat 2012-12-30 08:11 all applications where you need precise timing only for a reasonably short interval and where you need rapid responses only within a reasonably short time interval 2012-12-30 08:11 how come atben has no firmware? i see there is some mcu :) 2012-12-30 08:11 that's the transceiver :) 2012-12-30 08:11 and you control the transceiver with gpios, right? 2012-12-30 08:11 yup. is talks SPI plus a few control signals with the ben 2012-12-30 08:12 ok... i see 2012-12-30 08:12 it means that we also have SPI :) 2012-12-30 08:12 see also: http://projects.qi-hardware.com/schhist/atben/pdf_atben.pdf 2012-12-30 08:12 SPI is very very easy :) 2012-12-30 08:13 jekhor has joined #qi-hardware 2012-12-30 08:14 if i have a temperature sensor that talks i2c, connecting it to 8:10 card would be a piece of cake, right? 2012-12-30 08:15 if you're looking for protocols, we also have the in-circuit programming protocols of: AVR (via avrdude), some PICs (wernermisc/bacon/prog/), silabs C8051F3xx series (f32xbase/f32x/), and soon NXP LPC1xxx (ben-blinkenlights/lpc111x-isp/) 2012-12-30 08:16 yup, i2c has no problematic timing constraints 2012-12-30 08:16 heh, it seems that you've exploited this MMC controller to the full :) 2012-12-30 08:16 the only things that suck are maximum response times. minimum response times are never a problem 2012-12-30 08:16 oh, all those just bit-bang 2012-12-30 08:16 the only thing where i used the MMC controller is ubb-vga 2012-12-30 08:17 i turn interrupts off in ubb-vga and swuart 2012-12-30 08:17 but when you use those 6 GPIOs, don't you use MMC controller? 2012-12-30 08:17 new, i just use them as gpios 2012-12-30 08:18 hm.. i thought these gpios are coming from mmc controller 2012-12-30 08:19 in f32x, i leave interrupts on but get real-time priority. that means that the programmer may occasionally miss the timing (that protocol has a maximum response time) but that doesn't happen very often 2012-12-30 08:20 each pin can be switched between several functions, e.g., gpio, interrupts, or some hardwired function block (mmc, spi, ...) 2012-12-30 08:20 well, almost each i/o pin 2012-12-30 08:21 regarding fpgatools, people need to come forward if they want something 2012-12-30 08:21 how do you decide which way to go - get rt priority and leave interrupts on, or to turn off interrupts? 2012-12-30 08:21 I will react then 2012-12-30 08:22 at this point the sw is in such alpha state that you couldn't run much on actual hardware 2012-12-30 08:23 I took a break the last week or so for year-end backups and cleanups and so on but will continue soon. already forgot what the next item was :-) I think make the blinking_led a little more flexible, then jtag-controllable counter and other goodies 2012-12-30 08:23 yeah, that was the next item on the list 2012-12-30 08:23 kyak: basically based on how precise things have to be and how bad it is if i miss the timing 2012-12-30 08:24 wpwrak: i see.. btw, can we disable interrupts that simple on x86? :) 2012-12-30 08:25 wolfspra1l: people will probably want to "follow the project" and have hardware that lets them run whatever new cool stuff happens. so if your experimentation platform is somewhat predictable, that would be the device of choice. 2012-12-30 08:26 kyak: just tell the interrupt controller to shut up ? ;) 2012-12-30 08:27 kyak: but i've never done that on x86. on x86, if i write code that may crash/hang the system, i tend to go straight for the kernel 2012-12-30 08:28 so that you could creash it much better :) 2012-12-30 08:29 well, in the kernel i have functions that manage resources for me, etc. 2012-12-30 08:29 on the ben, i can get away with just saying "timer 3 is MINE now". but i wouldn't dare that on x86 2012-12-30 08:30 but why not? what's so different? 2012-12-30 08:30 you dont know which peripheal might be driven by that timer? 2012-12-30 08:31 yup. on x86 i have no idea what may grab timers and such 2012-12-30 08:31 on the ben, life is simpler and more stable 2012-12-30 08:32 and there are also hardware abstractions on x86 the kernel takes care of for me. on the ben, there's just one hardware 2012-12-30 08:33 so no guessing how interrupts may be routed, etc. 2012-12-30 08:33 x86 is so complicated, it always makes we wonder how real time are real-time solutions based on x86 2012-12-30 08:34 there is a huge market for x86 simulators, for example 2012-12-30 08:34 x86 simulators ? 2012-12-30 08:34 and they are real-time, yes 2012-12-30 08:35 oh, i mean, simulators based on x86 2012-12-30 08:36 if you ever heard of Opal-Rt, dSpace, xPC Target - these are all x86 2012-12-30 08:37 some are running "red-hat linux with real-time patches", some are running win32-compatible RTOS 2012-12-30 08:37 well, for reasonably lax RT, a lot of things are possible 2012-12-30 08:40 for example. ubb-vga has to be accurate in the nanosecond range (each pixel is only about 18 ns). software would have a hard time doing that :) 2012-12-30 08:41 swuart is nicer. at 115200 bps, i have 8.7 us per bit. software can do that, though without interrupts and i use a timer to avoid drifting (due to cache delays) 2012-12-30 08:41 yep, everything below 1 us is usually offloaded to FPGA (http://www.opal-rt.com/electrical-system-overview) 2012-12-30 08:42 but all of these providers have no problems with capturing a high-frequency PWM or doing quadrature decoding in real-time 2012-12-30 08:45 a little fpga can go a long way when it comes to relaxing your timing 2012-12-30 08:46 anyway, thanks for the chat.. time to do some new year preparations :) 2012-12-30 08:47 ah, the booze shopping :) 2012-12-30 08:58 erikkugel has joined #qi-hardware 2012-12-30 09:09 in fact, did that one week ago. It would've been a suicide to go to a store today and tomorrow :) 2012-12-30 09:10 morning 2012-12-30 09:18 wolfspraul has joined #qi-hardware 2012-12-30 09:21 wolfspra1l has quit [Ping timeout: 264 seconds] 2012-12-30 10:23 MistahDarcy has quit [Read error: Connection reset by peer] 2012-12-30 10:24 MistahDarcy has joined #qi-hardware 2012-12-30 11:33 urandom__ has joined #qi-hardware 2012-12-30 11:35 pcercuei has joined #qi-hardware 2012-12-30 12:06 kilae has joined #qi-hardware 2012-12-30 12:12 GNUtoo-desktop has joined #qi-hardware 2012-12-30 12:13 pcercuei has quit [Ping timeout: 260 seconds] 2012-12-30 12:26 wej has quit [Ping timeout: 264 seconds] 2012-12-30 12:29 pcercuei has joined #qi-hardware 2012-12-30 12:41 wej has joined #qi-hardware 2012-12-30 12:49 pcercuei2 has joined #qi-hardware 2012-12-30 12:51 pcercuei has quit [Ping timeout: 260 seconds] 2012-12-30 13:12 jekhor has quit [Ping timeout: 255 seconds] 2012-12-30 14:24 pcercuei2 has quit [Remote host closed the connection] 2012-12-30 14:32 pcercuei has joined #qi-hardware 2012-12-30 14:48 rz2k has joined #qi-hardware 2012-12-30 14:49 GNUtoo-desktop has quit [Quit: [INFO] fsogsmd : received signal -11, exiting.] 2012-12-30 15:40 GNUtoo has joined #qi-hardware 2012-12-30 15:56 pcercuei has quit [Quit: Bye] 2012-12-30 15:56 pcercuei has joined #qi-hardware 2012-12-30 16:15 jekhor has joined #qi-hardware 2012-12-30 16:30 jekhor has quit [Ping timeout: 245 seconds] 2012-12-30 17:01 jekhor has joined #qi-hardware 2012-12-30 17:07 pcercuei has quit [Quit: Bye] 2012-12-30 17:09 erikkugel has quit [Read error: Connection reset by peer] 2012-12-30 17:16 jekhor has quit [Ping timeout: 250 seconds] 2012-12-30 17:36 xiangfu has quit [Quit: leaving] 2012-12-30 17:36 xiangfu has joined #qi-hardware 2012-12-30 17:38 pi_ has joined #qi-hardware 2012-12-30 17:38 pi_ is now known as FrankBlues 2012-12-30 17:39 FrankBlues has quit [Client Quit] 2012-12-30 17:40 FrankBlues has joined #qi-hardware 2012-12-30 17:54 jekhor has joined #qi-hardware 2012-12-30 18:03 jekhor has quit [Ping timeout: 244 seconds] 2012-12-30 18:08 pcercuei has joined #qi-hardware 2012-12-30 18:10 wej has quit [Ping timeout: 260 seconds] 2012-12-30 18:15 wej has joined #qi-hardware 2012-12-30 18:23 wolfspraul has quit [Quit: leaving] 2012-12-30 18:24 wolfspraul has joined #qi-hardware 2012-12-30 18:28 FrankBlues has quit [Remote host closed the connection] 2012-12-30 18:33 kilae has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]] 2012-12-30 18:52 pcercuei has quit [Quit: Bye] 2012-12-30 19:11 GNUtoo has quit [Quit: Program received signal SIGSEGV, Segmentation fault.] 2012-12-30 19:16 emeb has joined #qi-hardware 2012-12-30 19:30 pcercuei has joined #qi-hardware 2012-12-30 19:41 RT usually is defined as "predictable guaranteed maximum response delay to a certains set of defined external events" - this response time can as well be defined as: in the range of minutes 2012-12-30 19:41 depending on the particular system 2012-12-30 19:42 generally RT isn't about speed but about predictability and determinism 2012-12-30 19:43 yep 2012-12-30 19:46 but then you discover that your maximum delay is not small enough... 2012-12-30 19:46 following this definition, Linux-RT is not about a particularly speedy system, but about guaranteeing that a set of processes scheduled realtime will never take longer than X to get CPU and process an IRQ 2012-12-30 19:47 otoh extreme speed requirements (like werber's VGA hack) might not have real hard RT requirements, if you tolerate occasional artifacts in your display 2012-12-30 19:48 werner's* 2012-12-30 19:48 DocScrutinizer05: I'd say that technically it does have hard RT requirement, as with some delays you'd lose sync 2012-12-30 19:51 whitequark: no, if you'd for example miss out on 1% of pixels and display just a default black instead, but resync for next pixel, you'd get a pretty acceptable image yet the system clearly doesn't qualify for RT 2012-12-30 19:52 basically the timing requirements for a VGA output are mostly unrelated to those specified for a RT system 2012-12-30 19:53 e.g jitter isn't even a topic for RT 2012-12-30 19:56 DocScrutinizer05: I was more thinking about this: if your system, let's say, features a garbage collector with unbounded maximum runtime, it is obviously not RT. And while for 99% of cases it would output the perfect signal, the fact that it *can* lose sync (which I deem a catastrophic failure here) makes it unsuitable for the task 2012-12-30 19:58 yes, such a thing like a GC disqualifies the system for both RT and the wpwrak VGA hack 2012-12-30 19:58 very much so ;-) 2012-12-30 19:58 still doesn't mean RT and VGA hack have any common denominator 2012-12-30 19:59 you have these parameters in all systems: what bounds you want to be met and the consequences of failure to meet them. 2012-12-30 19:59 wpwrak: would it be a catastrophic failure for your system if it misses a single deadline? 2012-12-30 19:59 DocScrutinizer05: but don't requirements for the VGA hack (the need to output sync signals in time) qualify it to be an RT system? 2012-12-30 19:59 DocScrutinizer05: I don't understand why not 2012-12-30 19:59 what i'm saying is that for VGA hack a lot of RT specs apply as well, though in a way more strict way. While some others don't apply at all 2012-12-30 19:59 in the case of ubb-vga, failure isn't catastrophic. but of course, if it happens too often, people will dislike it. 2012-12-30 20:00 i don't like this word, but then your system is "soft real-time" 2012-12-30 20:00 i think many screens have something like a PLL. so if you get the timing wrong too often, the PLL will start to wander. 2012-12-30 20:00 DocScrutinizer05: yes, it's quite atypical RT. 2012-12-30 20:01 at least in the context of software RT 2012-12-30 20:01 not so much in the context of hardware RT. e.g., you don;t really expect a UART to jitter significantly 2012-12-30 20:02 generally you expect hw to be "real time" 2012-12-30 20:02 DocScrutinizer05: or, in other words, what I mean is that requirements for the vga hack is a superset of typical requirements for an RT system 2012-12-30 20:02 exceptions frequently need very special notice 2012-12-30 20:03 whitequark: nope, not all of them, since RT *never* allows any glitch 2012-12-30 20:03 every system glitches :) 2012-12-30 20:04 DocScrutinizer05: I see 2012-12-30 20:04 while. as explained above, you could output a complete black H-line on ubb-vga every now and then and it wouldn't matter too much 2012-12-30 20:05 the question is what happens then. 1) nobody even notices. 2) a few raised eyebrows. 3) a murder investigation. 4) etc. 2012-12-30 20:05 the requirements for ubb-vga are simply different from the definition of RT, though admittedly quite a few of them can be found in RT defs 2012-12-30 20:06 DocScrutinizer05: thanks for explanation 2012-12-30 20:06 on a related topic: do you know why TV RF is specified as "stronger signal for darker pixel"? 2012-12-30 20:07 random noise would usually add to the signal level from transmitter, thus causing dark spots instead of white spots 2012-12-30 20:07 your eye will ignore those transient dark spots pretty much 2012-12-30 20:08 DocScrutinizer05: but why does it add to the signal level? 2012-12-30 20:08 the eye's ability to remember photons is indeed quite remarkable 2012-12-30 20:11 whitequark: because of two signals rather add than interfere to mutually eliminate 2012-12-30 20:12 since for audio same physiological trick obviously doesn't work, they chosen AM for video and FM for audio signal of TV 2012-12-30 20:19 emeb has quit [*.net *.split] 2012-12-30 20:19 Jay7 has quit [*.net *.split] 2012-12-30 20:19 jow_laptop has quit [*.net *.split] 2012-12-30 20:19 whitequark has quit [*.net *.split] 2012-12-30 20:19 whitequark has joined #qi-hardware 2012-12-30 20:19 jow_laptop has joined #qi-hardware 2012-12-30 20:19 Jay7 has joined #qi-hardware 2012-12-30 20:19 emeb has joined #qi-hardware 2012-12-30 20:35 by the way, what do you guys think about automatic reference counting as a memory management strategy? 2012-12-30 20:39 common strategy, used e.g in Qt 2012-12-30 20:40 combined with copy-on-modify for optimization of string handling 2012-12-30 20:41 DocScrutinizer05: I think I should elaborate. I'm implementing a Ruby dialect for embedded development, right now. (I wrote an article: http://whitequark.org/blog/2012/12/06/a-language-for-embedded-developers/) 2012-12-30 20:41 my strategy for memory management is currently as follows: 2012-12-30 20:42 1. perform region analysis and put all objects which lifetime does not exceed those of the current stack frame to the stack 2012-12-30 20:42 2. have a heap divided into fixed-size (16- or 32-byte) blocks to avoid fragmentation and have fast, constant-time allocation 2012-12-30 20:42 3. use automatic reference counting with write barriers inserted by the compiler for fast, constant-time deallocation 2012-12-30 20:43 4. use copy-on-write and ropes for strings and arrays 2012-12-30 20:45 sounds ok'ish to me, but I wouldn't know too much to contribute anyway 2012-12-30 20:45 oh ok 2012-12-30 20:45 now, a bit about the other side of the coin 2012-12-30 20:46 probably wpwrak has some better expertise and comments on such stuff 2012-12-30 20:47 in a nutshell, I use Ruby for three things here: 2012-12-30 20:47 1. it compiles down to native code which executes on the target device 2012-12-30 20:48 2. it executes on host to generate other Ruby code. Think of it as a C preprocessor done right, or a simple and safe form of Lisp macro expansion 2012-12-30 20:48 3. it executes on host with target semantics, which is basically the same as constant folding performed by modern C compilers, but well-defined and more extensive. 2012-12-30 20:49 (I think that C++11 with its well-defined constant folding semantics is close to what I want, but not entirely sure) 2012-12-30 20:50 the expected benefit is to decouple intended semantics of your code from accidental semantics of, for example, C, and its way to handle the target and its quirks. 2012-12-30 20:51 whitequark: just wondering, how do you compile Ruby down to native code? And what do you exactly mean by "native code"? 2012-12-30 20:51 would you, as embedded developers, want to use such language? if not, why? 2012-12-30 20:51 kyak: compiling ruby to native code is easy. Obj-C is basically the exact same stuff 2012-12-30 20:52 compiling ruby to _efficient_ machine code is much harder 2012-12-30 20:52 I've added static typing, and type inference for you to avoid writing unnecessary code 2012-12-30 20:53 kyak: "native code" here means that there is no interpreter and, additionally, you are not isolated from details of your hardware unless you opt to. 2012-12-30 20:53 ok, so you go directly from Ruby to machine code? How much would you have to change if you want to support another target? 2012-12-30 20:54 kyak: well, not directly. I have my own SSA IR which resembles Ruby semantics (the IR itself is modelled after LLVM IR), and which I optimize, and then I convert it to the LLVM IR 2012-12-30 20:55 (another target) it depends. CPU architectures are handled by LLVM, so adding one means I just need to find a decent C++ dev 2012-12-30 20:55 board support packages, on the other hand, are written entirely in Ruby 2012-12-30 20:56 i see.. it's very interesting 2012-12-30 20:56 obviously you need to adapt them across different families, but given how flexible Ruby is, it would be way, way simpler than in C 2012-12-30 20:56 and you could also assign this task to Ruby programmers :) 2012-12-30 20:57 do i understand correctly, i have Ruby code, then i get the IR which is used by LLVM to convert to a specific machine code? 2012-12-30 20:58 kyak: Ruby code -> (parsing, translating) -> Ruby IR -> (optimizing) -> Ruby IR -> (translating) -> LLVM IR -> (llvm) -> machine code 2012-12-30 20:59 i see.. How do you verify your machine code against Ruby code? I mean, this chain is error-prone 2012-12-30 21:00 kyak: it is not inherently more error-prone than ones in GCC or LLVM Clang themselves 2012-12-30 21:00 so the answer is, test coverage. 2012-12-30 21:00 I don't do formal verification. It's not even possible for almost all real-world code. 2012-12-30 21:00 yeah, compiler is also adding possible errors 2012-12-30 21:02 kyak: don't forget humans, who quite certainly add a lot of errors ;) 2012-12-30 21:03 you probably won't use v1.0 to control your car. but that applies to any different compiler as well. 2012-12-30 21:03 what you are doing is very interesting. In fact, such approach is widely used in some tools. For example, MATLAB (being a high-level language of technical computing) and Simulink (being a tool for system-level modeling via block diagrams) can both be converted to C code (that's a bit different from your approach where you don't actually get the readable code) 2012-12-30 21:03 I'm fine starting with TV remotes. 2012-12-30 21:04 I could use LLVM C backend to generate C code 2012-12-30 21:04 it would even make quite some sense, for this kind of auto-generated stuff 2012-12-30 21:04 eg you could clearly see objects, theirs methods, lambda functions, etc 2012-12-30 21:05 it is also a general trend in last years to use higher level languages for embedded systems development (namely, the automatic C code generation) - because the systems are getting so complex 2012-12-30 21:05 the idea of GC in embedded code makes me feel somewhat uncomfortable 2012-12-30 21:06 :) 2012-12-30 21:06 I'm still using assembler ;-P 2012-12-30 21:07 I don't think is that bad. 2012-12-30 21:07 it's just a matter to write it well enough. 2012-12-30 21:07 generally speaking I'd try to avoid resource allocation and freeing in embedded, if any possible 2012-12-30 21:07 how do you deal with real-time requirements and GC 2012-12-30 21:07 wpwrak: see how many smartcards run java :) 2012-12-30 21:07 do those smartcards have a gc? 2012-12-30 21:08 I don't see why not 2012-12-30 21:08 wpwrak, DocScrutinizer05: I fully agree. It is well possible to write a program without GC with this approach, if you only use global data and stack-allocated temporaries (as it is often the case) 2012-12-30 21:08 i think it's a great exercise anyway, and definitely we will have to go to a higher level than C 2012-12-30 21:08 hozer: they do have a GC. There are realtime GCs out there 2012-12-30 21:08 python is the way to go ;) 2012-12-30 21:08 hozer: you have two choices: 1) you leave room for worst-case GC. 2) you don't to GC ;-) 2012-12-30 21:08 yes. 2012-12-30 21:09 so easy. 2012-12-30 21:09 s/to/do/ 2012-12-30 21:09 wpwrak meant: "hozer: you have two choices: 1) you leave room for worst-case GC. 2) you don't do GC ;-)" 2012-12-30 21:09 I'll take option-2 for my engine controller please 2012-12-30 21:09 yeah 2012-12-30 21:09 You can have real-time embedded systems with memory leaks, instead ;) 2012-12-30 21:10 whitequark: maybe just make it a fatal error to do anything that would require GC 2012-12-30 21:10 don't allocate memory 2012-12-30 21:10 in smaller embedded systems, you don't have resources to throw around anyway 2012-12-30 21:10 wpwrak: yes, there would be a possibility to disable heap compile-time. I don't see why not. 2012-12-30 21:10 hozer: if you don't allocate memory, you won't be running a gc 2012-12-30 21:10 ARC doesn't have problems which GC's often have. 2012-12-30 21:10 if there's no memory allocation, there can be no memory leaks :P 2012-12-30 21:10 it has predictable allocation and deallocation times, which are also fixed if the heap doesn't fragment. 2012-12-30 21:11 forget about the GC, think about higher level languages. 2012-12-30 21:11 so I think it does suit a lot of embedded systems well. 2012-12-30 21:11 what is arc 2012-12-30 21:11 hozer: automatic reference counting 2012-12-30 21:11 kyak says a very important thing. there shouldn't be a reason why your register couldn't have a high-level representation 2012-12-30 21:12 which is both a pleasure to work with (PLL.lock_at(16_000_000)) and compiles to machine code which is as efficient as if you'd do that in C. 2012-12-30 21:12 I like ARC, and a circular reference (that breaks ARC) should be a fatal exception and the thing turns off ;) 2012-12-30 21:13 because you are going to get memory corruption and some point, and the system should gracefully power off when that happens 2012-12-30 21:13 s/and/at/ 2012-12-30 21:13 hozer meant: "because you are going to get memory corruption at some point, at the system should gracefully power off when that happens" 2012-12-30 21:14 hozer: a generally accepted solution is to use weak references and/or include a mark&sweep GC in addition to ARC 2012-12-30 21:14 but weak refs are quite heavy 2012-12-30 21:14 so you either use mark&sweep GC if you don't have to care about realtime, or you look after yourself and break loops manually. 2012-12-30 21:16 considering that you'll typically in a memory-constrained context, you may want to have explicit allocation limits 2012-12-30 21:17 e.g., given objects of type A, B, and C, something like: A | 2*B | A+C 2012-12-30 21:17 so you either allocate an A and maybe a C too, or neither A nor C, but two B 2012-12-30 21:17 wpwrak: at which point would I enforce this limit? 2012-12-30 21:18 you may optionally check for them 2012-12-30 21:18 it's about static analysis 2012-12-30 21:18 no? 2012-12-30 21:18 it's about compile-time allocation 2012-12-30 21:18 it would basically be the programmer telling the compiler what resource use is expected 2012-12-30 21:19 wpwrak: well, CFA and DFA allow me to infer this information, sometimes 2012-12-30 21:19 it's up to the programmer to ensure this isn't violated, be it by checking in the code (and implementing a recovery strategy in case of a conflict), or by ensuring that, implicitly, this can't happen 2012-12-30 21:20 whitequark: of course, you may find that you're rapidly approaching C semantics with all this :) 2012-12-30 21:20 wpwrak: ah, I see what you mean. Interesting approach. I have some aversion to techniques which require the programmer to ensure something isn't violated, but this is probably a result of writing too much Ruby 2012-12-30 21:21 you could add checks, but they would basically be of the type if (check_is_okay) do_it(); else panic(); 2012-12-30 21:21 wpwrak: C semantics isn't all that bad. The parts which closely resemble and allow you to work directly with hardware resources are very useful 2012-12-30 21:22 Inability to build any abstrctions around those parts is what's bad 2012-12-30 21:22 the compiler is also too stupid sometimes, where it has no reason to. 2012-12-30 21:23 for example, I do not understand why, in absence of mutually recursive functions (which are WRONG in embedded anyway), a compiler couldn't determine optimal stack depth at compile time by itself. 2012-12-30 21:23 in C (in embedded systems), you'd normally just have static allocations for such things. but of course, that could waste memory. 2012-12-30 21:23 wpwrak: (such things) which? 2012-12-30 21:24 e.g., if you have two subsystems which each need some buffers, but they're not active at the same time 2012-12-30 21:24 once the memory is physically there, and only for you, it is no waste. 2012-12-30 21:24 wpwrak: ah, I understand what you mean. I'll think of possible solutions for this problem. 2012-12-30 21:25 pcercuei has quit [Ping timeout: 260 seconds] 2012-12-30 21:25 note that I do not enforce memory safety. Precisely nothing prevents you from allocating a region of bytes and then using whatever you want with it. 2012-12-30 21:26 I only provide any guarantees if you use provided abstractions in well-defined way. Which is basically what C does as well. (Except that my *default* abstraction for strings prevents you from getting buffer overruns all over the place. You get the idea.) 2012-12-30 21:27 (resources / allocation) I tend to define "static" variables, and for any re-use I simply use unions on same memory range, used in mutually exclusive program branches 2012-12-30 21:27 wpwrak: (two subsystems) in fact this is probably best solved by stack allocation, yeah 2012-12-30 21:27 DocScrutinizer05 uses what I've described before that 2012-12-30 21:27 so no need to GC anything 2012-12-30 21:28 C is not that bad if you take malloc and free out :) 2012-12-30 21:29 a thing I'll also be able to do (and of which I'm quite proud that it is possible) is that you could execute code with target semantics on your host 2012-12-30 21:29 which means: 2012-12-30 21:29 1) unit tests 2012-12-30 21:29 whitequark: some sort of stack. not necessarily the regular stack. 2012-12-30 21:29 GitHub76 has joined #qi-hardware 2012-12-30 21:29 13j1soc/06master 1495d55a0 15Cristian Paul Peñaranda Rojas: from RAMB16_S to RAMB16BWER, soc nows builds please check log 2012-12-30 21:29 GitHub76 has left #qi-hardware [#qi-hardware] 2012-12-30 21:29 01[13j1soc01] 15kristianpaul pushed 1 new commit to 06master: 02https://github.com/kristianpaul/j1soc/commit/95d55a016e8966e42bbd37954c5de3e6e5809b0f 2012-12-30 21:30 even better, unit tests where your mock peripherals can be written in regular Ruby, simplifying that a lot 2012-12-30 21:30 whitequark: e.g., you may have modes of operation but some common code as well. so you'll return to your main event handler or whatever, but you'd then switch modes. 2012-12-30 21:30 it would be nice if any assembler/compiler would throw an error when a function of branch B is called in branch A where conflicting uses of a memory range would create colliding visibility of different cases of same range 2012-12-30 21:30 can you make this work so I can write perphirals in python too ;) 2012-12-30 21:30 yay, I wonder if anybody could parse the above 2012-12-30 21:30 if an event appears that doesn't match the current mode, you'd ignore it, abandon the previous mode, etc. 2012-12-30 21:31 wpwrak, DocScrutinizer05: well, with the stack allocation, the compiler would enforce that implicitly 2012-12-30 21:31 with more complex system like modes, there probably isn't a way to verify this in compiler 2012-12-30 21:31 But what if this memory range is hardware registers (like say Infiniband verbs stuff) 2012-12-30 21:31 (I suspect it can be proven that general case is equivalent to halting problem) 2012-12-30 21:31 whitequark: (target semantics on the host) just a question of writing the appropriate wrapper :) 2012-12-30 21:32 whitequark: yup, for stack stuff is pretty simple 2012-12-30 21:32 wpwrak: what if your target has 16-bit ints? things get pretty painful, and emulators often aren't what you want 2012-12-30 21:32 in assembler however you tend to think of stack as a location to push registers and PC 2012-12-30 21:32 hozer: (python) sorry, only Ruby. they're very similar, you won't have problems learning one if you know another one. 2012-12-30 21:32 whitequark: easy: don't use "int". use "int16_t" instead. 2012-12-30 21:33 wpwrak: aaand what if your target has non-IEEE floating point semantics? :D 2012-12-30 21:33 like ARM NEON 2012-12-30 21:34 whitequark: I've got python code that's been running for several years, I'd like to be able to just use it instead of rewriting it 2012-12-30 21:34 \o/ NEON 2012-12-30 21:34 god created the integer. all else is heresy :) 2012-12-30 21:34 hozer: I suspect that in this case, some form of IPC would suffice. I'd think about implementing that someday. It depends on exact application, through. 2012-12-30 21:35 in another channel some guys investigating NEON vs genuine ARM since a few days. Results are not that encouraging 2012-12-30 21:35 zear_ has joined #qi-hardware 2012-12-30 21:35 couldn't use use the same pythong to llvm approach? Can swig make python<->ruby interfaces? 2012-12-30 21:35 zear has quit [Ping timeout: 265 seconds] 2012-12-30 21:35 s/pythong/python/ 2012-12-30 21:35 hozer meant: "couldn't use use the same python to llvm approach? Can swig make python<->ruby interfaces?" 2012-12-30 21:36 hozer: hm, there are existing ruby<>python bridge in fact. yes, you could use that. 2012-12-30 21:36 *there is 2012-12-30 21:36 this is how github highlights syntax on the website. yeah, one EXTRA FAT interpreter uses another EXTRA FAT interpreter :D 2012-12-30 21:37 git highlights syntax using python running in ruby? 2012-12-30 21:37 github. yes. 2012-12-30 21:37 it seems that pygments is much better than any existing Ruby alternative. 2012-12-30 21:37 hilarous. So the question is how many bytes of object code does this fatness compile to after you run your magic ;) 2012-12-30 21:37 hozer: I don't compile whatever runs on the host 2012-12-30 21:38 [2012-12-30 18:35:23] freemangordon: what's this new libpng? 2012-12-30 21:38 [2012-12-30 18:35:25] NEONized one? 2012-12-30 21:38 [2012-12-30 18:35:43] luf: why don't you test it, pngtest binary is here http://merlin1991.at/~freemangordon/libpng/ 2012-12-30 21:38 [2012-12-30 18:35:46] kerio: yes 2012-12-30 21:38 hozer: there is no point to. well, you could use Rubinius (Ruby with LLVM backend), or JRuby (which is pretty awesome), but x86 hw is fast enough to use anything 2012-12-30 21:39 wpwrak: you see, in my case there isn't even such a quetion. Everything is a method call. 5.0 + 10.0 is 5.0.+(10.0) 2012-12-30 21:39 well, I want to develop stuff for the embedded platform in python+ruby 2012-12-30 21:39 what I really want is something that outputs YASEP code ;) 2012-12-30 21:40 wpwrak: for the target, it's defined as a plain primitive floating-point operation. for the host, you can write whatever code you'd want to emulate however weird the behavior of your target is. all completely transparently :) 2012-12-30 21:40 hozer: port LLVM to codegen for it 2012-12-30 21:41 hopefully LLVM codegen is a lot easier than GCC codegen 2012-12-30 21:41 YASEP is, to be sincere, somewhat fringe for me, but I don't see why underlying concepts couldn't work. I just don't expect it to become anyhow wirespread 2012-12-30 21:42 hozer: writing for LLVM is a joy. except for the whole C++ part, but they use a subset of C++ which doesn't hurt your brain and isn't slow 2012-12-30 21:42 well, so far yasep is the cleanest open-source processor design I've run across. 2012-12-30 21:43 I want a synthesizable embedded cpu core, first for fpgas and eventually for homebrew ASIC 2012-12-30 21:45 (homebrew ASIC) things got really cheap right now. I don't see why someone sufficiently motivated couldn't reproduce 4004 in their garage 2012-12-30 21:45 leon-sparc might work, but it's a bit heavyweight 2012-12-30 21:45 it shouldn't be that hard to replicate top-notch 1960's tech in 2012. 2012-12-30 21:45 there's no way I'm ever going to produce a leon-sparc in my garage, at least for 5-10 years 2012-12-30 21:46 leon-sparc absolutely 2012-12-30 21:46 but 8051? why not? 2012-12-30 21:46 I'd prefer a cleanroom open-source design 2012-12-30 21:46 well, by saying "8051" I mean the order of complexity, not a particular ISA or design 2012-12-30 21:47 also, why not openrisc32? 2012-12-30 21:47 find me a git or mercurial repo of openrisc32, and I'll start trying to build an fpga bitstream later today :P 2012-12-30 21:48 svn + opencores.org 2012-12-30 21:48 opencores.org's obnoxious registration and clunky interface drove me away. 2012-12-30 21:49 hozer: svn co http://opencores.org/ocsvn/openrisc/openrisc/trunk 2012-12-30 21:52 whitequark: I take that back. I could not find that link when I went looking for it 2012-12-30 21:52 hozer: first link in google :) 2012-12-30 21:52 http://opencores.org/or1k/OR1200_OpenRISC_Processor 2012-12-30 21:52 Can someone please confirm that http://www.latticesemi.com/dynamic/view_document.cfm?document_id=38780 is actually a DFSG-compliant bsd-style license? 2012-12-30 21:53 whitequark: have you ever registered with opencores.org 2012-12-30 21:54 hozer: probably no 2012-12-30 21:54 I don't see an entry in keepassx 2012-12-30 21:55 well, I wonder if they changed it. I tried to download some variation of the OR12k SOC and I had to register before I could get SVN access 2012-12-30 21:55 oh. no idea about that 2012-12-30 21:55 hozer: there are some interesting clauses in that license 2012-12-30 21:55 namely, export restrictions 2012-12-30 21:56 also you need to clearly identify the parts you've changed, but I think that lies within DFSG. IANAL, through. 2012-12-30 21:56 I guess that explains why milkymist doesn't incldue it 2012-12-30 21:58