Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
<wpwrak>
soldering station, multimeter, and power supply, all in one device. nice for crowded spaces.
<wpwrak>
of course ... power supply without current limit. somebody's been very afraid of actually making it useful :)
emeb has joined #qi-hardware
<wpwrak>
ah, lovely. from the description of a soldering station: "The whole function suffers the CPU control."
<wpwrak>
hmm. ssh: connect to host projects.qi-hardware.com port 22: Connection timed out
pcercuei has joined #qi-hardware
urandom__ has quit [Quit: Konversation terminated!]
wej has quit [Ping timeout: 260 seconds]
pi_ has joined #qi-hardware
pi_ is now known as FrankBlues
wej has joined #qi-hardware
<whitequark>
wpwrak: ohh, zd\d{3} model name
<whitequark>
I have some stuff from that chinese vendor. it's pretty good.
<whitequark>
the iron and heat gun saved me quite a lot of times.
<whitequark>
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.
<whitequark>
through it might be me and not the tool itself.
LunaVorax has quit [Ping timeout: 260 seconds]
xiangfu has joined #qi-hardware
LunaVorax has joined #qi-hardware
FrankBlues has quit [Remote host closed the connection]
pcercuei has quit [Remote host closed the connection]
LunaVorax has quit [Quit: Quitte]
<wpwrak>
whitequark: hmm, a desoldering iron ... applied to SMT circuits ? or to through-hole ?
<xiangfu>
great. the GFW blocked *.qi-hardware.com in beijing. as least I can not access them any more.
<wpwrak>
time to emigrate ?
<wpwrak>
actually, that may be premature. http://qi-hw.com/ doesn't work from argentina either
<wpwrak>
and i know that projects.qi-hardware.com is down
<xiangfu>
projects and wiki on same machine.
<xiangfu>
en.qi-hardware.com working and project.qi-hardware.com not working?
<wpwrak>
checking ...
<wpwrak>
i can't reach en.qi-hardware.com
<xiangfu>
ok. maybe the qi-hardware.com is down.
<xiangfu>
pertain.qi-hardware.com block by GFW.
<wpwrak>
the last hop i see with traceroute is valkyrie.qi-hardware.com
<wpwrak>
not sure what this machine is
brimstone has left #qi-hardware ["WeeChat 0.3.8"]
<xiangfu>
(en.qi-hardware.com) traceroute same here. stop at valkyrie.qi-hardware.com
<xiangfu>
traceroute pertain.qi-hardware.com: stop at ChinaUnicom-BACKBONE.
<wpwrak>
let's see ...
<wpwrak>
"pertain" goes all the way to hos-tr1.ex3k15.rz16.hetzner.de
<wpwrak>
ah, or static.233.58.9.5.clients.your-server.de
<wpwrak>
it even answers http: "It works!
<wpwrak>
This is the default web page for this server.
<wpwrak>
The web server software is running but no content has been added, yet."
<xiangfu>
yes. (en.qi-hardware.com) works fine here.
megharsh has quit [Quit: WeeChat 0.3.9.2]
<wpwrak>
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 ?
emeb has quit [Quit: Leaving.]
<kyak>
wpwrak: do you use PWM to control LED brightness with 8:10 card, or it is a simple on/off?
<wpwrak>
hmm, you mean "is there a PWM one could use with UBB" ?
<wpwrak>
and answer to that would be "no". all you have there is the MMC controller
<wpwrak>
you can use it to send finite bit patterns (see ubb-vga) but it's not really a PWM
<wpwrak>
depending on the accuracy you need, you can hack various alternatives
<wpwrak>
e.g., you could do a software PWM in unprivileged user space if you don't mind the occasional scheduling interruption
<kyak>
yep, we already had this discussion and just re-read the log :)
<wpwrak>
or privileged user space (with real-time priority) if you don't mind the occasional interrupt
<wpwrak>
or heavily nasty privileged user space (disabling interrupts) if you don't mind cache delays
<kyak>
how about various real-time patches to linux kernel? would they help?
<wpwrak>
or use the MMC controller to get rid of cache delays as well, but have an anomaly at block boundaries
<wpwrak>
not sure. i didn't keep track of them
<wpwrak>
ah, more options: use timers vs. bust looping
<wpwrak>
s/bust/busy/
<qi-bot>
wpwrak meant: "ah, more options: use timers vs. busy looping"
<kyak>
so, it turns to be a quite limited GPIO..
<wpwrak>
yes. if you need resource-friendly tight timing, you need to add some MCU
<kyak>
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 :)
<wpwrak>
yeah, why not :)
<kyak>
so, you use gpios to command mcu, and it in turn doesn't the real-time thing?
<kyak>
well, basically, it's ben-wpan :)
<wpwrak>
yeah
<wpwrak>
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
<wpwrak>
ubb-vga is one example of cheating
<wpwrak>
swuart is another one
<kyak>
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
<wpwrak>
you could probably even make a low- or even full-speed device or a USB host
<wpwrak>
atben has no firmware. only atusb does, but that's not for the ben
<kyak>
yep, so all applications where i don't need determinism, i can cheat
<wpwrak>
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
<kyak>
how come atben has no firmware? i see there is some mcu :)
<wpwrak>
that's the transceiver :)
<kyak>
and you control the transceiver with gpios, right?
<wpwrak>
yup. is talks SPI plus a few control signals with the ben
<kyak>
if i have a temperature sensor that talks i2c, connecting it to 8:10 card would be a piece of cake, right?
<wpwrak>
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/)
<wpwrak>
yup, i2c has no problematic timing constraints
<kyak>
heh, it seems that you've exploited this MMC controller to the full :)
<wpwrak>
the only things that suck are maximum response times. minimum response times are never a problem
<wpwrak>
oh, all those just bit-bang
<wpwrak>
the only thing where i used the MMC controller is ubb-vga
<wpwrak>
i turn interrupts off in ubb-vga and swuart
<kyak>
but when you use those 6 GPIOs, don't you use MMC controller?
<wpwrak>
new, i just use them as gpios
<kyak>
hm.. i thought these gpios are coming from mmc controller
<wpwrak>
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
<wpwrak>
each pin can be switched between several functions, e.g., gpio, interrupts, or some hardwired function block (mmc, spi, ...)
<wpwrak>
well, almost each i/o pin
<wolfspra1l>
regarding fpgatools, people need to come forward if they want something
<kyak>
how do you decide which way to go - get rt priority and leave interrupts on, or to turn off interrupts?
<wolfspra1l>
I will react then
<wolfspra1l>
at this point the sw is in such alpha state that you couldn't run much on actual hardware
<wolfspra1l>
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
<wpwrak>
yeah, that was the next item on the list
<wpwrak>
kyak: basically based on how precise things have to be and how bad it is if i miss the timing
<kyak>
wpwrak: i see.. btw, can we disable interrupts that simple on x86? :)
<wpwrak>
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.
<wpwrak>
kyak: just tell the interrupt controller to shut up ? ;)
<wpwrak>
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
<kyak>
so that you could creash it much better :)
<wpwrak>
well, in the kernel i have functions that manage resources for me, etc.
<wpwrak>
on the ben, i can get away with just saying "timer 3 is MINE now". but i wouldn't dare that on x86
<kyak>
but why not? what's so different?
<kyak>
you dont know which peripheal might be driven by that timer?
<wpwrak>
yup. on x86 i have no idea what may grab timers and such
<wpwrak>
on the ben, life is simpler and more stable
<wpwrak>
and there are also hardware abstractions on x86 the kernel takes care of for me. on the ben, there's just one hardware
<wpwrak>
so no guessing how interrupts may be routed, etc.
<kyak>
x86 is so complicated, it always makes we wonder how real time are real-time solutions based on x86
<kyak>
there is a huge market for x86 simulators, for example
<wpwrak>
x86 simulators ?
<kyak>
and they are real-time, yes
<kyak>
oh, i mean, simulators based on x86
<kyak>
if you ever heard of Opal-Rt, dSpace, xPC Target - these are all x86
<kyak>
some are running "red-hat linux with real-time patches", some are running win32-compatible RTOS
<wpwrak>
well, for reasonably lax RT, a lot of things are possible
<wpwrak>
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 :)
<wpwrak>
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)
<kyak>
but all of these providers have no problems with capturing a high-frequency PWM or doing quadrature decoding in real-time
<wpwrak>
a little fpga can go a long way when it comes to relaxing your timing
<kyak>
anyway, thanks for the chat.. time to do some new year preparations :)
<wpwrak>
ah, the booze shopping :)
erikkugel has joined #qi-hardware
<kyak>
in fact, did that one week ago. It would've been a suicide to go to a store today and tomorrow :)
<Fallenou>
morning
wolfspraul has joined #qi-hardware
wolfspra1l has quit [Ping timeout: 264 seconds]
MistahDarcy has quit [Read error: Connection reset by peer]
MistahDarcy has joined #qi-hardware
urandom__ has joined #qi-hardware
pcercuei has joined #qi-hardware
kilae has joined #qi-hardware
GNUtoo-desktop has joined #qi-hardware
pcercuei has quit [Ping timeout: 260 seconds]
wej has quit [Ping timeout: 264 seconds]
pcercuei has joined #qi-hardware
wej has joined #qi-hardware
pcercuei2 has joined #qi-hardware
pcercuei has quit [Ping timeout: 260 seconds]
jekhor has quit [Ping timeout: 255 seconds]
pcercuei2 has quit [Remote host closed the connection]
pcercuei has joined #qi-hardware
rz2k has joined #qi-hardware
GNUtoo-desktop has quit [Quit: [INFO] fsogsmd : received signal -11, exiting.]
GNUtoo has joined #qi-hardware
pcercuei has quit [Quit: Bye]
pcercuei has joined #qi-hardware
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 245 seconds]
jekhor has joined #qi-hardware
pcercuei has quit [Quit: Bye]
erikkugel has quit [Read error: Connection reset by peer]
jekhor has quit [Ping timeout: 250 seconds]
xiangfu has quit [Quit: leaving]
xiangfu has joined #qi-hardware
pi_ has joined #qi-hardware
pi_ is now known as FrankBlues
FrankBlues has quit [Client Quit]
FrankBlues has joined #qi-hardware
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 244 seconds]
pcercuei has joined #qi-hardware
wej has quit [Ping timeout: 260 seconds]
wej has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
wolfspraul has joined #qi-hardware
FrankBlues has quit [Remote host closed the connection]
kilae has quit [Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]]
pcercuei has quit [Quit: Bye]
GNUtoo has quit [Quit: Program received signal SIGSEGV, Segmentation fault.]
emeb has joined #qi-hardware
pcercuei has joined #qi-hardware
<DocScrutinizer05>
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
<DocScrutinizer05>
depending on the particular system
<DocScrutinizer05>
generally RT isn't about speed but about predictability and determinism
<pcercuei>
yep
<whitequark>
but then you discover that your maximum delay is not small enough...
<DocScrutinizer05>
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
<DocScrutinizer05>
otoh extreme speed requirements (like werber's VGA hack) might not have real hard RT requirements, if you tolerate occasional artifacts in your display
<DocScrutinizer05>
werner's*
<whitequark>
DocScrutinizer05: I'd say that technically it does have hard RT requirement, as with some delays you'd lose sync
<DocScrutinizer05>
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
<DocScrutinizer05>
basically the timing requirements for a VGA output are mostly unrelated to those specified for a RT system
<DocScrutinizer05>
e.g jitter isn't even a topic for RT
<whitequark>
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
<DocScrutinizer05>
yes, such a thing like a GC disqualifies the system for both RT and the wpwrak VGA hack
<wpwrak>
very much so ;-)
<DocScrutinizer05>
still doesn't mean RT and VGA hack have any common denominator
<wpwrak>
you have these parameters in all systems: what bounds you want to be met and the consequences of failure to meet them.
<kyak>
wpwrak: would it be a catastrophic failure for your system if it misses a single deadline?
<whitequark>
DocScrutinizer05: but don't requirements for the VGA hack (the need to output sync signals in time) qualify it to be an RT system?
<whitequark>
DocScrutinizer05: I don't understand why not
<DocScrutinizer05>
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
<wpwrak>
in the case of ubb-vga, failure isn't catastrophic. but of course, if it happens too often, people will dislike it.
<kyak>
i don't like this word, but then your system is "soft real-time"
<wpwrak>
i think many screens have something like a PLL. so if you get the timing wrong too often, the PLL will start to wander.
<wpwrak>
not so much in the context of hardware RT. e.g., you don;t really expect a UART to jitter significantly
<DocScrutinizer05>
generally you expect hw to be "real time"
<whitequark>
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
<DocScrutinizer05>
exceptions frequently need very special notice
<DocScrutinizer05>
whitequark: nope, not all of them, since RT *never* allows any glitch
<wpwrak>
every system glitches :)
<whitequark>
DocScrutinizer05: I see
<DocScrutinizer05>
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
<wpwrak>
the question is what happens then. 1) nobody even notices. 2) a few raised eyebrows. 3) a murder investigation. 4) etc.
<DocScrutinizer05>
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
<whitequark>
DocScrutinizer05: thanks for explanation
<DocScrutinizer05>
on a related topic: do you know why TV RF is specified as "stronger signal for darker pixel"?
<DocScrutinizer05>
random noise would usually add to the signal level from transmitter, thus causing dark spots instead of white spots
<DocScrutinizer05>
your eye will ignore those transient dark spots pretty much
<whitequark>
DocScrutinizer05: but why does it add to the signal level?
<wpwrak>
the eye's ability to remember photons is indeed quite remarkable
<DocScrutinizer05>
whitequark: because of two signals rather add than interfere to mutually eliminate
<DocScrutinizer05>
since for audio same physiological trick obviously doesn't work, they chosen AM for video and FM for audio signal of TV
emeb has quit [*.net *.split]
Jay7 has quit [*.net *.split]
jow_laptop has quit [*.net *.split]
whitequark has quit [*.net *.split]
whitequark has joined #qi-hardware
jow_laptop has joined #qi-hardware
Jay7 has joined #qi-hardware
emeb has joined #qi-hardware
<whitequark>
by the way, what do you guys think about automatic reference counting as a memory management strategy?
<DocScrutinizer05>
common strategy, used e.g in Qt
<DocScrutinizer05>
combined with copy-on-modify for optimization of string handling
<whitequark>
my strategy for memory management is currently as follows:
<whitequark>
1. perform region analysis and put all objects which lifetime does not exceed those of the current stack frame to the stack
<whitequark>
2. have a heap divided into fixed-size (16- or 32-byte) blocks to avoid fragmentation and have fast, constant-time allocation
<whitequark>
3. use automatic reference counting with write barriers inserted by the compiler for fast, constant-time deallocation
<whitequark>
4. use copy-on-write and ropes for strings and arrays
<DocScrutinizer05>
sounds ok'ish to me, but I wouldn't know too much to contribute anyway
<whitequark>
oh ok
<whitequark>
now, a bit about the other side of the coin
<DocScrutinizer05>
probably wpwrak has some better expertise and comments on such stuff
<whitequark>
in a nutshell, I use Ruby for three things here:
<whitequark>
1. it compiles down to native code which executes on the target device
<whitequark>
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
<whitequark>
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.
<whitequark>
(I think that C++11 with its well-defined constant folding semantics is close to what I want, but not entirely sure)
<whitequark>
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.
<kyak>
whitequark: just wondering, how do you compile Ruby down to native code? And what do you exactly mean by "native code"?
<whitequark>
would you, as embedded developers, want to use such language? if not, why?
<whitequark>
kyak: compiling ruby to native code is easy. Obj-C is basically the exact same stuff
<whitequark>
compiling ruby to _efficient_ machine code is much harder
<whitequark>
I've added static typing, and type inference for you to avoid writing unnecessary code
<whitequark>
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.
<kyak>
ok, so you go directly from Ruby to machine code? How much would you have to change if you want to support another target?
<whitequark>
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
<whitequark>
(another target) it depends. CPU architectures are handled by LLVM, so adding one means I just need to find a decent C++ dev
<whitequark>
board support packages, on the other hand, are written entirely in Ruby
<kyak>
i see.. it's very interesting
<whitequark>
obviously you need to adapt them across different families, but given how flexible Ruby is, it would be way, way simpler than in C
<whitequark>
and you could also assign this task to Ruby programmers :)
<kyak>
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?
<whitequark>
kyak: Ruby code -> (parsing, translating) -> Ruby IR -> (optimizing) -> Ruby IR -> (translating) -> LLVM IR -> (llvm) -> machine code
<kyak>
i see.. How do you verify your machine code against Ruby code? I mean, this chain is error-prone
<whitequark>
kyak: it is not inherently more error-prone than ones in GCC or LLVM Clang themselves
<whitequark>
so the answer is, test coverage.
<whitequark>
I don't do formal verification. It's not even possible for almost all real-world code.
<kyak>
yeah, compiler is also adding possible errors
<whitequark>
kyak: don't forget humans, who quite certainly add a lot of errors ;)
<whitequark>
you probably won't use v1.0 to control your car. but that applies to any different compiler as well.
<kyak>
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)
<whitequark>
I'm fine starting with TV remotes.
<whitequark>
I could use LLVM C backend to generate C code
<whitequark>
it would even make quite some sense, for this kind of auto-generated stuff
<whitequark>
eg you could clearly see objects, theirs methods, lambda functions, etc
<kyak>
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
<wpwrak>
the idea of GC in embedded code makes me feel somewhat uncomfortable
<viric>
:)
<DocScrutinizer05>
I'm still using assembler ;-P
<viric>
I don't think is that bad.
<viric>
it's just a matter to write it well enough.
<DocScrutinizer05>
generally speaking I'd try to avoid resource allocation and freeing in embedded, if any possible
<hozer>
how do you deal with real-time requirements and GC
<viric>
wpwrak: see how many smartcards run java :)
<hozer>
do those smartcards have a gc?
<viric>
I don't see why not
<whitequark>
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)
<kyak>
i think it's a great exercise anyway, and definitely we will have to go to a higher level than C
<whitequark>
hozer: they do have a GC. There are realtime GCs out there
<hozer>
python is the way to go ;)
<wpwrak>
hozer: you have two choices: 1) you leave room for worst-case GC. 2) you don't to GC ;-)
<viric>
yes.
<viric>
so easy.
<wpwrak>
s/to/do/
<qi-bot>
wpwrak meant: "hozer: you have two choices: 1) you leave room for worst-case GC. 2) you don't do GC ;-)"
<hozer>
I'll take option-2 for my engine controller please
<wpwrak>
yeah
<viric>
You can have real-time embedded systems with memory leaks, instead ;)
<wpwrak>
whitequark: maybe just make it a fatal error to do anything that would require GC
<hozer>
don't allocate memory
<wpwrak>
in smaller embedded systems, you don't have resources to throw around anyway
<whitequark>
wpwrak: yes, there would be a possibility to disable heap compile-time. I don't see why not.
<viric>
hozer: if you don't allocate memory, you won't be running a gc
<whitequark>
ARC doesn't have problems which GC's often have.
<hozer>
if there's no memory allocation, there can be no memory leaks :P
<whitequark>
it has predictable allocation and deallocation times, which are also fixed if the heap doesn't fragment.
<kyak>
forget about the GC, think about higher level languages.
<whitequark>
so I think it does suit a lot of embedded systems well.
<hozer>
what is arc
<whitequark>
hozer: automatic reference counting
<whitequark>
kyak says a very important thing. there shouldn't be a reason why your register couldn't have a high-level representation
<whitequark>
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.
<hozer>
I like ARC, and a circular reference (that breaks ARC) should be a fatal exception and the thing turns off ;)
<hozer>
because you are going to get memory corruption and some point, and the system should gracefully power off when that happens
<hozer>
s/and/at/
<qi-bot>
hozer meant: "because you are going to get memory corruption at some point, at the system should gracefully power off when that happens"
<whitequark>
hozer: a generally accepted solution is to use weak references and/or include a mark&sweep GC in addition to ARC
<whitequark>
but weak refs are quite heavy
<whitequark>
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.
<wpwrak>
considering that you'll typically in a memory-constrained context, you may want to have explicit allocation limits
<wpwrak>
e.g., given objects of type A, B, and C, something like: A | 2*B | A+C
<wpwrak>
so you either allocate an A and maybe a C too, or neither A nor C, but two B
<whitequark>
wpwrak: at which point would I enforce this limit?
<wpwrak>
you may optionally check for them
<viric>
it's about static analysis
<viric>
no?
<wpwrak>
it's about compile-time allocation
<wpwrak>
it would basically be the programmer telling the compiler what resource use is expected
<whitequark>
wpwrak: well, CFA and DFA allow me to infer this information, sometimes
<wpwrak>
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
<wpwrak>
whitequark: of course, you may find that you're rapidly approaching C semantics with all this :)
<whitequark>
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
<wpwrak>
you could add checks, but they would basically be of the type if (check_is_okay) do_it(); else panic();
<whitequark>
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
<whitequark>
Inability to build any abstrctions around those parts is what's bad
<whitequark>
the compiler is also too stupid sometimes, where it has no reason to.
<whitequark>
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.
<wpwrak>
in C (in embedded systems), you'd normally just have static allocations for such things. but of course, that could waste memory.
<whitequark>
wpwrak: (such things) which?
<wpwrak>
e.g., if you have two subsystems which each need some buffers, but they're not active at the same time
<viric>
once the memory is physically there, and only for you, it is no waste.
<whitequark>
wpwrak: ah, I understand what you mean. I'll think of possible solutions for this problem.
pcercuei has quit [Ping timeout: 260 seconds]
<whitequark>
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.
<whitequark>
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.)
<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 branches
<whitequark>
wpwrak: (two subsystems) in fact this is probably best solved by stack allocation, yeah
<whitequark>
DocScrutinizer05 uses what I've described before that
<DocScrutinizer05>
so no need to GC anything
<viric>
C is not that bad if you take malloc and free out :)
<whitequark>
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
<whitequark>
which means:
<whitequark>
1) unit tests
<wpwrak>
whitequark: some sort of stack. not necessarily the regular stack.
GitHub76 has joined #qi-hardware
<GitHub76>
j1soc/master 95d55a0 Cristian Paul Peñaranda Rojas: from RAMB16_S to RAMB16BWER, soc nows builds please check log
<whitequark>
even better, unit tests where your mock peripherals can be written in regular Ruby, simplifying that a lot
<wpwrak>
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.
<DocScrutinizer05>
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
<hozer>
can you make this work so I can write perphirals in python too ;)
<DocScrutinizer05>
yay, I wonder if anybody could parse the above
<wpwrak>
if an event appears that doesn't match the current mode, you'd ignore it, abandon the previous mode, etc.
<whitequark>
wpwrak, DocScrutinizer05: well, with the stack allocation, the compiler would enforce that implicitly
<whitequark>
with more complex system like modes, there probably isn't a way to verify this in compiler
<hozer>
But what if this memory range is hardware registers (like say Infiniband verbs stuff)
<whitequark>
(I suspect it can be proven that general case is equivalent to halting problem)
<wpwrak>
whitequark: (target semantics on the host) just a question of writing the appropriate wrapper :)
<DocScrutinizer05>
whitequark: yup, for stack stuff is pretty simple
<whitequark>
wpwrak: what if your target has 16-bit ints? things get pretty painful, and emulators often aren't what you want
<DocScrutinizer05>
in assembler however you tend to think of stack as a location to push registers and PC
<whitequark>
hozer: (python) sorry, only Ruby. they're very similar, you won't have problems learning one if you know another one.
<wpwrak>
whitequark: easy: don't use "int". use "int16_t" instead.
<whitequark>
wpwrak: aaand what if your target has non-IEEE floating point semantics? :D
<whitequark>
like ARM NEON
<hozer>
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
<DocScrutinizer05>
\o/ NEON
<wpwrak>
god created the integer. all else is heresy :)
<whitequark>
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.
<DocScrutinizer05>
in another channel some guys investigating NEON vs genuine ARM since a few days. Results are not that encouraging
zear_ has joined #qi-hardware
<hozer>
couldn't use use the same pythong to llvm approach? Can swig make python<->ruby interfaces?
zear has quit [Ping timeout: 265 seconds]
<hozer>
s/pythong/python/
<qi-bot>
hozer meant: "couldn't use use the same python to llvm approach? Can swig make python<->ruby interfaces?"
<whitequark>
hozer: hm, there are existing ruby<>python bridge in fact. yes, you could use that.
<whitequark>
*there is
<whitequark>
this is how github highlights syntax on the website. yeah, one EXTRA FAT interpreter uses another EXTRA FAT interpreter :D
<hozer>
git highlights syntax using python running in ruby?
<whitequark>
github. yes.
<whitequark>
it seems that pygments is much better than any existing Ruby alternative.
<hozer>
hilarous. So the question is how many bytes of object code does this fatness compile to after you run your magic ;)
<whitequark>
hozer: I don't compile whatever runs on the host
<DocScrutinizer05>
[2012-12-30 18:35:23] <kerio> freemangordon: what's this new libpng?
<whitequark>
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
<whitequark>
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)
<hozer>
well, I want to develop stuff for the embedded platform in python+ruby
<hozer>
what I really want is something that outputs YASEP code ;)
<whitequark>
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 :)
<whitequark>
hozer: port LLVM to codegen for it
<hozer>
hopefully LLVM codegen is a lot easier than GCC codegen
<whitequark>
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
<whitequark>
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
<hozer>
well, so far yasep is the cleanest open-source processor design I've run across.
<hozer>
I want a synthesizable embedded cpu core, first for fpgas and eventually for homebrew ASIC
<whitequark>
(homebrew ASIC) things got really cheap right now. I don't see why someone sufficiently motivated couldn't reproduce 4004 in their garage
<hozer>
leon-sparc might work, but it's a bit heavyweight
<whitequark>
it shouldn't be that hard to replicate top-notch 1960's tech in 2012.
<hozer>
there's no way I'm ever going to produce a leon-sparc in my garage, at least for 5-10 years
<whitequark>
leon-sparc absolutely
<whitequark>
but 8051? why not?
<hozer>
I'd prefer a cleanroom open-source design
<whitequark>
well, by saying "8051" I mean the order of complexity, not a particular ISA or design
<whitequark>
also, why not openrisc32?
<hozer>
find me a git or mercurial repo of openrisc32, and I'll start trying to build an fpga bitstream later today :P
<hozer>
svn + opencores.org
<hozer>
opencores.org's obnoxious registration and clunky interface drove me away.