2013-02-16 00:22 wej has quit [Ping timeout: 264 seconds]
2013-02-16 00:25 wej has joined #qi-hardware
2013-02-16 00:34 LunaVorax has quit [Ping timeout: 260 seconds]
2013-02-16 01:49 baba has quit [Ping timeout: 248 seconds]
2013-02-16 02:50 <wpwrak> larsc: ah, working on ieee 802.15.4 ?
2013-02-16 04:02 DocScrutinizer05 has quit [Disconnected by services]
2013-02-16 04:02 DocScrutinizer05 has joined #qi-hardware
2013-02-16 05:12 emeb has joined #qi-hardware
2013-02-16 05:53 wolfspraul has quit [Quit: leaving]
2013-02-16 06:17 emeb has quit [Read error: Connection reset by peer]
2013-02-16 06:29 emeb has joined #qi-hardware
2013-02-16 06:34 qwebirc33055 has joined #qi-hardware
2013-02-16 06:47 qwebirc33055 is now known as Fieldmouse
2013-02-16 07:06 Fieldmouse has left #qi-hardware [#qi-hardware]
2013-02-16 07:08 jekhor has joined #qi-hardware
2013-02-16 08:43 <larsc> wpwrak: no
2013-02-16 08:43 <larsc> just getting rid of stupid code ;)
2013-02-16 08:44 <larsc> there are like 10 drivers left which use the legacy spi suspend/resume code, and that one was an easy target
2013-02-16 09:04 LunaVorax has joined #qi-hardware
2013-02-16 09:58 <wpwrak> ah, removing paths that mislead :)
2013-02-16 10:09 <larsc> the code in the core looks like: return drv->suspend ? drv->suspend() : 0;
2013-02-16 10:10 <larsc> that driver implemented a suspend callback that looked like int suspend() { return 0; }
2013-02-16 10:10 <larsc> so even if that had not been a legacy code path it probably would have been the right thing to remove those no-op suspend callbacks
2013-02-16 10:12 <wpwrak> well, it may have been a reminder. but of course, if it's obsolete, then even that wouldn't make so much sense anymore
2013-02-16 10:14 LunaVorax has quit [Ping timeout: 260 seconds]
2013-02-16 10:22 wej has quit [Ping timeout: 248 seconds]
2013-02-16 10:28 LunaVorax has joined #qi-hardware
2013-02-16 10:29 wej has joined #qi-hardware
2013-02-16 10:39 <larsc> I kind of got the impression that ieee 802.15.4 linux support seems to be kind of dead. their git repo listed in MAINTAINERS does not exist (anymore?)
2013-02-16 10:41 <wpwrak> i think everything now goes straight into net-next
2013-02-16 10:42 <wpwrak> and activity in that project has been very bursty, at least a while ago. may still be the same.
2013-02-16 10:44 <wpwrak> back then, what was missing was a full-time project leader. the group that did all the core work at some point switched direction, and then the project was adrift for long periods of time. they came back every once in a while, though.
2013-02-16 10:45 <wpwrak> perhaps the problem is that ieee 802.15.4 is mainly an industry-driven technology, and nobody in industry seems to consider good linux support enough of a priority to pay someone/a team to work on it long-term
2013-02-16 10:59 <larsc> hm
2013-02-16 11:00 wolfspraul has joined #qi-hardware
2013-02-16 11:02 <larsc> I think we have one or two ieee 802.15.4 capable devices, but there are quite a few other linux drivers with better ROI which want to be done first, so they don't see much love either
2013-02-16 11:04 <wpwrak> that seems to be the problem everywhere. the core work was done by some branch or subcontractor of siemens. but then siemens lost interest. the industry seems to be more interested in things like contiki, which is smaller than linux.
2013-02-16 11:06 <wpwrak> of course, if ieee 802.15.4 ever really takes off, it'll be around long enough for relevant devices to become well linux-capable (at which point things like contiki would become some of those nasty little legacies) ...
2013-02-16 11:06 jekhor has quit [Ping timeout: 255 seconds]
2013-02-16 11:09 <wpwrak> but considering that (another part of) the industry is giving a very vivid illustration what exactly what would happen if you'd time-port a human from cromagnon right to the present and immediately put him in charge of managing smartphone software lifecycle management (of android, to be precise), then i guess we shouldn't be overly surprised about a certain absence of foresight
2013-02-16 11:10 <larsc> :D
2013-02-16 11:43 jurting_ has quit [Remote host closed the connection]
2013-02-16 11:59 <larsc> ok, this one is even worse, it implements empty callbacks of both the new and the legacy pm methods. this is even worse because the core won't even look at the legacy callbacks if the new ones are implemented
2013-02-16 12:10 <wolfspraul> [fpgatools] I finished the first round of distributed memory support (the one in the luts)
2013-02-16 12:10 <wolfspraul> next step: block memory
2013-02-16 12:10 <wolfspraul> block memory has a lot of details, so I think this will keep me busy for a month or two...
2013-02-16 12:11 <wolfspraul> but who knows, maybe it's faster
2013-02-16 12:11 <wolfspraul> I'm doing a little (de)tour to more chip features before going back to the blinking led
2013-02-16 12:38 hellekin has quit [Remote host closed the connection]
2013-02-16 12:40 <larsc> nice :)
2013-02-16 12:41 <larsc> is there already support for automatically assigning the memory?
2013-02-16 12:41 kilae has joined #qi-hardware
2013-02-16 12:43 jekhor has joined #qi-hardware
2013-02-16 12:43 emeb1 has joined #qi-hardware
2013-02-16 12:43 emeb has quit [Quit: Leaving.]
2013-02-16 12:43 <wolfspraul> no, far from that
2013-02-16 12:44 <wolfspraul> you mean how to create/program designs that would make use of the distributed memory cells?
2013-02-16 12:44 <wolfspraul> that requires that I write more support function and glue logic first
2013-02-16 12:44 <wolfspraul> support functions
2013-02-16 12:45 <wolfspraul> so that will come when I go back to the sample projects like blinking_led
2013-02-16 12:45 <wolfspraul> although the blinking_led will not need memory, so it must be some more advanced (not yet conceived) example
2013-02-16 12:46 <wolfspraul> so my rough plan is to just stick with the blinking_led concept, but implement it with a small j1 softcore and some j1 instructions in block memory
2013-02-16 12:46 <wolfspraul> that would lead to a more complete api to program a design
2013-02-16 12:46 <larsc> ok
2013-02-16 12:47 <biot> wolfspraul: hi
2013-02-16 12:47 <biot> wolfspraul: can I ask, how did you manage to get the internal detail of that xc6slx9 FPGA?
2013-02-16 12:52 <wolfspraul> sure you can ask
2013-02-16 12:52 <wolfspraul> I think it's called "work" :-)
2013-02-16 12:53 <wolfspraul> you just sit down, start, and little by little the enlightenment will shine upon you
2013-02-16 12:53 <biot> you reverse engineered it then
2013-02-16 12:53 <biot> that's what I wondered :)
2013-02-16 12:53 <wolfspraul> I only do forward engineering
2013-02-16 12:53 <wolfspraul> my brain works in forward motion
2013-02-16 12:53 <wolfspraul> do you do reverse engineering?
2013-02-16 12:54 <biot> yes, of protocols
2013-02-16 12:54 <biot> I'm one of the people working on the sigrok project
2013-02-16 12:54 <wolfspraul> oh, nice!
2013-02-16 12:54 <wolfspraul> maybe we can program an fpga one day to make some nice instrumentation?
2013-02-16 12:54 <wolfspraul> I'd love to
2013-02-16 12:54 <wolfspraul> that would be a good example too, although it would require solid work on the analog side too
2013-02-16 12:54 <wolfspraul> I mean on the pcb, electrically, etc.
2013-02-16 12:55 <wolfspraul> the digital part would be the easy part
2013-02-16 12:55 <biot> yeah, what you're doing is a step towards a totally open design that nobody's done before
2013-02-16 12:55 <biot> hence my interest
2013-02-16 12:55 <wolfspraul> nah, let's stay real
2013-02-16 12:55 <biot> so the xc6slx9 is a small FPGA, as these things go
2013-02-16 12:56 <wolfspraul> with 'design' you want tools that take you from concept to hardware description or modeling to simulation and finally into a chip
2013-02-16 12:56 <biot> if you were to want to suppport a larger one, would it be exponentially harder to figure out? or just the same work, but more of it?
2013-02-16 12:56 <biot> (I don't know anything about FPGA internal)
2013-02-16 12:56 <wolfspraul> no, it's not harder
2013-02-16 12:57 <wolfspraul> actually since I started, there was nothing I found 'hard'. it's just a lot of bits (!) and pieces, literally :-)
2013-02-16 12:57 <wolfspraul> but I will continue with the xc6slx9 exclusively, for the time being
2013-02-16 12:57 <wolfspraul> I am interesting in switching to an xc7a100 or smaller, but I have no rush with that
2013-02-16 12:58 <wolfspraul> if I switch from xc6slx9 to xc7a100, that's more or less a complete rewrite and at least 6 months work
2013-02-16 12:58 <wolfspraul> but... it would make the codebase 10 times better too
2013-02-16 12:58 <biot> sounds like you'll need to do that anyway
2013-02-16 12:58 <wolfspraul> for example I worked exclusively with the qfp144 package for a few months, until I wanted to try a ftg256 package
2013-02-16 12:58 <biot> at some point
2013-02-16 12:58 jekhor has quit [Ping timeout: 264 seconds]
2013-02-16 12:59 <wolfspraul> so that took me about 2 weeks or so because there were a lot of places in the codes with hard-coded stuff about the package
2013-02-16 12:59 <wolfspraul> going from the first package to the second is hard
2013-02-16 12:59 <wolfspraul> now I have more infrastructure in place, so supporting the next one like csg324 'should' be easier
2013-02-16 12:59 <biot> huh, the package makes a difference to the internals?
2013-02-16 13:00 <wolfspraul> biot: like I said, if you want to make some hardware and program an fpga in a novel way, I'm interested in the fpga/digital side - I can just make that an 'example' in fpgatools
2013-02-16 13:00 <biot> I thought it would be just the same basic thing with different bonding wires etc
2013-02-16 13:00 <wolfspraul> yes but if you look at the details, you will see that package-specific stuff had spreaded here and there (in the sources)
2013-02-16 13:00 <wolfspraul> which can easily happen if you only ever work with 1 package, and you don't know (yet) what is "package-specific"
2013-02-16 13:01 <wolfspraul> the joy of doing something new
2013-02-16 13:01 <wolfspraul> in hindsight vision is 20/20, of course
2013-02-16 13:01 <biot> ah right
2013-02-16 13:01 <biot> yeah I've come across that problem :)
2013-02-16 13:01 <wolfspraul> by now fpgatools is about 30k lines of code
2013-02-16 13:01 <wolfspraul> and I have already rewritten significant parts multiple times
2013-02-16 13:01 <wolfspraul> that process will continue, that's why I'm rather picky about supporting new packages or dies/chips
2013-02-16 13:02 <wolfspraul> I will strictly only support what I need myself :-)
2013-02-16 13:02 <wolfspraul> how is sigrok doing?
2013-02-16 13:02 <biot> pretty good, lots of hardware supported these days
2013-02-16 13:03 <biot> we keep getting distracted though, gnuradio stuff these days
2013-02-16 13:03 <wolfspraul> we used or tried to use some fx2-based stuff
2013-02-16 13:03 <wolfspraul> but analog was not developing much at all
2013-02-16 13:03 <wolfspraul> and as you said there is too much going on, and too little focus in general
2013-02-16 13:03 <wolfspraul> (including on my side, admittedly)
2013-02-16 13:03 <wolfspraul> so gnuradio now, cool :-)
2013-02-16 13:04 <biot> analog on the FX2 boards hasn't developed at all no
2013-02-16 13:04 <wolfspraul> there was some activity, then it stalled
2013-02-16 13:04 <biot> though we support a couple of scopes and many analog devices like multimeters
2013-02-16 13:04 <wolfspraul> looks very fragmented now, you say "lots of hw supported" but what does that mean?
2013-02-16 13:04 <wolfspraul> lots of alpha-quality stuff, dropped experiments, and so on?
2013-02-16 13:05 <biot> oh no, lots of totally working drivers
2013-02-16 13:05 <biot> there are only two or so that are not in a working state
2013-02-16 13:05 <biot> http://sigrok.org/wiki/Supported_hardware
2013-02-16 13:05 <wolfspraul> nice
2013-02-16 13:05 <wolfspraul> yes sure, I know
2013-02-16 13:05 <biot> that table is up to date
2013-02-16 13:05 <wolfspraul> are you using sigrok hw? which one?
2013-02-16 13:05 <wpwrak> larsc: (this one is even worse) which one ?
2013-02-16 13:05 <wolfspraul> I mean hw with sigrok running on
2013-02-16 13:06 <larsc> wpwrak: some other driver
2013-02-16 13:06 <wolfspraul> if someone is interested in programming an fpga with fpgatools, just ping me here (for sigrok I mean)
2013-02-16 13:07 <biot> wolfspraul: I rarely use sigrok really, and when I do it's to help figure out some device for a new sigrok driver :)
2013-02-16 13:09 <biot> wolfspraul: wouldn't you have to get to a stage where you could have an fpgatools backend to e.g. a VHDL compiler, before fpgatools could be used for a project?
2013-02-16 13:11 <wolfspraul> depends
2013-02-16 13:11 <wolfspraul> yes, one could reactivate the fpga backend in iverilog, for example
2013-02-16 13:12 <wolfspraul> (it is dormant and build-broken for a few years, but the sources are still dragged forward in the tree in case someone wants to breathe new life into it)
2013-02-16 13:13 <wolfspraul> I doubt I will do that though. It's too much work and doesn't interest me that much right now.
2013-02-16 13:13 <biot> yeah, it seems premature at this point
2013-02-16 13:13 <wolfspraul> I would estimate this to be at least "several months" of full-time work before it starts to work
2013-02-16 13:13 <wolfspraul> and it would drive lots of use-cases into fpgatools and require extensive work/features/fixes in there as well - EXTENSIVE
2013-02-16 13:14 <wolfspraul> another option is an llvm-backend (high-level synthesis), and I may play with that a bit
2013-02-16 13:14 <wolfspraul> seems more interesting
2013-02-16 13:18 <wolfspraul> there could be other ways too I'm not aware of, so any ideas or pointers are always welcome
2013-02-16 13:18 <wolfspraul> edif converter etc.
2013-02-16 13:18 <wolfspraul> but all a lot of work, I will only pick small things I'm interested in
2013-02-16 13:18 <wolfspraul> that's all I can do, really
2013-02-16 13:19 <biot> naturally
2013-02-16 13:19 <wolfspraul> and that will in no way at all replace or compete with the big toolchains
2013-02-16 13:19 <wolfspraul> that's already a complete misconception if you realize all the features in those toolchains, the amount of user investments made there, the number of people working on and around them, etc.
2013-02-16 13:20 <wolfspraul> one nice side effect of my work is that I learn how to appreciate the existing proprietary toolchains
2013-02-16 13:20 <wolfspraul> which I think are great tools :-)
2013-02-16 13:20 <biot> it seems like a lot, but then so does writing a kernel, C compiler, unix tools etc
2013-02-16 13:21 <biot> and we have all of that as free software
2013-02-16 13:24 <wolfspraul> I may do a bit of work on things like ieee1532 one day - that is a standard container format for bitstreams
2013-02-16 13:24 <wolfspraul> small things like that are nice
2013-02-16 13:24 <wolfspraul> it takes some of the mystery out of the process
2013-02-16 13:25 <biot> I wish I could help out
2013-02-16 13:25 <biot> but I know very little about FPGAs
2013-02-16 13:25 <wolfspraul> the way you can help is that if you read something interesting about tools/ways to program fpgas, ping me here and post it
2013-02-16 13:38 rz2k has joined #qi-hardware
2013-02-16 13:59 <wpwrak> larsc: the adf7242 driver is also one of the old SPI suspend/resume candidates, complete with return 0. alas, it never made it from the linux-zigbee tree into mainline.
2013-02-16 14:00 <wpwrak> linux wpan land is overall an unpretty sight of abandonment ...
2013-02-16 14:01 <larsc> yea, my boss wrote the adf7242 driver, he sometimes talks about that we should probably clean it up and get it mainline at somepoint
2013-02-16 14:01 <larsc> ;)
2013-02-16 14:01 <wpwrak> heh :)
2013-02-16 14:02 <wpwrak> so have analog kinda given up on ieee 802.15.4 ? i'm never quite sure what's happening with that technology. there are new chips popping up from time to time, but there's never anything that looks "big"
2013-02-16 14:04 <larsc> I don't know, but iirc the adf7242 is already a few years old and there hasn't been much new
2013-02-16 14:07 <wpwrak> yeah, seems that the new chips combine a transceiver with an MCU core. standalone transceivers like the adf7242 or also the at86rf230x are already last generation.
2013-02-16 14:07 <larsc> yea, either ARM cores or I think we even have some with a custom MCU
2013-02-16 14:08 <larsc> but the later is kind of suboptimal if you ask me, since you have to also create compiler, toolchain, etc.
2013-02-16 14:10 <wpwrak> foolish indeed
2013-02-16 14:11 <wpwrak> atmel also have one with an avr core. a horrible hybrid. going by the overall structure, it may actually have two chips inside.
2013-02-16 14:11 <wpwrak> but yes, arm is the future
2013-02-16 14:13 <larsc> after the age of WINTEL now the age LARM?
2013-02-16 14:18 <wpwrak> yeah ;-) and before we know it, even for small MCUs. even the small ones are just about two or three orders of magnitude away from being able to run linux. and they'd probably easily jump one order if there was just the need. so that's 4-5 years and even arduino-class devices will have linux (as the bottom line, not as "also available for that form factor", which has been true for years already, gumstick, etc.)
2013-02-16 14:24 <larsc> yea, lets hope we can keep up the rate for a few more years
2013-02-16 14:27 <larsc> and lets hope that our software doesn't get slower faster than the cpus get faster
2013-02-16 14:27 xiangfu has joined #qi-hardware
2013-02-16 14:32 <wolfspraul> which chips make ad the most money?
2013-02-16 14:32 <wpwrak> yeah, let's ward ourselves against the curse of wintel :)
2013-02-16 14:32 <wolfspraul> (that's unfair to ask larsc, so maybe I should try to answer it myself pouring over ad results... :-))
2013-02-16 14:32 <larsc> wolfspraul: I wouldn't know
2013-02-16 14:33 <larsc> I'm a codemonkey
2013-02-16 14:33 <wolfspraul> yeah but I'm just asking that myself
2013-02-16 14:33 <wolfspraul> even you knew, and the better you knew, then you would be well advised to not post that in a public forum, logged even...
2013-02-16 14:34 <wolfspraul> I don't know about general trends, you can find good arguments for and against all of them. so it comes down to individual companies and what they can make money with
2013-02-16 14:34 <wolfspraul> imho
2013-02-16 14:34 <wolfspraul> and each one will be different then
2013-02-16 14:35 <wolfspraul> the newer semiconductor processes thend to get more expensive
2013-02-16 14:35 <wolfspraul> and you can invest more theoretical performance in running the Linux kernel (for example), or lower-power
2013-02-16 14:35 <wolfspraul> no idea what will sell better, or with higher margin
2013-02-16 14:36 <wolfspraul> it probably depends on lots of factors
2013-02-16 14:39 <wpwrak> for mcus, an limiting factor may be voltage range. the more complex and the larger, the more sensitive they should get to supply issues. e.g., anything arm-based now usually has a built-in LDO for the core and a relatively narrow range for I/O. the pre-ARM MCUs have much wider ranges and run everything on the same voltage.
2013-02-16 14:40 <wpwrak> but then, the ARM-based MCUs have improved in that regard. the first ones were more limited. so i think we'll see sturdy but primitive MCUs in parallel with more fragile but sophisticated MCUs for a while
2013-02-16 14:42 <wpwrak> until the level of sophistication reaches a natural plateau where they have the same set of peripherals as today's MCUs but can run much more complex code. at that point, development could move towards making them more robust. not sure how low power will evolve. it may just get better all the time as a byproduct of the high-end embedded cores (smartphone/tablet grade)
2013-02-16 14:43 <wpwrak> well, that's what i see in my crystal ball :)
2013-02-16 14:46 <wpwrak> i'm a bit surprised the lower-end ARM SoCs haven't started to appear in POP configurations in the mass market yet. having to add external memories just for the OS is kind of annoying. and at least some companies don't seem to be afraid of managing a huge fleet of design variations anyway (e.g., NXP with their one thousand and one - if it's not more - LPCxxxx configurations)
2013-02-16 14:47 kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]]
2013-02-16 14:48 <larsc> POP?
2013-02-16 14:49 <larsc> package on package
2013-02-16 14:49 <larsc> I've actually seen a few POP ARM SoCs
2013-02-16 14:50 <larsc> the brcm on the rpi for example does this
2013-02-16 14:51 <wpwrak> that one should probably be considered one of the larger SoCs already. also, i wonder if the POP configuration is easy to source.
2013-02-16 14:52 <wpwrak> but for example freescale have a few reasonably small ones that look like perfect candidates for POP.
2013-02-16 14:54 <wpwrak> (also, for example the samsung socs openmoko used had POP memories. the technology has been around for a good while, especially from companies that already make all the ingredients. but they weren't readily available in the open market)
2013-02-16 16:00 LunaVorax has quit [Remote host closed the connection]
2013-02-16 16:08 xiangfu has quit [Quit: leaving]
2013-02-16 16:37 rz2k has quit [Read error: Connection reset by peer]
2013-02-16 16:40 rz2k has joined #qi-hardware
2013-02-16 16:48 LunaVorax has joined #qi-hardware
2013-02-16 16:58 urandom_ has joined #qi-hardware
2013-02-16 17:02 emeb1 has quit [Ping timeout: 256 seconds]
2013-02-16 17:07 jekhor has joined #qi-hardware
2013-02-16 17:19 jekhor has quit [Ping timeout: 252 seconds]
2013-02-16 17:20 <roh> .s
2013-02-16 17:20 <roh> irgh
2013-02-16 17:21 <roh> i dont like pop since it makes assembly harder. but if you dont need the bus to nand or nor flash or external io, but JUST the ram, then pop makes a load of sense. much easier routing then.
2013-02-16 17:22 <roh> about 802.15.4... i think that one died the 'one interface too many-death
2013-02-16 17:23 <roh> wifi and bt were there already and are quite cheap/integrated now
2013-02-16 17:37 <wpwrak> roh: if you have ram and flash on the POP, you don't need any external bus. that's a pretty neat simplification. you basically turn your soc+court into a very fancy MCU
2013-02-16 17:40 <wpwrak> (wpan) wifi has extremely different characteristics, beginning with power. i'm less sure about BT. as i understand it, BT is a thicket of layers and variants, kinda like USB, so there may be a somewhat comparable mode. may still be expensive to implement, though.
2013-02-16 17:41 <roh> wpwrak: i wouldnt build anything with lots of external flash anymore. either sd storage or use something else. but managing nand yourself properly.. naaah.. let somebody else have that pain. rather add loads of ram and run from sdcard.
2013-02-16 17:44 <wpwrak> yeah, if that's an option, that's (of course) what i'd do, too :)
2013-02-16 17:49 jekhor has joined #qi-hardware
2013-02-16 17:57 jekhor has quit [Ping timeout: 256 seconds]
2013-02-16 19:04 <whitequark> wpwrak: it seems to me that 802.15.4 somewhat lives on, but only as zigbee, in multitude of incompatible proprietary variants as usual
2013-02-16 19:31 <wpwrak> things may have moved to 6lowpan. but i don't know how much "new" activity there is, compared to the installed zigbee base that will of course live on for a while through sheer inertia
2013-02-16 19:36 <roh> i dont see any installed zigbee base. never even met somebody really using it irl
2013-02-16 19:37 <roh> i know much more people using rfm12 stuff. so 802.15.4 seems quite dead to me.
2013-02-16 19:41 <wpwrak> rfm12 is DIY :)
2013-02-16 19:45 <roh> sure. thats how few people use 802.15.4. i say.. < than 1/10th as rfm12 hobbyists
2013-02-16 20:21 kristianpaul has quit [Ping timeout: 255 seconds]
2013-02-16 20:33 kristianpaul has joined #qi-hardware
2013-02-16 20:33 kristianpaul has joined #qi-hardware
2013-02-16 21:17 <wpwrak> ;-)
2013-02-16 22:18 dandon_ has joined #qi-hardware
2013-02-16 22:19 dandon has quit [Ping timeout: 252 seconds]
2013-02-16 22:19 dandon_ is now known as dandon
2013-02-16 22:29 paroneayea has quit [Remote host closed the connection]
2013-02-16 22:34 paroneayea has joined #qi-hardware
2013-02-16 23:26 rz2k has quit []
2013-02-16 23:35 kristianpaul has quit [Ping timeout: 255 seconds]
2013-02-16 23:37 kristianpaul has joined #qi-hardware
2013-02-16 23:37 kristianpaul has joined #qi-hardware
2013-02-16 23:38 pcercuei has joined #qi-hardware
2013-02-16 23:47 kristianpaul has quit [Ping timeout: 260 seconds]
2013-02-16 23:49 kristianpaul has joined #qi-hardware
2013-02-16 23:49 kristianpaul has quit [Changing host]
2013-02-16 23:49 kristianpaul has joined #qi-hardware