#qi-hardware IRC log for Sunday, 2012-12-30

wolfspra1lthanks for the headsup about the server06:23
wolfspra1lit's limping along :-)06:23
qi-bot[commit] Werner Almesberger: lpc111x-isp/lpc111x.c: straighten *dialog*() API; radically simplify tracing (master) http://qi-hw.com/p/ben-blinkenlights/eda113507:01
qi-bot[commit] Werner Almesberger: lpc111x-isp/lpc111x.c (identify): retrieve and print the chip's unique ID (master) http://qi-hw.com/p/ben-blinkenlights/505caf907:01
qi-bot[commit] Werner Almesberger: libubb/swuart.c (swuart_open): don't call ubb_power (master) http://qi-hw.com/p/ben-blinkenlights/be82db007:01
qi-bot[commit] Werner Almesberger: lpc111x-isp/lpc111x.c: new option -n to disable powering the device (master) http://qi-hw.com/p/ben-blinkenlights/b2f131007:01
qi-bot[commit] Werner Almesberger: lpc111x-isp/lpc111x.c: read and dump (to stdout) the entire Flash (master) http://qi-hw.com/p/ben-blinkenlights/5246f5f07:01
wpwrakwhee, works again ! :) thanks !07:01
xiangfuyes. (en.qi-hardware.com) works fine here.07:09
wpwrakwolfspra1l: 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 ?07:12
kyakwpwrak: do you use PWM to control LED brightness with 8:10 card, or it is a simple on/off?07:52
wpwrakhmm, you mean "is there a PWM one could use with UBB" ?07:56
wpwrakand answer to that would be "no". all you have there is the MMC controller07:57
wpwrakyou can use it to send finite bit patterns (see ubb-vga) but it's not really a PWM07:57
wpwrakdepending on the accuracy you need, you can hack various alternatives07:58
wpwrake.g., you could do a software PWM in unprivileged user space if you don't mind the occasional scheduling interruption07:58
kyakyep, we already had this discussion and just re-read the log :)07:59
wpwrakor privileged user space (with real-time priority) if you don't mind the occasional interrupt07:59
wpwrakor heavily nasty privileged user space (disabling interrupts) if you don't mind cache delays08:00
kyakhow about various real-time patches to linux kernel? would they help?08:00
wpwrakor use the MMC controller to get rid of cache delays as well, but have an anomaly at block boundaries08:00
wpwraknot sure. i didn't keep track of them08:02
wpwrakah, more options: use timers vs. bust looping08:02
kyakso, it turns to be a quite limited GPIO..08:02
wpwrakyes. if you need resource-friendly tight timing, you need to add some MCU08:03
wpwraklike this critter: http://en.qi-hardware.com/wiki/File:Uart-inserted.jpg08:04
kyakmaybe 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 :)08:05
wpwrakyeah, why not :)08:05
kyakso, you use gpios to command mcu, and it in turn doesn't the real-time thing?08:06
kyakwell, basically, it's ben-wpan :)08:06
wpwrakbut if your external stuff isn't timing-critical or if it is but you can cheat, then you don't need any of this08:08
wpwrakubb-vga is one example of cheating08:08
wpwrakswuart is another one08:08
kyaktaking 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-bridge08:08
wpwrakyou could probably even make a low- or even full-speed device or a USB host08:09
wpwrakatben has no firmware. only atusb does, but that's not for the ben08:09
kyakyep, so all applications where i don't need determinism, i can cheat08:09
wpwrakall applications where you need precise timing only for a reasonably short interval and where you need rapid responses only within a reasonably short time interval08:11
kyakhow come atben has no firmware? i see there is some mcu :)08:11
wpwrakthat's the transceiver :)08:11
kyakand you control the transceiver with gpios, right?08:11
wpwrakyup. is talks SPI plus a few control signals with the ben08:11
kyakok... i see08:12
kyakit means that we also have SPI :)08:12
wpwraksee also: http://projects.qi-hardware.com/schhist/atben/pdf_atben.pdf08:12
wpwrakSPI is very very easy :)08:12
kyakif i have a temperature sensor that talks i2c, connecting it to 8:10 card would be a piece of cake, right?08:14
wpwrakif 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/)08:15
wpwrakyup, i2c has no problematic timing constraints08:16
kyakheh, it seems that you've exploited this MMC controller to the full :)08:16
wpwrakthe only things that suck are maximum response times. minimum response times are never a problem08:16
wpwrakoh, all those just bit-bang08:16
wpwrakthe only thing where i used the MMC controller is ubb-vga08:16
wpwraki turn interrupts off in ubb-vga and swuart08:17
kyakbut when you use those 6 GPIOs, don't you use MMC controller?08:17
wpwraknew, i just use them as gpios08:17
kyakhm.. i thought these gpios are coming from mmc controller08:18
wpwrakin 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 often08:19
wpwrakeach pin can be switched between several functions, e.g., gpio, interrupts, or some hardwired function block (mmc, spi, ...)08:20
wpwrakwell, almost each i/o pin08:20
wolfspra1lregarding fpgatools, people need to come forward if they want something08:21
kyakhow do you decide which way to go - get rt priority and leave interrupts on, or to turn off interrupts?08:21
wolfspra1lI will react then08:21
wolfspra1lat this point the sw is in such alpha state that you couldn't run much on actual hardware08:22
wolfspra1lI 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 goodies08:23
wpwrakyeah, that was the next item on the list08:23
wpwrakkyak: basically based on how precise things have to be and how bad it is if i miss the timing08:23
kyakwpwrak: i see.. btw, can we disable interrupts that simple on x86? :)08:24
wpwrakwolfspra1l: 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.08:25
wpwrakkyak: just tell the interrupt controller to shut up ? ;)08:26
wpwrakkyak: 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 kernel08:27
kyakso that you could creash it much better :)08:28
wpwrakwell, in the kernel i have functions that manage resources for me, etc.08:29
wpwrakon the ben, i can get away with just saying "timer 3 is MINE now". but i wouldn't dare that on x8608:29
kyakbut why not? what's so different?08:30
kyakyou dont know which peripheal might be driven by that timer?08:30
wpwrakyup. on x86 i have no idea what may grab timers and such08:31
wpwrakon the ben, life is simpler and more stable08:31
wpwrakand there are also hardware abstractions on x86 the kernel takes care of for me. on the ben, there's just one hardware08:32
wpwrakso no guessing how interrupts may be routed, etc.08:33
kyakx86 is so complicated, it always makes we wonder how real time are real-time solutions based on x8608:33
kyakthere is a huge market for x86 simulators, for example08:34
wpwrakx86 simulators ?08:34
kyakand they are real-time, yes08:34
kyakoh, i mean, simulators based on x8608:35
kyakif you ever heard of Opal-Rt, dSpace, xPC Target - these are all x8608:36
kyaksome are running "red-hat linux with real-time patches", some are running win32-compatible RTOS08:37
wpwrakwell, for reasonably lax RT, a lot of things are possible08:37
wpwrakfor 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 :)08:40
wpwrakswuart 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)08:41
kyakyep, everything below 1 us is usually offloaded to FPGA (http://www.opal-rt.com/electrical-system-overview)08:41
kyakbut all of these providers have no problems with capturing a high-frequency PWM or doing quadrature decoding in real-time08:42
wpwraka  little fpga can go a long way when it comes to relaxing your timing08:45
kyakanyway, thanks for the chat.. time to do some new year preparations :)08:46
wpwrakah, the booze shopping :)08:47
kyakin fact, did that one week ago. It would've been a suicide to go to a store today and tomorrow :)09:09
DocScrutinizer05RT 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 minutes19:41
DocScrutinizer05depending on the particular system19:41
DocScrutinizer05generally RT isn't about speed but about predictability and determinism19:42
whitequarkbut then you discover that your maximum delay is not small enough...19:46
DocScrutinizer05following 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 IRQ19:46
DocScrutinizer05otoh extreme speed requirements (like werber's VGA hack) might not have real hard RT requirements, if you tolerate occasional artifacts in your display19:47
whitequarkDocScrutinizer05: I'd say that technically it does have hard RT requirement, as with some delays you'd lose sync19:48
DocScrutinizer05whitequark: 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 19:51
DocScrutinizer05basically the timing requirements for a VGA output are mostly unrelated to those specified for a RT system19:52
DocScrutinizer05e.g jitter isn't even a topic for RT19:53
whitequarkDocScrutinizer05: 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 task19:56
DocScrutinizer05yes, such a thing like a GC disqualifies the system for both RT and the wpwrak VGA hack19:58
wpwrakvery much so ;-)19:58
DocScrutinizer05still doesn't mean RT and VGA hack have any common denominator19:58
wpwrakyou have these parameters in all systems: what bounds you want to be met and the consequences of failure to meet them.19:59
kyakwpwrak: would it be a catastrophic failure for your system if it misses a single deadline?19:59
whitequarkDocScrutinizer05: but don't requirements for the VGA hack (the need to output sync signals in time) qualify it to be an RT system?19:59
whitequarkDocScrutinizer05: I don't understand why not19:59
DocScrutinizer05what 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 all19:59
wpwrakin the case of ubb-vga, failure isn't catastrophic. but of course, if it happens too often, people will dislike it.19:59
kyaki don't like this word, but then your system is "soft real-time"20:00
wpwraki think many screens have something like a PLL. so if you get the timing wrong too often, the PLL will start to wander.20:00
wpwrakDocScrutinizer05: yes, it's quite atypical RT.20:01
wpwrakat least in the context of software RT20:01
wpwraknot so much in the context of hardware RT. e.g., you don;t really expect a UART to jitter significantly20:01
DocScrutinizer05generally you expect hw to be "real time"20:02
whitequarkDocScrutinizer05: or, in other words, what I mean is that requirements for the vga hack is a superset of typical requirements for an RT system20:02
DocScrutinizer05exceptions frequently need very special notice20:02
DocScrutinizer05whitequark: nope, not all of them, since RT *never* allows any glitch20:03
wpwrakevery system glitches :)20:03
whitequarkDocScrutinizer05: I see20:04
DocScrutinizer05while. as explained above, you could output a complete black H-line on ubb-vga every now and then and it wouldn't matter too much20:04
wpwrakthe question is what happens then. 1) nobody even notices. 2) a few raised eyebrows. 3) a murder investigation. 4) etc.20:05
DocScrutinizer05the requirements for ubb-vga are simply different from the definition of RT, though admittedly quite a few of them can be found in RT defs20:05
whitequarkDocScrutinizer05: thanks for explanation20:06
DocScrutinizer05on a related topic: do you know why TV RF is specified as "stronger signal for darker pixel"?20:06
DocScrutinizer05random noise would usually add to the signal level from transmitter, thus causing dark spots instead of white spots20:07
DocScrutinizer05your eye will ignore those transient dark spots pretty much20:07
whitequarkDocScrutinizer05: but why does it add to the signal level?20:08
wpwrakthe eye's ability to remember photons is indeed quite remarkable20:08
DocScrutinizer05whitequark: because of two signals rather add than interfere to mutually eliminate 20:11
DocScrutinizer05since for audio same physiological trick obviously doesn't work, they chosen AM for video and FM for audio signal of TV20:12
whitequarkby the way, what do you guys think about automatic reference counting as a memory management strategy?20:35
DocScrutinizer05common strategy, used e.g in Qt20:39
DocScrutinizer05combined with copy-on-modify for optimization of string handling20:40
whitequarkDocScrutinizer05: 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/)20:41
whitequarkmy strategy for memory management is currently as follows:20:41
whitequark1. perform region analysis and put all objects which lifetime does not exceed those of the current stack frame to the stack20:42
whitequark2. have a heap divided into fixed-size (16- or 32-byte) blocks to avoid fragmentation and have fast, constant-time allocation20:42
whitequark3. use automatic reference counting with write barriers inserted by the compiler for fast, constant-time deallocation20:42
whitequark4. use copy-on-write and ropes for strings and arrays20:43
DocScrutinizer05sounds ok'ish to me, but I wouldn't know too much to contribute anyway20:45
whitequarkoh ok20:45
whitequarknow, a bit about the other side of the coin20:45
DocScrutinizer05probably wpwrak has some better expertise and comments on such stuff20:46
whitequarkin a nutshell, I use Ruby for three things here:20:47
whitequark1. it compiles down to native code which executes on the target device20:47
whitequark2. 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 expansion20:48
whitequark3. 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.20:48
whitequark(I think that C++11 with its well-defined constant folding semantics is close to what I want, but not entirely sure)20:49
whitequarkthe 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.20:50
kyakwhitequark: just wondering, how do you compile Ruby down to native code? And what do you exactly mean by "native code"?20:51
whitequarkwould you, as embedded developers, want to use such language? if not, why?20:51
whitequarkkyak: compiling ruby to native code is easy. Obj-C is basically the exact same stuff20:51
whitequarkcompiling ruby to _efficient_ machine code is much harder20:52
whitequarkI've added static typing, and type inference for you to avoid writing unnecessary code20:52
whitequarkkyak: "native code" here means that there is no interpreter and, additionally, you are not isolated from details of your hardware unless you opt to.20:53
kyakok, so you go directly from Ruby to machine code? How much would you have to change if you want to support another target?20:53
whitequarkkyak: 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 IR20:54
whitequark(another target) it depends. CPU architectures are handled by LLVM, so adding one means I just need to find a decent C++ dev20:55
whitequarkboard support packages, on the other hand, are written entirely in Ruby20:55
kyaki see.. it's very interesting20:56
whitequarkobviously you need to adapt them across different families, but given how flexible Ruby is, it would be way, way simpler than in C20:56
whitequarkand you could also assign this task to Ruby programmers :)20:56
kyakdo i understand correctly, i have Ruby code, then i get the IR which is used by LLVM to convert to a specific machine code?20:57
whitequarkkyak: Ruby code -> (parsing, translating) -> Ruby IR -> (optimizing) -> Ruby IR -> (translating) -> LLVM IR -> (llvm) -> machine code20:58
kyaki see.. How do you verify your machine code against Ruby code? I mean, this chain is error-prone20:59
whitequarkkyak: it is not inherently more error-prone than ones in GCC or LLVM Clang themselves21:00
whitequarkso the answer is, test coverage.21:00
whitequarkI don't do formal verification. It's not even possible for almost all real-world code.21:00
kyakyeah, compiler is also adding possible errors21:00
whitequarkkyak: don't forget humans, who quite certainly add a lot of errors ;)21:02
whitequarkyou probably won't use v1.0 to control your car. but that applies to any different compiler as well.21:03
kyakwhat 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)21:03
whitequarkI'm fine starting with TV remotes.21:03
whitequarkI could use LLVM C backend to generate C code21:04
whitequarkit would even make quite some sense, for this kind of auto-generated stuff21:04
whitequarkeg you could clearly see objects, theirs methods, lambda functions, etc21:04
kyakit 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 complex21:05
wpwrakthe idea of GC in embedded code makes me feel somewhat uncomfortable21:05
DocScrutinizer05I'm still using assembler ;-P21:06
viricI don't think is that bad.21:07
viricit's just a matter to write it well enough.21:07
DocScrutinizer05generally speaking I'd try to avoid resource allocation and freeing in embedded, if any possible21:07
hozerhow do you deal with real-time requirements and GC21:07
viricwpwrak: see how many smartcards run java :)21:07
hozerdo those smartcards have a gc?21:07
viricI don't see why not21:08
whitequarkwpwrak, 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)21:08
kyaki think it's a great exercise anyway, and definitely we will have to go to a higher level than C21:08
whitequarkhozer: they do have a GC. There are realtime GCs out there21:08
hozerpython is the way to go ;)21:08
wpwrakhozer: you have two choices: 1) you leave room for worst-case GC. 2) you don't to GC ;-)21:08
viricso easy.21:09
hozerI'll take option-2 for my engine controller please21:09
viricYou can have real-time embedded systems with memory leaks, instead ;)21:09
wpwrakwhitequark: maybe just make it a fatal error to do anything that would require GC21:10
hozerdon't allocate memory21:10
wpwrakin smaller embedded systems, you don't have resources to throw around anyway21:10
whitequarkwpwrak: yes, there would be a possibility to disable heap compile-time. I don't see why not.21:10
virichozer: if you don't allocate memory, you won't be running a gc21:10
whitequarkARC doesn't have problems which GC's often have.21:10
hozerif there's no memory allocation, there can be no memory leaks :P21:10
whitequarkit has predictable allocation and deallocation times, which are also fixed if the heap doesn't fragment.21:10
kyakforget about the GC, think about higher level languages.21:11
whitequarkso I think it does suit a lot of embedded systems well.21:11
hozerwhat is arc21:11
whitequarkhozer: automatic reference counting21:11
whitequarkkyak says a very important thing. there shouldn't be a reason why your register couldn't have a high-level representation21:11
whitequarkwhich 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.21:12
hozerI like ARC, and a circular reference (that breaks ARC) should be a fatal exception and the thing turns off ;)21:12
hozerbecause you are going to get memory corruption and some point, and the system should gracefully power off when that happens21:13
whitequarkhozer: a generally accepted solution is to use weak references and/or include a mark&sweep GC in addition to ARC21:14
whitequarkbut weak refs are quite heavy21:14
whitequarkso you either use mark&sweep GC if you don't have to care about realtime, or you look after yourself and break loops manually.21:14
wpwrakconsidering that you'll typically in a memory-constrained context, you may want to have explicit allocation limits21:16
wpwrake.g., given objects of type A, B, and C, something like: A | 2*B | A+C21:17
wpwrakso you either allocate an A and maybe a C too, or neither A nor C, but two B21:17
whitequarkwpwrak: at which point would I enforce this limit?21:17
wpwrakyou may optionally check for them21:18
viricit's about static analysis21:18
wpwrakit's about compile-time allocation21:18
wpwrakit would basically be the programmer telling the compiler what resource use is expected21:18
whitequarkwpwrak: well, CFA and DFA allow me to infer this information, sometimes21:19
wpwrakit'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 happen21:19
wpwrakwhitequark: of course, you may find that you're rapidly approaching C semantics with all this :)21:20
whitequarkwpwrak: 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 Ruby21:20
wpwrakyou could add checks, but they would basically be of the type  if (check_is_okay) do_it(); else panic();21:21
whitequarkwpwrak: C semantics isn't all that bad. The parts which closely resemble and allow you to work directly with hardware resources are very useful21:21
whitequarkInability to build any abstrctions around those parts is what's bad21:22
whitequarkthe compiler is also too stupid sometimes, where it has no reason to.21:22
whitequarkfor 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.21:23
wpwrakin C (in embedded systems), you'd normally just have static allocations for such things. but of course, that could waste memory.21:23
whitequarkwpwrak: (such things) which?21:23
wpwrake.g., if you have two subsystems which each need some buffers, but they're not active at the same time21:24
viriconce the memory is physically there, and only for you, it is no waste.21:24
whitequarkwpwrak: ah, I understand what you mean. I'll think of possible solutions for this problem.21:24
whitequarknote 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.21:25
whitequarkI 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.)21:26
DocScrutinizer05(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 branches21:27
whitequarkwpwrak: (two subsystems) in fact this is probably best solved by stack allocation, yeah21:27
whitequarkDocScrutinizer05 uses what I've described before that21:27
DocScrutinizer05so no need to GC anything21:27
viricC is not that bad if you take malloc and free out :)21:28
whitequarka 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 host21:29
whitequarkwhich means:21:29
whitequark1) unit tests21:29
wpwrakwhitequark: some sort of stack. not necessarily the regular stack.21:29
GitHub7601[13j1soc01] 15kristianpaul pushed 1 new commit to 06master: 02https://github.com/kristianpaul/j1soc/commit/95d55a016e8966e42bbd37954c5de3e6e5809b0f21:29
GitHub7613j1soc/06master 1495d55a0 15Cristian Paul PeƱaranda Rojas: from RAMB16_S to RAMB16BWER, soc nows builds  please check log21:29
whitequarkeven better, unit tests where your mock peripherals can be written in regular Ruby, simplifying that a lot21:30
wpwrakwhitequark: 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.21:30
DocScrutinizer05it 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 range21:30
hozercan you make this work so I can write perphirals in python too ;)21:30
DocScrutinizer05yay, I wonder if anybody could parse the above21:30
wpwrakif an event appears that doesn't match the current mode, you'd ignore it, abandon the previous mode, etc.21:30
whitequarkwpwrak, DocScrutinizer05: well, with the stack allocation, the compiler would enforce that implicitly21:31
whitequarkwith more complex system like modes, there probably isn't a way to verify this in compiler21:31
hozerBut what if this memory range is hardware registers (like say Infiniband verbs stuff)21:31
whitequark(I suspect it can be proven that general case is equivalent to halting problem)21:31
wpwrakwhitequark: (target semantics on the host) just a question of writing the appropriate wrapper :)21:31
DocScrutinizer05whitequark: yup, for stack stuff is pretty simple21:32
whitequarkwpwrak: what if your target has 16-bit ints? things get pretty painful, and emulators often aren't what you want21:32
DocScrutinizer05in assembler however you tend to think of stack as a location to push registers and PC21:32
whitequarkhozer: (python) sorry, only Ruby. they're very similar, you won't have problems learning one if you know another one.21:32
wpwrakwhitequark: easy: don't use "int". use "int16_t" instead.21:32
whitequarkwpwrak: aaand what if your target has non-IEEE floating point semantics? :D21:33
whitequarklike ARM NEON21:33
hozerwhitequark: 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 it21:34
DocScrutinizer05\o/ NEON21:34
wpwrakgod created the integer. all else is heresy :)21:34
whitequarkhozer: 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.21:34
DocScrutinizer05in another channel some guys investigating NEON vs genuine ARM since a few days. Results are not that encouraging21:35
hozercouldn't use use the same pythong to llvm approach? Can swig make python<->ruby interfaces?21:35
whitequarkhozer: hm, there are existing ruby<>python bridge in fact. yes, you could use that.21:36
whitequark*there is21:36
whitequarkthis is how github highlights syntax on the website. yeah, one EXTRA FAT interpreter uses another EXTRA FAT interpreter :D21:36
hozergit highlights syntax using python running in ruby?21:37
whitequarkgithub. yes.21:37
whitequarkit seems that pygments is much better than any existing Ruby alternative.21:37
hozerhilarous. So the question is how many bytes of object code does this fatness compile to after you run your magic ;)21:37
whitequarkhozer: I don't compile whatever runs on the host21:37
DocScrutinizer05[2012-12-30 18:35:23] <kerio> freemangordon: what's this new libpng?21:38
DocScrutinizer05[2012-12-30 18:35:25] <kerio> NEONized one?21:38
DocScrutinizer05[2012-12-30 18:35:43] <freemangordon> luf: why don't you test it, pngtest binary is here  http://merlin1991.at/~freemangordon/libpng/21:38
DocScrutinizer05[2012-12-30 18:35:46] <freemangordon> kerio: yes21:38
whitequarkhozer: 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 anything21:38
whitequarkwpwrak: 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)21:39
hozerwell, I want to develop stuff for the embedded platform in python+ruby21:39
hozerwhat I really want is something that outputs YASEP code ;)21:39
whitequarkwpwrak: 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 :)21:40
whitequarkhozer: port LLVM to codegen for it21:40
hozerhopefully LLVM codegen is a lot easier than GCC codegen21:41
whitequarkYASEP 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 wirespread21:41
whitequarkhozer: 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 slow21:42
hozerwell, so far yasep is the cleanest open-source processor design I've run across.21:42
hozerI want a synthesizable embedded cpu core, first for fpgas and eventually for homebrew ASIC21:43
whitequark(homebrew ASIC) things got really cheap right now. I don't see why someone sufficiently motivated couldn't reproduce 4004 in their garage21:44
hozerleon-sparc might work, but it's a bit heavyweight21:45
whitequarkit shouldn't be that hard to replicate top-notch 1960's tech in 2012.21:45
hozerthere's no way I'm ever going to produce a leon-sparc in my garage, at least for 5-10 years21:45
whitequarkleon-sparc absolutely21:46
whitequarkbut 8051? why not?21:46
hozerI'd prefer a cleanroom open-source design21:46
whitequarkwell, by saying "8051" I mean the order of complexity, not a particular ISA or design21:46
whitequarkalso, why not openrisc32?21:47
hozerfind me a git or mercurial repo of openrisc32, and I'll start trying to build an fpga bitstream later today :P21:47
hozersvn + opencores.org21:48
hozeropencores.org's obnoxious registration and clunky interface drove me away.21:48
whitequarkhozer: svn co http://opencores.org/ocsvn/openrisc/openrisc/trunk21:49
hozerwhitequark: I take that back. I could not find that link when I went looking for it21:52
whitequarkhozer: first link in google :)21:52
hozerCan someone please confirm that http://www.latticesemi.com/dynamic/view_document.cfm?document_id=38780 is actually a DFSG-compliant bsd-style license?21:52
hozerwhitequark: have you ever registered with opencores.org21:53
whitequarkhozer: probably no21:54
whitequarkI don't see an entry in keepassx21:54
hozerwell, 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 access21:55
whitequarkoh. no idea about that21:55
whitequarkhozer: there are some interesting clauses in that license21:55
whitequarknamely, export restrictions21:55
whitequarkalso you need to clearly identify the parts you've changed, but I think that lies within DFSG. IANAL, through.21:56
hozerI guess that explains why milkymist doesn't incldue it21:56
hozerI guess I'd rather spend time thinking about LLVM yasep codegen than think about export nonsense.k21:58
whitequarkhozer: it's also LM821:58
whitequarkyou probably wanted LM32. I'm not sure through.21:58
whitequark(this is actually first time I ever see LM8...)21:59
hozeroh yeah, and the or12k repo includes the whole damn kernel21:59
whitequarkalso complete toolchain21:59
whitequarkand it's in this SVN abomination :/21:59
hozerlm32 appears to be at http://www.latticesemi.com/dynamic/index.cfm?fuseaction=view_documents&document_type=175&sloc=01-01-08-11-48&source=sidebar22:01
hozerif I have to screw around with toolchains, I'd rather screw around with fpgatools ;)22:01
whitequarkit is also GPL, which doesn't have that export nonsense22:01
hozeror12k is gpl?22:02
whitequarkhozer: LM32 is22:02
whitequarkOR is LGPL22:02
hozerso where do I dowload the actually LM32 core then, from that link above?22:02
Action: hozer gives up on checking out YATC (yet another toolchain)22:03
whitequarkhozer: http://www.latticesemi.com/products/designsoftware/micodevelopmenttools/index.cfm22:03
whitequarksooo http://www.latticesemi.com/dynamic/index.cfm?fuseaction=view_documents&document_type=65&sloc=01-01-07-20&source=sidebar22:04
whitequarkhozer: YATC?22:06
hozerLM8 looks a lot easier to deal with22:07
whitequarkdepends on your task.22:08
whitequarkI won't probably ever use a 8-bit micro for a new real-world project.22:08
whitequarkwpwrak: btw, we've talked about this before22:10
whitequarkI rechecked, and all STM32 families are cheaper than equivalent ATmegas22:11
whitequarkoften substantially (2x)22:11
whitequarkof course, you must not mind TQFP/QFN and 3V3. but that's all.22:12
hozerminsoc requires an opencores.org account .. http://www.minsoc.com/1_0:configuration22:14
whitequarkoh I see22:16
hozeronce I gave up trying to make sure I could check everything into my own git/mercurial and just ran the setup script it seems kinda nice :P22:20
hozerits downloading/building gcc/gdb for or32 now22:21
hozerSo how does the stm32 get to be so cheap? What will it take for an or32 or openrisc-minsoc to match the stm32 prices?22:22
wpwrakwhitequark: STM32 and atmega are in different performance classes. and yes, the high-end avr are crazily expensive.22:35
kristianpaulhozer: had you build from scratch a compile for the LM8?22:59
kristianpauli just dint figured out where lattice have that source code.. perhas in the same micosytem rpm but not checked in depth22:59
--- Mon Dec 31 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!