#qi-hardware IRC log for Saturday, 2013-02-16

wpwraklarsc: ah, working on ieee 802.15.4 ?02:50
larscwpwrak: no08:43
larscjust getting rid of stupid code ;)08:43
larscthere are like 10 drivers left which use the legacy spi suspend/resume code, and that one was an easy target08:44
wpwrakah, removing paths that mislead :)09:58
larscthe code in the core looks like: return drv->suspend ? drv->suspend() : 0;10:09
larscthat driver implemented a suspend callback that looked like int suspend() { return 0; }10:10
larscso even if that had not been a legacy code path it probably would have been the right thing to remove those no-op suspend callbacks10:10
wpwrakwell, it may have been a reminder. but of course, if it's obsolete, then even that wouldn't make so much sense anymore10:12
larscI 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?)10:39
wpwraki think everything now goes straight into net-next10:41
wpwrakand activity in that project has been very bursty, at least a while ago. may still be the same.10:42
wpwrakback 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.10:44
wpwrakperhaps 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-term10:45
larscI 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 either11:02
wpwrakthat 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.11:04
wpwrakof 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) ...11:06
wpwrakbut 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 foresight11:09
larscok, 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 implemented11:59
wolfspraul[fpgatools] I finished the first round of distributed memory support (the one in the luts)12:10
wolfspraulnext step: block memory12:10
wolfspraulblock memory has a lot of details, so I think this will keep me busy for a month or two...12:10
wolfspraulbut who knows, maybe it's faster12:11
wolfspraulI'm doing a little (de)tour to more chip features before going back to the blinking led12:11
larscnice :)12:40
larscis there already support for automatically assigning the memory?12:41
wolfspraulno, far from that12:43
wolfspraulyou mean how to create/program designs that would make use of the distributed memory cells?12:44
wolfspraulthat requires that I write more support function and glue logic first12:44
wolfspraulsupport functions12:44
wolfspraulso that will come when I go back to the sample projects like blinking_led12:45
wolfspraulalthough the blinking_led will not need memory, so it must be some more advanced (not yet conceived) example12:45
wolfspraulso 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 memory12:46
wolfspraulthat would lead to a more complete api to program a design12:46
biotwolfspraul: hi12:47
biotwolfspraul: can I ask, how did you manage to get the internal detail of that xc6slx9 FPGA?12:47
wolfspraulsure you can ask12:52
wolfspraulI think it's called "work" :-)12:52
wolfspraulyou just sit down, start, and little by little the enlightenment will shine upon you12:53
biotyou reverse engineered it then12:53
biotthat's what I wondered :)12:53
wolfspraulI only do forward engineering12:53
wolfspraulmy brain works in forward motion12:53
wolfsprauldo you do reverse engineering?12:53
biotyes, of protocols12:54
biotI'm one of the people working on the sigrok project12:54
wolfsprauloh, nice!12:54
wolfspraulmaybe we can program an fpga one day to make some nice instrumentation?12:54
wolfspraulI'd love to12:54
wolfspraulthat would be a good example too, although it would require solid work on the analog side too12:54
wolfspraulI mean on the pcb, electrically, etc.12:54
wolfspraulthe digital part would be the easy part12:55
biotyeah, what you're doing is a step towards a totally open design that nobody's done before12:55
biothence my interest12:55
wolfspraulnah, let's stay real12:55
biotso the xc6slx9 is a small FPGA, as these things go12:55
wolfspraulwith 'design' you want tools that take you from concept to hardware description or modeling to simulation and finally into a chip12:56
biotif 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?12:56
biot(I don't know anything about FPGA internal)12:56
wolfspraulno, it's not harder12:56
wolfspraulactually since I started, there was nothing I found 'hard'. it's just a lot of bits (!) and pieces, literally :-)12:57
wolfspraulbut I will continue with the xc6slx9 exclusively, for the time being12:57
wolfspraulI am interesting in switching to an xc7a100 or smaller, but I have no rush with that12:57
wolfspraulif I switch from xc6slx9 to xc7a100, that's more or less a complete rewrite and at least 6 months work12:58
wolfspraulbut... it would make the codebase 10 times better too12:58
biotsounds like you'll need to do that anyway12:58
wolfspraulfor example I worked exclusively with the qfp144 package for a few months, until I wanted to try a ftg256 package12:58
biotat some point12:58
wolfspraulso that took me about 2 weeks or so because there were a lot of places in the codes with hard-coded stuff about the package12:59
wolfspraulgoing from the first package to the second is hard12:59
wolfspraulnow I have more infrastructure in place, so supporting the next one like csg324 'should' be easier12:59
biothuh, the package makes a difference to the internals?12:59
wolfspraulbiot: 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 fpgatools13:00
biotI thought it would be just the same basic thing with different bonding wires etc13:00
wolfspraulyes but if you look at the details, you will see that package-specific stuff had spreaded here and there (in the sources)13:00
wolfspraulwhich can easily happen if you only ever work with 1 package, and you don't know (yet) what is "package-specific"13:00
wolfspraulthe joy of doing something new13:01
wolfspraulin hindsight vision is 20/20, of course13:01
biotah right13:01
biotyeah I've come across that problem :)13:01
wolfspraulby now fpgatools is about 30k lines of code13:01
wolfsprauland I have already rewritten significant parts multiple times13:01
wolfspraulthat process will continue, that's why I'm rather picky about supporting new packages or dies/chips13:01
wolfspraulI will strictly only support what I need myself :-)13:02
wolfspraulhow is sigrok doing?13:02
biotpretty good, lots of hardware supported these days13:02
biotwe keep getting distracted though, gnuradio stuff these days13:03
wolfspraulwe used or tried to use some fx2-based stuff13:03
wolfspraulbut analog was not developing much at all13:03
wolfsprauland as you said there is too much going on, and too little focus in general13:03
wolfspraul(including on my side, admittedly)13:03
wolfspraulso gnuradio now, cool :-)13:03
biotanalog on the FX2 boards hasn't developed at all no13:04
wolfspraulthere was some activity, then it stalled13:04
biotthough we support a couple of scopes and many analog devices like multimeters13:04
wolfspraullooks very fragmented now, you say "lots of hw supported" but what does that mean?13:04
wolfspraullots of alpha-quality stuff, dropped experiments, and so on?13:04
biotoh no, lots of totally working drivers13:05
biotthere are only two or so that are not in a working state13:05
wolfspraulyes sure, I know13:05
biotthat table is up to date13:05
wolfspraulare you using sigrok hw? which one?13:05
wpwraklarsc: (this one is even worse) which one ?13:05
wolfspraulI mean hw with sigrok running on13:05
larscwpwrak: some other driver13:06
wolfspraulif someone is interested in programming an fpga with fpgatools, just ping me here (for sigrok I mean)13:06
biotwolfspraul: I rarely use sigrok really, and when I do it's to help figure out some device for a new sigrok driver :)13:07
biotwolfspraul: 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?13:09
wolfspraulyes, one could reactivate the fpga backend in iverilog, for example13:11
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)13:12
wolfspraulI doubt I will do that though. It's too much work and doesn't interest me that much right now.13:13
biotyeah, it seems premature at this point13:13
wolfspraulI would estimate this to be at least "several months" of full-time work before it starts to work13:13
wolfsprauland it would drive lots of use-cases into fpgatools and require extensive work/features/fixes in there as well - EXTENSIVE13:13
wolfspraulanother option is an llvm-backend (high-level synthesis), and I may play with that a bit13:14
wolfspraulseems more interesting13:14
wolfspraulthere could be other ways too I'm not aware of, so any ideas or pointers are always welcome13:18
wolfsprauledif converter etc.13:18
wolfspraulbut all a lot of work, I will only pick small things I'm interested in13:18
wolfspraulthat's all I can do, really13:18
wolfsprauland that will in no way at all replace or compete with the big toolchains13:19
wolfspraulthat'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.13:19
wolfspraulone nice side effect of my work is that I learn how to appreciate the existing proprietary toolchains13:20
wolfspraulwhich I think are great tools :-)13:20
biotit seems like a lot, but then so does writing a kernel, C compiler, unix tools etc13:20
biotand we have all of that as free software13:21
wolfspraulI may do a bit of work on things like ieee1532 one day - that is a standard container format for bitstreams13:24
wolfspraulsmall things like that are nice13:24
wolfspraulit takes some of the mystery out of the process13:24
biotI wish I could help out13:25
biotbut I know very little about FPGAs13:25
wolfspraulthe way you can help is that if you read something interesting about tools/ways to program fpgas, ping me here and post it13:25
wpwraklarsc: 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.13:59
wpwraklinux wpan land is overall an unpretty sight of abandonment ...14:00
larscyea, my boss wrote the adf7242 driver, he sometimes talks about that we should probably clean it up and get it mainline at somepoint14:01
wpwrakheh :)14:01
wpwrakso 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"14:02
larscI don't know, but iirc the adf7242 is already a few years old and there hasn't been much new14:04
wpwrakyeah, 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.14:07
larscyea, either ARM cores or I think we even have some with a custom MCU14:07
larscbut the later is kind of suboptimal if you ask me, since you have to also create compiler, toolchain, etc.14:08
wpwrakfoolish indeed14:10
wpwrakatmel also have one with an avr core. a horrible hybrid. going by the overall structure, it may actually have two chips inside.14:11
wpwrakbut yes, arm is the future14:11
larscafter the age of WINTEL now the age LARM?14:13
wpwrakyeah ;-) 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.)14:18
larscyea, lets hope we can keep up the rate for a few more years14:24
larscand lets hope that our software doesn't get slower faster than the cpus get faster14:27
wolfspraulwhich chips make ad the most money?14:32
wpwrakyeah, let's ward ourselves against the curse of wintel :)14:32
wolfspraul(that's unfair to ask larsc, so maybe I should try to answer it myself pouring over ad results... :-))14:32
larscwolfspraul: I wouldn't know14:32
larscI'm a codemonkey14:33
wolfspraulyeah but I'm just asking that myself14:33
wolfsprauleven you knew, and the better you knew, then you would be well advised to not post that in a public forum, logged even...14:33
wolfspraulI 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 with14:34
wolfsprauland each one will be different then14:34
wolfspraulthe newer semiconductor processes thend to get more expensive14:35
wolfsprauland you can invest more theoretical performance in running the Linux kernel (for example), or lower-power14:35
wolfspraulno idea what will sell better, or with higher margin14:35
wolfspraulit probably depends on lots of factors14:36
wpwrakfor 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.14:39
wpwrakbut 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 while14:40
wpwrakuntil 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)14:42
wpwrakwell, that's what i see in my crystal ball :)14:43
wpwraki'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)14:46
larscpackage on package14:49
larscI've actually seen a few POP ARM SoCs14:49
larscthe brcm on the rpi for example does this14:50
wpwrakthat one should probably be considered one of the larger SoCs already. also, i wonder if the POP configuration is easy to source.14:51
wpwrakbut for example freescale have a few reasonably small ones that look like perfect candidates for POP.14:52
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)14:54
rohi 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.17:21
rohabout 802.15.4... i think that one died the 'one interface too many-death17:22
rohwifi and bt were there already and are quite cheap/integrated now17:23
wpwrakroh: 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 MCU17:37
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.17:40
rohwpwrak: 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.17:41
wpwrakyeah, if that's an option, that's (of course) what i'd do, too :)17:44
whitequarkwpwrak: it seems to me that 802.15.4 somewhat lives on, but only as zigbee, in multitude of incompatible proprietary variants as usual19:04
wpwrakthings 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 inertia19:31
rohi dont see any installed zigbee base. never even met somebody really using it irl19:36
rohi know much more people using rfm12 stuff. so 802.15.4 seems quite dead to me.19:37
wpwrakrfm12 is DIY :)19:41
rohsure. thats how few people use 802.15.4. i say.. < than 1/10th as rfm12 hobbyists19:45
--- Sun Feb 17 201300:00

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