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
wej has quit [Ping timeout: 264 seconds]
wej has joined #qi-hardware
LunaVorax has quit [Ping timeout: 260 seconds]
baba has quit [Ping timeout: 248 seconds]
<wpwrak>
larsc: ah, working on ieee 802.15.4 ?
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #qi-hardware
emeb has joined #qi-hardware
wolfspraul has quit [Quit: leaving]
emeb has quit [Read error: Connection reset by peer]
emeb has joined #qi-hardware
qwebirc33055 has joined #qi-hardware
qwebirc33055 is now known as Fieldmouse
Fieldmouse has left #qi-hardware [#qi-hardware]
jekhor has joined #qi-hardware
<larsc>
wpwrak: no
<larsc>
just getting rid of stupid code ;)
<larsc>
there are like 10 drivers left which use the legacy spi suspend/resume code, and that one was an easy target
LunaVorax has joined #qi-hardware
<wpwrak>
ah, removing paths that mislead :)
<larsc>
the code in the core looks like: return drv->suspend ? drv->suspend() : 0;
<larsc>
that driver implemented a suspend callback that looked like int suspend() { return 0; }
<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
<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
LunaVorax has quit [Ping timeout: 260 seconds]
wej has quit [Ping timeout: 248 seconds]
LunaVorax has joined #qi-hardware
wej has joined #qi-hardware
<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?)
<wpwrak>
i think everything now goes straight into net-next
<wpwrak>
and activity in that project has been very bursty, at least a while ago. may still be the same.
<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.
<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
<larsc>
hm
wolfspraul has joined #qi-hardware
<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
<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.
<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) ...
jekhor has quit [Ping timeout: 255 seconds]
<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
<larsc>
:D
jurting_ has quit [Remote host closed the connection]
<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
<wolfspraul>
[fpgatools] I finished the first round of distributed memory support (the one in the luts)
<wolfspraul>
next step: block memory
<wolfspraul>
block memory has a lot of details, so I think this will keep me busy for a month or two...
<wolfspraul>
but who knows, maybe it's faster
<wolfspraul>
I'm doing a little (de)tour to more chip features before going back to the blinking led
hellekin has quit [Remote host closed the connection]
<larsc>
nice :)
<larsc>
is there already support for automatically assigning the memory?
kilae has joined #qi-hardware
jekhor has joined #qi-hardware
emeb1 has joined #qi-hardware
emeb has quit [Quit: Leaving.]
<wolfspraul>
no, far from that
<wolfspraul>
you mean how to create/program designs that would make use of the distributed memory cells?
<wolfspraul>
that requires that I write more support function and glue logic first
<wolfspraul>
support functions
<wolfspraul>
so that will come when I go back to the sample projects like blinking_led
<wolfspraul>
although the blinking_led will not need memory, so it must be some more advanced (not yet conceived) example
<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
<wolfspraul>
that would lead to a more complete api to program a design
<larsc>
ok
<biot>
wolfspraul: hi
<biot>
wolfspraul: can I ask, how did you manage to get the internal detail of that xc6slx9 FPGA?
<wolfspraul>
sure you can ask
<wolfspraul>
I think it's called "work" :-)
<wolfspraul>
you just sit down, start, and little by little the enlightenment will shine upon you
<biot>
you reverse engineered it then
<biot>
that's what I wondered :)
<wolfspraul>
I only do forward engineering
<wolfspraul>
my brain works in forward motion
<wolfspraul>
do you do reverse engineering?
<biot>
yes, of protocols
<biot>
I'm one of the people working on the sigrok project
<wolfspraul>
oh, nice!
<wolfspraul>
maybe we can program an fpga one day to make some nice instrumentation?
<wolfspraul>
I'd love to
<wolfspraul>
that would be a good example too, although it would require solid work on the analog side too
<wolfspraul>
I mean on the pcb, electrically, etc.
<wolfspraul>
the digital part would be the easy part
<biot>
yeah, what you're doing is a step towards a totally open design that nobody's done before
<biot>
hence my interest
<wolfspraul>
nah, let's stay real
<biot>
so the xc6slx9 is a small FPGA, as these things go
<wolfspraul>
with 'design' you want tools that take you from concept to hardware description or modeling to simulation and finally into a chip
<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?
<biot>
(I don't know anything about FPGA internal)
<wolfspraul>
no, it's not harder
<wolfspraul>
actually since I started, there was nothing I found 'hard'. it's just a lot of bits (!) and pieces, literally :-)
<wolfspraul>
but I will continue with the xc6slx9 exclusively, for the time being
<wolfspraul>
I am interesting in switching to an xc7a100 or smaller, but I have no rush with that
<wolfspraul>
if I switch from xc6slx9 to xc7a100, that's more or less a complete rewrite and at least 6 months work
<wolfspraul>
but... it would make the codebase 10 times better too
<biot>
sounds like you'll need to do that anyway
<wolfspraul>
for example I worked exclusively with the qfp144 package for a few months, until I wanted to try a ftg256 package
<biot>
at some point
jekhor has quit [Ping timeout: 264 seconds]
<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
<wolfspraul>
going from the first package to the second is hard
<wolfspraul>
now I have more infrastructure in place, so supporting the next one like csg324 'should' be easier
<biot>
huh, the package makes a difference to the internals?
<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
<biot>
I thought it would be just the same basic thing with different bonding wires etc
<wolfspraul>
yes but if you look at the details, you will see that package-specific stuff had spreaded here and there (in the sources)
<wolfspraul>
which can easily happen if you only ever work with 1 package, and you don't know (yet) what is "package-specific"
<wolfspraul>
the joy of doing something new
<wolfspraul>
in hindsight vision is 20/20, of course
<biot>
ah right
<biot>
yeah I've come across that problem :)
<wolfspraul>
by now fpgatools is about 30k lines of code
<wolfspraul>
and I have already rewritten significant parts multiple times
<wolfspraul>
that process will continue, that's why I'm rather picky about supporting new packages or dies/chips
<wolfspraul>
I will strictly only support what I need myself :-)
<wolfspraul>
how is sigrok doing?
<biot>
pretty good, lots of hardware supported these days
<biot>
we keep getting distracted though, gnuradio stuff these days
<wolfspraul>
we used or tried to use some fx2-based stuff
<wolfspraul>
but analog was not developing much at all
<wolfspraul>
and as you said there is too much going on, and too little focus in general
<wolfspraul>
(including on my side, admittedly)
<wolfspraul>
so gnuradio now, cool :-)
<biot>
analog on the FX2 boards hasn't developed at all no
<wolfspraul>
there was some activity, then it stalled
<biot>
though we support a couple of scopes and many analog devices like multimeters
<wolfspraul>
looks very fragmented now, you say "lots of hw supported" but what does that mean?
<wolfspraul>
lots of alpha-quality stuff, dropped experiments, and so on?
<biot>
oh no, lots of totally working drivers
<biot>
there are only two or so that are not in a working state
<wpwrak>
larsc: (this one is even worse) which one ?
<wolfspraul>
I mean hw with sigrok running on
<larsc>
wpwrak: some other driver
<wolfspraul>
if someone is interested in programming an fpga with fpgatools, just ping me here (for sigrok I mean)
<biot>
wolfspraul: I rarely use sigrok really, and when I do it's to help figure out some device for a new sigrok driver :)
<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?
<wolfspraul>
depends
<wolfspraul>
yes, one could reactivate the fpga backend in iverilog, for example
<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)
<wolfspraul>
I doubt I will do that though. It's too much work and doesn't interest me that much right now.
<biot>
yeah, it seems premature at this point
<wolfspraul>
I would estimate this to be at least "several months" of full-time work before it starts to work
<wolfspraul>
and it would drive lots of use-cases into fpgatools and require extensive work/features/fixes in there as well - EXTENSIVE
<wolfspraul>
another option is an llvm-backend (high-level synthesis), and I may play with that a bit
<wolfspraul>
seems more interesting
<wolfspraul>
there could be other ways too I'm not aware of, so any ideas or pointers are always welcome
<wolfspraul>
edif converter etc.
<wolfspraul>
but all a lot of work, I will only pick small things I'm interested in
<wolfspraul>
that's all I can do, really
<biot>
naturally
<wolfspraul>
and that will in no way at all replace or compete with the big toolchains
<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.
<wolfspraul>
one nice side effect of my work is that I learn how to appreciate the existing proprietary toolchains
<wolfspraul>
which I think are great tools :-)
<biot>
it seems like a lot, but then so does writing a kernel, C compiler, unix tools etc
<biot>
and we have all of that as free software
<wolfspraul>
I may do a bit of work on things like ieee1532 one day - that is a standard container format for bitstreams
<wolfspraul>
small things like that are nice
<wolfspraul>
it takes some of the mystery out of the process
<biot>
I wish I could help out
<biot>
but I know very little about FPGAs
<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
rz2k has joined #qi-hardware
<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.
<wpwrak>
linux wpan land is overall an unpretty sight of abandonment ...
<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
<larsc>
;)
<wpwrak>
heh :)
<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"
<larsc>
I don't know, but iirc the adf7242 is already a few years old and there hasn't been much new
<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.
<larsc>
yea, either ARM cores or I think we even have some with a custom MCU
<larsc>
but the later is kind of suboptimal if you ask me, since you have to also create compiler, toolchain, etc.
<wpwrak>
foolish indeed
<wpwrak>
atmel also have one with an avr core. a horrible hybrid. going by the overall structure, it may actually have two chips inside.
<wpwrak>
but yes, arm is the future
<larsc>
after the age of WINTEL now the age LARM?
<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.)
<larsc>
yea, lets hope we can keep up the rate for a few more years
<larsc>
and lets hope that our software doesn't get slower faster than the cpus get faster
xiangfu has joined #qi-hardware
<wolfspraul>
which chips make ad the most money?
<wpwrak>
yeah, let's ward ourselves against the curse of wintel :)
<wolfspraul>
(that's unfair to ask larsc, so maybe I should try to answer it myself pouring over ad results... :-))
<larsc>
wolfspraul: I wouldn't know
<larsc>
I'm a codemonkey
<wolfspraul>
yeah but I'm just asking that myself
<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...
<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
<wolfspraul>
imho
<wolfspraul>
and each one will be different then
<wolfspraul>
the newer semiconductor processes thend to get more expensive
<wolfspraul>
and you can invest more theoretical performance in running the Linux kernel (for example), or lower-power
<wolfspraul>
no idea what will sell better, or with higher margin
<wolfspraul>
it probably depends on lots of factors
<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.
<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
<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)
<wpwrak>
well, that's what i see in my crystal ball :)
<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)
kilae has quit [Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]]
<larsc>
POP?
<larsc>
package on package
<larsc>
I've actually seen a few POP ARM SoCs
<larsc>
the brcm on the rpi for example does this
<wpwrak>
that one should probably be considered one of the larger SoCs already. also, i wonder if the POP configuration is easy to source.
<wpwrak>
but for example freescale have a few reasonably small ones that look like perfect candidates for POP.
<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)
LunaVorax has quit [Remote host closed the connection]
xiangfu has quit [Quit: leaving]
rz2k has quit [Read error: Connection reset by peer]
rz2k has joined #qi-hardware
LunaVorax has joined #qi-hardware
urandom_ has joined #qi-hardware
emeb1 has quit [Ping timeout: 256 seconds]
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 252 seconds]
<roh>
.s
<roh>
irgh
<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.
<roh>
about 802.15.4... i think that one died the 'one interface too many-death
<roh>
wifi and bt were there already and are quite cheap/integrated now
<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
<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.
<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.
<wpwrak>
yeah, if that's an option, that's (of course) what i'd do, too :)
jekhor has joined #qi-hardware
jekhor has quit [Ping timeout: 256 seconds]
<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
<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
<roh>
i dont see any installed zigbee base. never even met somebody really using it irl
<roh>
i know much more people using rfm12 stuff. so 802.15.4 seems quite dead to me.
<wpwrak>
rfm12 is DIY :)
<roh>
sure. thats how few people use 802.15.4. i say.. < than 1/10th as rfm12 hobbyists
kristianpaul has quit [Ping timeout: 255 seconds]
kristianpaul has joined #qi-hardware
kristianpaul has joined #qi-hardware
<wpwrak>
;-)
dandon_ has joined #qi-hardware
dandon has quit [Ping timeout: 252 seconds]
dandon_ is now known as dandon
paroneayea has quit [Remote host closed the connection]