<wpwrak>
some distros may have it packaged already, but better build from sources so that you get the latest version
<wpwrak>
finally, project eda-tools (qi-hw again) may be useful. e.g., when you're in ben-wpan, do "make dsv"
<wpwrak>
then put eda-tools/dsv/dsv into your PATH
<wpwrak>
now you can invoke the at86rf231 data sheet with  dsv txrx  (while you're under ben-wpan)
<[g2]>
I haven't gotten that far yet.  I've just built the latest kicad from source and I'm running that.
<[g2]>
I now see how the components are added in via the "Component library files"
<[g2]>
I'm warming up to eschema, but it'll take a little time
<[g2]>
I'm going to try and have an ATmega328 TQFN layout done for Monday and then the AT86RF231 daughterboard for following Monday
<wolfspraul>
good morning everybody
<wolfspraul>
:-)
<[g2]>
wolfspraul, morning :)
<wpwrak>
[g2]: the libs are listed in the *.pro file. i usually just add them there. less hassle than the gui :)
<[g2]>
wpwrak, nod.
<wpwrak>
[g2]: in general, it's probably best if you try to imitate the structure of the ben-wpan project. that way, you'll find many useful items that are already in place. including makefiles ;-)
<[g2]>
wpwrak, I'll have to work my way up to that.
<wpwrak>
sure. it wasn't built in a day either :)
<[g2]>
right, I'm jumping in after like 4 years
<kristianpaul>
wolfspraul: buenos dias :)
<wolfspraul>
wpwrak: just reading backlog. you definitely 100% don't have to worry about shipping prototypes with leaded solder and running into any rohs issue.
<wolfspraul>
that takes the entire rohs concept and implementation completely out of proportion
<wpwrak>
wolfspraul: heh ;-) i have a somewhat pessimistic bias with customs from hell right next to me
<wolfspraul>
sure, but I wanted to throw in my experience
<wolfspraul>
so we can focus on real issues not perceived ones
<wolfspraul>
first of all I am 99.999% sure that no customs in the world will have lead testing strips and do random checks on anything
<wolfspraul>
that's because rohs is far more than just 'lead', and it's becoming more all the time (which is good)
<wolfspraul>
rohs is an evolving standard, and big success
<wolfspraul>
the way it's enforced is mostly via trade or industry groups
<wolfspraul>
they are 'monitoring' the market
<wolfspraul>
sometimes they act passively, i.e. companies can ask them for advice regarding their products
<wolfspraul>
but they can also start to become active, going after repeat 'offenders'
<wolfspraul>
most likely that would be some big Asian manufacturer/importer who just thinks he can make a little extra margin by importing large quantities of non-rohs compliant stuff into the EU (for example)
<wpwrak>
yeah, wouldn't have to worry about repeat offending :)
<wolfspraul>
afaik rohs still doesn't apply in the US
<wolfspraul>
south korea, japan, and now even china are following with similar ideas/legislation though
<wolfspraul>
so let's say we have such a large Asian manufacturer/vendor, and they import large quantities. Maybe a competitor notices, and alerts the industry/trade group watching this. They would first try to work with the manufacturer/importer - if that doesn't go anywhere they would start to involve customs.
<wolfspraul>
the focus of everybody is to _improve_ the quality of products and make them rohs compliant, not to confiscate and discard stuff at customs
<wolfspraul>
in all this, a 1-man operation in Buenos Aires, with a home lab, soldering together a few prototypes, it all really completely will never show up on the radar
<wolfspraul>
it's not what rohs was meant to address, and it's not how it works and why it became successful
<wolfspraul>
having said that, of course it's a nice gesture from you that you want to help the world by spreading a few grams of lead less into the environment :-)
<wolfspraul>
there are still some Chinese manufacturers who are learning what that stuff really is. if they finally get it, that will save tons of lead every month. that's the focus...
<wolfspraul>
if China would start to enforce rohs or similar legislation in their domestic market, that would be a huge win
<wolfspraul>
of course the US could work a little harder too :-)
<wpwrak>
well, who said that customs behave based on the intent of the rules they're supposed to enforce ? :)
<wpwrak>
at least around here, that's often not the case. instead, the rules give them an opportunity to stop things. and then let you make it worth their effort to get them released again.
<wolfspraul>
in my experience, customs will not want to have anything to do with rohs
<wolfspraul>
it's too complicated
<wolfspraul>
please keep the big picture in mind. rohs is largely a eu thing.
<wolfspraul>
south korea, japan have adopted similar ideas
<wpwrak>
here, they told me that even something declared as "PCB" could be an issue. because "PCB" also means a prohibited chemical.
<wolfspraul>
some others are 'debating' or trying a little here and there, like California has some rules that apply to light bulbs now (according to Wikipedia)
<wolfspraul>
ah definitely
<wolfspraul>
that's another story
<wolfspraul>
you have to be careful with labling
<wolfspraul>
:-)
<wpwrak>
yeah ;)
<wolfspraul>
because they will lookup acronyms in their books...
<wpwrak>
and on comes the flashing red light ...
<wolfspraul>
yes but how does that relate to you using leaded or lead-free solder when making your 3 prototypes?
<wolfspraul>
I tried to put rohs fear in perspective.
<wolfspraul>
nothing to fear about rohs. rohs is a good thing, and will evolve further.
<wolfspraul>
doesn't apply to home-made anything
<wolfspraul>
when you go into volume production, and make a retail product, and want to sell in the EU or some other countries, then yes, rohs is one thing on a longer list to take care of (like CE, FCC, WEEE, etc)
<wolfspraul>
that's all about rohs
<wpwrak>
actually, i think it may now apply to pretty much anything. they recently dropped a number of exceptions.
<wpwrak>
whether they enforce it for tiny quantities is a different story, though
<wolfspraul>
possible, but trust me, hand-built prototypes that you are sending from Buenos Aires to Berlin are _not_ meant
<wpwrak>
anyway, US, 2 x EU, and TW worked without any trouble, plus 3 x AR outbound. that's reassuring.
<wolfspraul>
I won't even try to sift through thousands of pages to find the exception that would apply to that case, if anybody would even want to take a closer look.
<wolfspraul>
good :-)
<wolfspraul>
I'm not surprised.
<wolfspraul>
with labling I totally agree with you - be careful
<wolfspraul>
that's how customs indeed does work
<wolfspraul>
they won't turn on your product, or even do chemical tests. but they will go through all documentation, and look around the product for labels or any text that gives them reason for action.
<wpwrak>
yes, exactly
<wpwrak>
so the question in this case is whether they're looking for something that says anything about RoHS compliance or not
<wpwrak>
apparently, they don't
<wolfspraul>
no
<wolfspraul>
rohs is too difficult/technical
<wpwrak>
it could just be the logo :)
<wolfspraul>
it is implemented by industry groups, working together with government agencies. and starting with high volume.
<wolfspraul>
and it only applies to the EU and some other smaller countries
<wolfspraul>
not the US, not China, not many other regions and countries
<wpwrak>
well, china have their own variant
<wolfspraul>
it's amazing what a pull force the EU market can create, I think by now 50% or more of Chinese manufacturers know what rohs is and a lot of them, especially the better ones, have changed all their production to be rohs compliant
<wolfspraul>
not yet, just being discussed I think
<wolfspraul>
I think after you made the initial investment, into your people to know what rohs is, the different process etc., the production costs must be very very close to non-rohs production costs.
<wpwrak>
(eu pull) yeah. it's too good a market to just give up. plus, running lead-free and leaded in parallel would be crazily expensive
<wolfspraul>
what I see a lot with Chinese vendors is that if it's a small vendor, who has never done rohs runs, or barely heard about it, then they will quote you some large extra charge for a rohs run
<wolfspraul>
basically you are financing his switch :-)
<wolfspraul>
but then there are many vendors now, especially larger ones but also increasingly smaller ones, they will just tell you "all our runs are rohs compliant now"
<wolfspraul>
even whatever they ship to US, China, South-East asia, etc.
<wolfspraul>
that's quite amazing I think
<wolfspraul>
actual rohs countries maybe only 500 million people or so
<ds3>
rohs sucks
<wolfspraul>
but it's cheaper for the manufacturer to switch everything to rohs compliance and never hear about this anymore :-)
<wpwrak>
people with money. good euros, not fragile dollars. well, maybe with the euro weakening, they wouldn't switch now ;-)
<wolfspraul>
ds3: why? tell us more :-)
<wolfspraul>
I think it's great. I want to understand more about the chemical composition of the stuff I'm making anyway. talking about rohs is a way to engage vendors in that kind of conversation...
<wolfspraul>
wpwrak: I read the backlog, but still cannot really make sense out of what [g2] is building
<wolfspraul>
he is building some 802.15.4 product?
<wpwrak>
he wants to combine a small arduino with the at86rf231, yes
<wolfspraul>
so he's not building an at86rf231 arduino shield, but an integrated board out of arduino+at86rf231?
<wpwrak>
actually, he now seems to want to make two boards. so the final arrangement may be something shield-ish.
<kristianpaul>
i just wondered with the first pic, now fixed :-)
<wpwrak>
the scope indicates quite a bit of jitter. you may want to move the trigger ~125 us to the left, then look at the curve again
<wpwrak>
(first pic) probe not grounded ? ;-)
<kristianpaul>
no no !!
<kristianpaul>
probe is grounded
<wpwrak>
then you have a lot of overshoot :)
<wpwrak>
well, could be just bad ground. (loop too long)
<kristianpaul>
from gnd in J21, whatever is grounds to..
<kristianpaul>
s/is/it
<wpwrak>
actually, the jitter is probably okay. that may be just trigger inaccuracy. all the rising edges are narrow, so they're in sync
<wpwrak>
is J21 close to the signal ?
<kristianpaul>
dont understand
<kristianpaul>
J21 is the I/O expasion connector in mm1
<kristianpaul>
this debug I/O i added and the other gps related pins go there
<wpwrak>
and where is the clock signal you're measuring ? also on J21 ?
<wpwrak>
ah, okay
<wpwrak>
can the scope display th trigger frequency ?
<wpwrak>
i think the frequency you're showing is a waveform measurement, correct ?
<kristianpaul>
(waveform) yes
<kristianpaul>
(trigger frequency) dunno
<wpwrak>
okay, then it's normal for it to be relatively inaccurate. if you can get the trigger frequency, there may be a much more precise indication.
<kristianpaul>
for now i'll activa the OUT ping for overrrun signal
<kristianpaul>
activaTE
<qi-bot>
[commit] Werner Almesberger: tools/Makefile (BEN_DIRS): added "dirtpan", so it's now included by default (master) http://qi-hw.com/p/ben-wpan/417d12c
<qi-bot>
[commit] Werner Almesberger: tools/dirtpan/: added statistics collection, SIGUSR1 to dump, SIGUSR2 to reset (master) http://qi-hw.com/p/ben-wpan/0194dc1
<kristianpaul>
i know i missed something but not sure wich part..
<wpwrak>
30*2048/2 = ~30 MB
<rjeffries>
fyi all US manufacturers are observinf ROHS standard. not sure if it is law, butsince any product may ship to EU i is effectiely required.
<wpwrak>
30*1024 = ~30 MB
<wpwrak>
30*4*256 = ~30 MB
<wpwrak>
so all buffers should be the same
<kristianpaul>
hehe
<wpwrak>
or did you mean MSa ? :)
<wpwrak>
(and Mb would be Megabits. careful, if you buy RAM chips, they always give the size in Mb, not in MB ;-)
<kristianpaul>
ahh
<wpwrak>
hm .. 4.475 us per bit. 4 us are for the air interface. that's 475 ns for transfer to/from the transceiver, meaning about 237 us per side ... about 4.2 Mbps. well, that may even be correct. having some evilly long inter-byte delays.
<wpwrak>
(inter-byte delays) required by the at86rf230. the ben could go a little faster
<rjeffries>
wpwrak the over the air data rate is expected to be...maybe 250 Kbps correct? goodput woud be less
<kristianpaul>
wpwrak: i like this of debugging with scope, is more fun than the classical led ;)
<kristianpaul>
i wich as usefull verbose as a printf :-)
<kristianpaul>
second i'll upload overflow OUT in scope
<wpwrak>
kristianpaul: so .. the overflow happens at the correct time ? if yes, how do you know ?
<wpwrak>
kristianpaul: something i see in the waveforms is that the falling edges are somewhat slow, about 10-15 ns, while the rising edges are much faster. you may want to check your pin configuration. for debugging signals, that's okay, but in case you're driving any "fast" digital logic, that could be a problem.
<wpwrak>
kristianpaul: maybe check with lekernel. he'll know instantly whether these signals look unusual or not.
<wpwrak>
kristianpaul: also, you may want to disable the bandwidth limiter and use peak detect. that way, you can see digital glitches.
<wpwrak>
kristianpaul: last but not least, you may want to build a resistive probe some day. that'll help you get rid of the reflections :) (the waveforms look very clean. did you use averaging ?)
<wpwrak>
dvdk: whee ! another epic struggle comes to an end :)
<wpwrak>
dvdk: the emacs build process must be quite something. actually, does perl still dump/undump itself too ? i vaguely recall that it did, some eons ago
<vladkorotnev>
Hello Everyone
<dvdk>
wpwrak: yeah, the emacs build process now involves a few more million LOC building qemu
<dvdk>
wpwrak: i guess the term "nightly build" cannot be really applied if builds take > 1d nowadays :)
<wpwrak>
dvdk: nice :) the should add some code-generation feature that makes each step grow the others a little. that way, you could reach a point where an emacs build outruns moore's law :)
<wpwrak>
s/the/they.
<wpwrak>
dvdk: how well do incremental builds work ?
<dvdk>
wpwrak: that.s easy, just add more layers of qemu emulation
<dvdk>
wpwrak: i'm using 'ccache' here (openwrt has an option to enable that).  this way build is a little incremental, but still 100% reproducable
<dvdk>
other than that, in theory openwrt tracks dependencies and only rebuilds packages that change.  but bad idea to rely on that on a build server
<dvdk>
a few (dependency) bugs only crop up if you build from scratch
<dvdk>
btw about the nightly builds: that's the firmware compilation time, not qemu+emacs (which only contribute about 10 min. i'd guess)
<wpwrak>
hmm, openwrt builds its own toolchain. how do you handle gcc distribution in a ccache environment ? doesn't ccache resent mixing gcc versions ?
<wpwrak>
err ... sorry, confused
<wpwrak>
no gcc distribution. just mixing gcc versions
<wpwrak>
distribution would be distcc ;-)
<wpwrak>
dvdk: (nightly) you mean the whole openwrt rootfs+optional packages set ? "firmware" is a bit confusing ...
<qi-bot>
[commit] Werner Almesberger: atusb/fw/: remove unused items when building the USB driver for the boot loader (master) http://qi-hw.com/p/ben-wpan/8f94984
<dvdk>
wpwrak (about ccache): i think ccache checks command line + date and file size of gcc executable to test whether a file from the cache matches
<dvdk>
in cross-build it's run as a prefix 'ccache mipsel-openwrt-linux-gcc' so it knows you're using a different compiler
<wpwrak>
dvdk: okay, that should be pretty robust. hmm, there was something that still broke it. i once ran into it ... when i reported it, they basically threw up their hands and concluded that they couldn't test for *that* too. hmm, what was it ... it was pretty obscure
<wpwrak>
grr. don't remember some ELF header that got subtly tweaked, i think
<qi-bot>
[commit] Werner Almesberger: qi_lb60: changed board setup from atben with spi_gpio to spi_atben (ben-wpan) http://qi-hw.com/p/qi-kernel/36baa2b
<qi-bot>
[commit] Werner Almesberger: Revert "at86rf230: initialize unused buffers in struct spi_transfer to NULL" (ben-wpan) http://qi-hw.com/p/qi-kernel/01c171f
<qi-bot>
[commit] Werner Almesberger: at86rf230: check PHR of inbound packets and make sure frame fits into skb (ben-wpan) http://qi-hw.com/p/qi-kernel/fe7850b
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved atben_reset and at86rf230_platform_data from board to driver (ben-wpan) http://qi-hw.com/p/qi-kernel/9a7d79a
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved qi_lb60_atben platform device from board to spi_atben (ben-wpan) http://qi-hw.com/p/qi-kernel/00fded8
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved spi_board_info of atben from board to spi_atben (ben-wpan) http://qi-hw.com/p/qi-kernel/b9def22
<qi-bot>
[commit] Werner Almesberger: spi_atben: announce atben_reset and don't modify global variables (ben-wpan) http://qi-hw.com/p/qi-kernel/add45cd
<qi-bot>
[commit] Werner Almesberger: spi_atben: we set prv->board_info.platform_data later, don't mis-initialize (ben-wpan) http://qi-hw.com/p/qi-kernel/8a07eed
<qi-bot>
[commit] Werner Almesberger: spi_atben: added detection of FORCE_TX_ON commands for interrupt synchronization (ben-wpan) http://qi-hw.com/p/qi-kernel/46b0b6b
<wpwrak>
hmm, those merges are indeed a little chatty ...
<wpwrak>
tuxbrain_HxxHhzo: heya ! how's lyf ?
<lkcl>
hi folks, i've been recommended to ask for some advice in here
<lkcl>
i'm looking for people who might be interested to build a free software licensed hardware project, based around the 1ghz Ingenic jz4770.
<lkcl>
more specifically, a GNU FSF "Hardware-endorsed" laptop and/or micro-server
<wpwrak>
ah, never heard of the 4770. is this a big brother to the 4760 ?
<Ayla>
yes
<lkcl>
yeehhhs, it is :)  1ghz, 65nm.  finally it's a CPU where there's no proprietary crap, that is quick enough to take quotes seriously quotes
<lkcl>
the 4760 wasn't quiite there (110nm or thereabouts, 700mhz)
<Ayla>
I know there's a GPU on that one, there are open-source drivers for it?
<lkcl>
the GPU is just yet another X-Burst engine, running at 1ghz.
<wpwrak>
(seriously) heh :)
<wolfspraul>
lkcl: when will the 4770 ship?
<lkcl>
wolfspraul: don't know.
<wolfspraul>
minor issue
<wolfspraul>
:-)
<wolfspraul>
"fsf endorsed laptop" has been a recipe for failure for a number of years now
<lkcl>
i've been pinging ingenic.
<wolfspraul>
hope you are not adding another one to the pile...
<lkcl>
wolfspraul: that's because the CPUs which can qualify are like... um... shit? :)
<wpwrak>
lkcl: you may want to reconsider the "FSF-endorsed" requirement. it's not bad as a "nice to have" objective, but you may find that some of the FSF's ideas wrt hardware are at odds with what makes sense on a practical level to optimize your freedoms.
<mth>
lkcl: afaik the VPU is just another X-Burst core, but there is a separate GPU rectangle in block diagram next to CPU and VPU
<wolfspraul>
lkcl: initially you said you are "looking for people interested in building..."
<lkcl>
there's a couple of other CPUs that qualify (and are good enough) such as TI's DM37xx and AM series *as long* as you get the versions without the 3D graphics
<Ayla>
yes, there's a CPU, a VPU (second Xburst) and a GPU
<wolfspraul>
what is your part?
<wolfspraul>
are you able to throw a few hundred thousand USD on the table for work to start?
<lkcl>
wolfspraul: get things going.
<wolfspraul>
or you just want to see others doing it while you comment on it from the side?
<wpwrak>
lkcl: unless, of course, someone is sponsoring your project specifically with "FSF endorsement" as a requirement ...
<wolfspraul>
or you want to order one for 199 USD?
<lkcl>
wolfspraul: hell no!  but i did get rms interested, enough for him to consider authorising at least _some_ funds.
<wolfspraul>
lkcl: there are definitely people here who "want to build" something like that :-)
<wolfspraul>
that sounds like it will go nowhere
<wolfspraul>
:-)
<lkcl>
and in some other public discussions, i got an offer of $1k out-of-the-blue towards it.
<wpwrak>
although we'd rather try something a little smaller. ben-sized would be ideal.
<Ayla>
lkcl: nice! 99k more and you can build it!
<wpwrak>
there's a war coming in the non-intel netbook category. there's little point in getting oneself onto that battlefield.
<lkcl>
wpwrak: i've been planning something like this for a while.  how about a 50x70mm CPU card?  i know of a design-house in china that will, if he is provided with a CPU card, make a 14in laptop around it for $2,000.
<wpwrak>
Ayla: multply with 150% and you have about the R&D cost
<wolfspraul>
I would agree with Werner. We have to be careful to not waste money in areas where others are doing it already.
<wpwrak>
Ayla: no money for initial production, though
<wolfspraul>
I'd rather innovate on copyleft hardware and in areas where others won't.
<wolfspraul>
lkcl: oh my :-)
<Ayla>
wpwrak: what R&D? You just need to buy a couple of components, and solder them together! voila! :)
<wolfspraul>
please stay in this community, it will be good for you...
<lkcl>
Ayla: i'm very much aware of the differences between USA / EU hardware development costs and those of China / Asia :)Â Â it's a factor of 10
<wolfspraul>
right now honestly I wouldn't know where to start...
<wolfspraul>
lkcl: all wrong
<wolfspraul>
:-)
<wolfspraul>
I'm typing to you from Beijing, China btw
<wolfspraul>
gotta get dinner soon
<Ayla>
wolfspraul: lies!
<lkcl>
so i have received quotes from China of $10k for doing a CPU board, and $100k from EU / Germany / USA developers
<wolfspraul>
sure
<lkcl>
exact same board.
<wpwrak>
lkcl: cheap, good, ever sees the light of day. pick two ;-)
<wolfspraul>
they mean very different things though
<Ayla>
wolfspraul: how did you pass the big firewall? :D
<lkcl>
wolfspraul: ni how maaaa :)
<wolfspraul>
openvpn
<wpwrak>
lkcl: and that's true in china as much as elsewhere
<wolfspraul>
lkcl: you have to be patient. your goals are similar to the goals of many people here.
<lkcl>
wolfspraul: wo jiaouu lukehh
<lkcl>
ahh goood.
<wolfspraul>
I'm not going to talk you into a Ben NanoNote now, just keep lurking here...
<lkcl>
i've been working quietly for over a year, banging my head against the wall on this project from a "mass-produced" angle
<wolfspraul>
lkcl: say hello to rms next time you see him :-)
<lkcl>
he he
<wolfspraul>
keep talking. what was your initial thinking, and how did it evolve over the last year?
<lkcl>
ok.
<wolfspraul>
what did you learn along the way?
<lkcl>
long story :)
<lkcl>
we learned that if you contact enough chinese OEMs, _eventually_ you'll break the myth that chinese OEMs will never part with money to a foreigner.
<lkcl>
:)
<lkcl>
we've come up with a de-facto industry standard group of interfaces
<lkcl>
and are looking to get this so-called "embedded" CPUs into a 50x70mm user-removable hot-swappable card with ethernet, 24-pin RGB/TTL, SATA, I2C, USB-2 and about 10 GPIO pins on the main internal edge connector
<lkcl>
those are pretty generic "lowest common denominator" interfaces (and there's a Genesys Logic IC which does USB-to-SATA if any one SoC happens not to have SATA, it's about $1)
<wpwrak>
USB 2.0 full-speed ?
<wolfspraul>
"never part with money to a foreigner"? don't understand
<Ayla>
USB-to-SATA? Isn't that like a very bad idea?
<lkcl>
on the _other_ end of the 50x70mm card, it's possible to get HDMI, Micro-SD, Audio jacks, USB-OTG and anything else that the CPU does or doesn't have
<wolfspraul>
in hardware, try to take the time to visit the vendors you plan to work with
<wpwrak>
Ayla: it think the fun begins with the edge connector ...
<lkcl>
Ayla: well, it's better than a kick in the teeth, if the CPU just doesn't have SATA at all.
<Ayla>
but then there's no point to use SATA
<lkcl>
wolfspraul: been there.  my associates went to HK and PRC last month.
<Ayla>
as you'll be highly limited by the speed of the USB bus
<wolfspraul>
lkcl: to give you an idea. If I wanted to know more about the 4770, small details like when it will be available, what the story is behind it, etc. then I would have a meeting with the Ingenic CEO tomorrow. That helps, quite a bit :-)
<lkcl>
Ayla: like i said, it's better than a kick in the teeth.  if the CPU is so low-cost it just doesn't _have_ SATA, but the de-facto (proposed) standard says SATA has to at least be provided...
<wolfspraul>
do not make too many assumptions
<lkcl>
wolfspraul: you're _really_ in china, and would do that? :)
<wolfspraul>
I will not do that.
<Ayla>
lkcl: yes, but then there's no *point* to have SATA
<wolfspraul>
lkcl: of course I'm in China, I just said so.
<lkcl>
Ayla: if you only are picking a standard to support one and only one CPU, i'd agree with you.
<lkcl>
Ayla: but if you are picking a standard which is designed for modern CPUs, then if someone wants to try to "force" their way into that standard using a lower-cost CPU and conversion ICs (e.g. USB-to-SATA) then... let them.  it's no big deal.
<Ayla>
it's big deal; without real SATA there's no way to run a full system on your board; only from USB or SD which is super-slow
<Ayla>
that's the main reason why I did not buy the Panda board
<wolfspraul>
lkcl: the product you are making, who's the user?
<wolfspraul>
it competes with what? a notebook? ipad? iphone? arduino?
<lkcl>
Ayla: then for those systems where high-performance is an issue, you pick CPUs which have real SATA.  the... oo, S5PV310 for example (i _think_ it's got SATA on-board)
<lkcl>
wolfspraul: ahh, that's the fun bit.  it's um... almost everything (but i'm aware there's a "walk-before-run" barrier)
<wolfspraul>
people buy it because?
<lkcl>
we want to start off with the "popular" band-wagon products (tablets etc.)
<lkcl>
ok, let me run you through the "story", and it'll answer that question.
<lkcl>
you walk into a supermarket, up to the computer "appliances" shelf.
<lkcl>
on the left-hand rack there are CPU cards.  $30, $40, $70 gets you a low-speed, medium-speed and super-dooper-speed CPU.
<lkcl>
the $30 card has say... a Telechips TCC8901 with 256mb RAM, or a WM8650, or... you get the idea
<lkcl>
the sooper-dooper-speed one has a 1.5ghz OMAP4440, or a Samsung S5PV310, or NVidia's "latest" whatever Tegra - again, you get the idea
<lkcl>
on the next shelf is "Chassis".
<wpwrak>
lkcl: i'd quickly forget about modularity at such a complex level. better to make the design open so that people who want to design for a different cpu can just adapt the design.
<wolfspraul>
I don't get the idea. it sounds scary.
<lkcl>
on this shelf there's a MID / Video Player; a PVR / TV Player; a 7in tablet chassis, an 8in tablet chassis, a 10in one, a 10in laptop, a 14in laptop, a 24in "all-in-one" TV
<wpwrak>
lkcl: keep are few _simple_ interfaces for DIY and such. but don't put high-speed busses on extension boards and such. that's just cost and trouble.
<lkcl>
wolfspraul: many people don't get it.
<wolfspraul>
lkcl: I think you have 2 paths forward: one is that your thinking includes manufacturing, then I very much suggest you start to manufacture things yourself asap.
<wolfspraul>
small things, you can start with a budget of a few hundred USD and will learn _A LOT_
<wolfspraul>
or you keep your mind entirely out of manufacturing, on the software side only
<lkcl>
wpwrak: look at the list of interfaces again.  the high-speed interfaces are all serial lines with balanced pairs, and the rest are maximum 75mhz (RGB/TTL)
<wolfspraul>
then you need to look at what is really available today, and you can make guesses on what will be available tomorrow, and you can focus your thinking on hacking into those things
<wolfspraul>
I think you have to make that decision first
<wolfspraul>
dinner, bbl
<lkcl>
wolfspraul: can't do that :) been planning this for ages.  i can do the software in my sleep (was one of the original HTC linux hackers / reverse-engineers back in 2004-6)
<lkcl>
so this is the next challenge for me
<wolfspraul>
you want to learn about manufacturing?
<lkcl>
i'd rather find people who already have that expertise :)
<lkcl>
ok - i'm going to chase ingenic.  i have a message sooomewhere with the 4760 datasheet... can't bloody find it
<wolfspraul>
oh my
<wolfspraul>
that's the reason why everybody hates 'support'
<wolfspraul>
"open source will bring expensive support cases"
<wolfspraul>
and what do people like me tell people like Ingenic?
<wolfspraul>
1) just hang up the phone
<wolfspraul>
2) just delete incoming mails
<wolfspraul>
yes, a lot of nonsense will come if you open up, it's unavoidable. But you still have the power to ignore.
<wolfspraul>
seriously, that's what I'm telling them
<wolfspraul>
and it's the only way for them to protect their scarce engineering resources
<lekernel>
more or less the same with xilinx...
<lkcl>
yeahhh, i know that one... that's why we're also working from the mass-volume angle.
<lkcl>
i did say it's a long story :)
<lkcl>
wolfspraul: go eat!
<wolfspraul>
lkcl: what do you mean with "working from the mass-volume angle"?
<wpwrak>
wolfspraul: "promise volume so they don't hang up so quickly" ? :)
<lkcl>
wolfspraul: tell you later, ok? got a couple of things to do.  brief answer: i have associates with connections in UK hypermarket retail stores.
<lkcl>
hen how!  they've released schematics of the developer board, the RD4770
<wpwrak>
wolfspraul: it kinda worked for openmoko :)
<wpwrak>
lkcl: why not go for something a bit simpler ? do you know the ben nanonote ? we're looking for ways to make a successor with improved specs and a much more open design and development process.
<wpwrak>
lkcl: the nanonote is much simpler than your high-end modular PC.
<wpwrak>
lkcl: so, lower R&D cost. simpler internal interfaces. fewer chips to worry about. lower cost of production ramp-up.
<lkcl>
wpwrak: apologies, i have an advantage that i've been going over this for some considerable time.
<Ayla>
wpwrak: I wouldn't mind a nanonote tablet :)
<wpwrak>
lkcl: i would still put the R&D cost around 100-200 kUSD. about 100-300 kUSD to start mass production, depends a bit on your negotiation powers :)
<lkcl>
from many different perspectives, not just "one product, one design team, one CPU, one sales channel, one end-user customer base"
<wpwrak>
lkcl: good that we just started yesterday ;-))
<lkcl>
wpwrak: no, it's not.  ok, if you do all the casework (plastics) from scratch, yes.  but that would be crazy
<lkcl>
the casework alone would be $100k (yes i've been following the openpandora...)
<lkcl>
wpwrak: :)
<wpwrak>
lkcl: the case is indeed one of the tricky bits. but you need to control that too, or you're not really free.
<wpwrak>
lkcl: obviously, you'd keep the case radically simple. no point in trying to out-style apple.
<Jay7>
Ya Tablet is good name for russian market :)
<lkcl>
wpwrak: that's why we've been talking about "converting" and "adapting" existing OEM casework, starting with systems that already have the holes in the right places.
<Jay7>
Ya Tabletko even
<wpwrak>
lkcl: 100 k for the case sounds like they hired a commercial design house
<Jay7>
(kind of slang)
<lkcl>
achh, it's a piss-take price, i know.
<wpwrak>
lkcl: OEM cases are risky. also, they limit what you can do to the beaten path. little potential for innovation. every change will be a pain. been there (at openmoko), done that. never again ;-)
<lkcl>
wpwrak: *snort* :)
<wpwrak>
Jay7: so what does it mean ? :)
<lkcl>
oo - it looks like the jz4770 has HDMI out!
<wpwrak>
ah, lemme check google translate. more fun that way :)
<Jay7>
wpwrak: well.. something like "I'm tablet"
<lkcl>
wtf is "EPD"??
<Jay7>
Ya is tralsiteration of letter / which is equal to "I'm" :)
<wpwrak>
Jay7: google xlat proposed  90 B01;5B:>  then said  "da pills" ;-)  (not sure if "da" is just a back-transliteration or a slurred "the")
<Jay7>
wpwrak: yes, really good translation
<wpwrak>
Jay7: aah ! kewl :)
<Jay7>
da is the, yes
<Jay7>
slangish :)
<wpwrak>
lkcl: (hdmi out) that's why you want a single board. no extension connector. particularly if you don't count on owning the case anyway. (but even if you do, you make your life easier if you can freely move things around)
<lkcl>
wpwrak: The Plan is: de-facto standard based around that set of interfaces, 50x70mm CPU cards.  the reasons why are numerous and overall compelling.  basically no - no single board.
<lkcl>
there's precedent for "PCBA" design as it's called.
<wpwrak>
"PCBA" = PCB assembled board
<lkcl>
the Seatron / Chitech PC-89E.  Telechips TCC890x tablets.
<lkcl>
wpwrak: ok, ok :) the ODMs we've been talking to understand what we mean.  ok, we _think_ they understand what they mean :)
<wpwrak>
lkcl: well, good luck ! i think you'll learn a lot on that first attempt ;-)
<wpwrak>
lkcl: at least you seem to have strong backers. that's good. else, you would even have a hard time getting usable chips.
<lkcl>
wpwrak: if companies like Seatron didn't already *successfully* have 200-pin SO-DIMMs, and DirectInsight.co.uk didn't have 200-pin SO-DIMMs with a range of CPUs on them, and various other design companies didn't have modular designs which are virtually identical in concept: yes, i wouldn't even bother
<wpwrak>
lkcl: and you don't seem to care about hardware openness. that also simplifies the problem.
<lkcl>
wpwrak: what do you mean?  i _do_ care - it's a simple, simple standard, so i'm working from all angles, both the proprietary non-open hardware angle *AND* the competely-open hardware angle
<wpwrak>
lkcl: oh, modular is possible. but look at the cost. also, if you don't own the case, there's very little real flexibility in your daughterboards.
<wpwrak>
lkcl: all you can do choose which holes in the plastic to fill.
<lkcl>
ok, ok, wpwrak - i have to get on: let it sink in / mull it over a bit.
<wpwrak>
;-)
<lkcl>
this has been a thought experiment / communicating-with-OEMs exercise for well over a year :)
<wpwrak>
lkcl: how many products have you designed and had manufactured so far ?
<wpwrak>
lkcl: (including specification and sourcing, of course)
<wpwrak>
(me: openmoko very little gta01, gta02, a bit debug board, a bit hxd8, very little gta03; gta02-core design process only (that's a nice bit of work too - your design house in china won't given you open design files; then three boards at qi-hw, all the way from specification, design to fab-ready output with testing)
<wpwrak>
(wolfgang: openmoko a bit gta02, gta03. then qi-hw ben, milkymist one. ben is an OEM design. milkymist one new from scratch.)
<Ayla>
I did work on the openmoko for a school project
<Ayla>
pretty weird machine
<wpwrak>
;-))
<wpwrak>
Ayla: i hope you enjoyed the rugged case design ;-)
<wpwrak>
Ayla: and the reliability of the debug board, in case you used that
<Ayla>
the job was to get Android 2.2 running on it, and make test apps for bluetooth, wifi and GPS
<wpwrak>
Ayla: pheww. tall order. and, did it work ?
<Ayla>
it was quite easy in fact
<Ayla>
there's already a port of Android on it
<wpwrak>
Ayla: ah, then you got into it at the right time :)
<Ayla>
yep
<Ayla>
but I was amazed by the battery life ;)
<wpwrak>
Ayla: how many minutes ? did you dare to suspend ? and if you did, did it resume ? :)
<Ayla>
on suspend, it wouldn't last one night
<Ayla>
after a full charge :/
<Ayla>
my openmoko was suspending/resuming fine, I never had problems with that
<Ayla>
but my coworker's wouldn't resume
<Ayla>
I was also amazed how non-responsive it is
<Ayla>
I believe that's because of the slow CPU<->GPU bus
<Ayla>
with a simple calcul, I discovered that the phone can't deliver more than ~10fps
<wpwrak>
Ayla: (non-responsive) that must have been thanks to the graphics decelerator. i think that was a novelty. shame we didn't patent it. see also page 31 of http://people.openmoko.org/werner/ols2008.ps
<qi-bot>
[commit] Werner Almesberger: re-applied at96rf230.c part of commit 8684b7aecce3963a04d1aeb9ac4154c0c235791e (ben-wpan) http://qi-hw.com/p/qi-kernel/233a114
<lekernel>
sane semantics would be one command to read capacity, one command to read a sector (identified by number), one command to write a sector
<lekernel>
instead of that they have puked out a 600-page specification
<wpwrak>
and part of it secret, to make things more interesting :)
<lekernel>
yeah..I wonder what sucks more, SD or USB?
<lekernel>
at least SD cards don't require you send them ping packets every millisecond
<wpwrak>
(what sucks more) i've asked myself the same question. couldn't quite decide either ;-)
<wpwrak>
IEEE 802.15.4 is also a good competitor. the spec (only 323 pages) cheerfully begins all talk about MAC-layer things with some 100 pages of MIB and intra-stack communication.
<wpwrak>
and there others would say things like "500 us", you're given a lengthy formula making reference to parameters scattered all over the document. naturally, there's no "for example, for <insert most common case>, this would be 500 us"
<whitequark>
hmm
<whitequark>
what's your best method of soldering wires to lqfp pins?
<lekernel>
ask mwalle on #milkymist, he's the only one who managed to do it properly (and get his board to work) when we messed up the video chip pinout on our first M1 prototypes
<whitequark>
duh, already done
<whitequark>
my preferred one is "when it's all fucked up, step out, calm down, and then start from beginning"
<kristianpaul>
wpwrak: (averaging) no
<kristianpaul>
wpwrak: (resistive probe) interesting, is no the same design you used in atben/atusb?
<kristianpaul>
wpwrak: (peak detect) sound interesting and i read how to do it, let me review manual
<kristianpaul>
wpwrak: i think i did some mistakes adding delayed assignment in non clocked block wich the one that fire the overrrun, thats fixed now waiting synthesis to finish so i'll mesure again
<kristianpaul>
wpwrak: overrun signal freq should be just 0.5 hz off 1024 wich is the clock used by the counter, and as it is 11 bits that mean 0,5 hz per count i think
<kristianpaul>
DocScrutinizer: this a nice link you posted time ago, finally had time to check it :)
<DocScrutinizer>
me posted a link?
<DocScrutinizer>
I'm posting so many links all the time, sorry I can't reacall
<stefan_schmidt>
wpwrak: what is the .slp_tr pin for? I just have seen that it is connected to an GPIO on the atben but I don't see how it will be handled with the atusb
<stefan_schmidt>
wpwrak: and btw, I had to export the irq function to use them in a module under x86. But now I get IRQ 24.
<DocScrutinizer>
I've been bitching and nagging abut it since at least half a year - got ignored. Today the big boom and everybody's upset and OHNOES!!! OMFG
<DocScrutinizer>
stefan_schmidt: still in USB<->OTA ?
<stefan_schmidt>
DocScrutinizer: yup, getting the driver to behave like a sane spi master
<DocScrutinizer>
aja zigbee
<stefan_schmidt>
no, not zigbee
<stefan_schmidt>
ieee802154
<DocScrutinizer>
yep
<stefan_schmidt>
that what zigbee uses as the first two layers
<DocScrutinizer>
:nod: I know. Just tierd
<stefan_schmidt>
heh, ok
<stefan_schmidt>
has to explain it to people often enough :)
<DocScrutinizer>
:-)
<kristianpaul>
:o, thats new for me
<wpwrak>
stefan_schmidt: (slp_tr) that's a multifunction pin: used to put the transceiver into sleep mode (which means it will stop supplying a clock to the mcu, thereby stopping usb), and also to start a transmission. for the latter, you can also just write a command to TRX_CMD
<stefan_schmidt>
wpwrak: ok, thanks
<wpwrak>
stefan_schmidt: (export) i actually never tried to build or use this as a module :)
<stefan_schmidt>
wpwrak: I'm still fighting various crashes here. I must have some broken logic wrt platform_device and usb_device
<stefan_schmidt>
wpwrak: heh, its easier for me having it as module here :)
<wpwrak>
kristianpaul: (resistive probe) hmm, not sure what you're referring to. i use resistive probes from time to time. they get a lot less noise and artifacts than "normal" probes. (probably also because i optimize their shape a bit)
<stefan_schmidt>
and you can see that RSTN is correct in the last one but not the ones before
<stefan_schmidt>
debug is in the fill_data function called from probe
<stefan_schmidt>
wpwrak: you did build a new kernel and booted into it for every try?
<wpwrak>
yeah. for now, there's no alternative to rebooting after one try.
<wpwrak>
yup
<wpwrak>
that's my preferred approach
<wpwrak>
nice clean kernel. no risk of chasing the mess some earlier bug left behind :)
<stefan_schmidt>
I'm doing the same on embedded devices, but it sucks for your normal workstation
<wpwrak>
it's useful to have > 1 x86 machines ;-)
<stefan_schmidt>
well, I don't have it :)
<stefan_schmidt>
We have some more in the lab, of course
<stefan_schmidt>
but I will not be there for more then one week
<wpwrak>
so try to make each boot count ;-)
<wpwrak>
meanwhile, i'll see if i can track this down ...
<stefan_schmidt>
heh
<stefan_schmidt>
wpwrak: your atusb devices are completely broken right now?
<wpwrak>
well, close to that. the best one doesn't have a working reset line and the RF is severely compromised
<stefan_schmidt>
hmm, or maybe something like kvm
<wpwrak>
also sometimes loses clock, etc.
<wpwrak>
qemu ! ;-)
<wpwrak>
but i should get a nice parcel from tuxbrain tomorrow :)
<stefan_schmidt>
would need to figure out how they do usb passthrough
<stefan_schmidt>
wpwrak: ah, tomorrow already.
<stefan_schmidt>
wpwrak: that means we can hack on this thing more effectively tomorrow
<wpwrak>
maybe. i also have to get things ready for FISL. leaving tuesday morning, volcano willing
<zear>
guys, does the nanonote still have a ~3 delay after you press and hold the power button before it shows anything on the screen?
<zear>
i have some very early firmware (late 2009?) on my unit, and it behaves this way
<zear>
we have a talk over at #dingoonity about this, since the old versions of the linux port to the dingoo a320 behaved the same way
<stefan_schmidt>
wpwrak: oh, bad timing (for me :))
<zear>
though a solution for this was found later, which led to an instant boot after powering on
<stefan_schmidt>
wpwrak: It really seems that someone tries to sabotage my diploma thesis with the ieee802154 drivers :)
<zear>
*~3 sec
<wpwrak>
stefan_schmidt: naw, just reboot and you'll have a clean context ;-) you seem to be quite close to having it all work anyway
<stefan_schmidt>
does not have a nanonote, can't tell
<stefan_schmidt>
wpwrak: close is not done :)
<wpwrak>
zear: i still get some delays but i update things sparingly
<stefan_schmidt>
wpwrak: anyway, reboot time...
<zear>
wpwrak, the thing is the delays have returned for us with OpenDingux (nex linux port to the dingoo), and we've kind of.. lost the solution for the delay fix in the legacy linux port
<zear>
so we're currently browsing the old sources and changelogs hoping to rediscover the fix
<wpwrak>
ah, maybe larsc or xiangfu can help you there.
<zear>
and i thought once we find it, perhaps it could benefit for the nanonote as well :)
<wpwrak>
regressions are fun ;-)
<qi-bot>
[commit] Werner Almesberger: kernel/irq/: EXPORT_SYMBOL_GPL functions for dynamic interrupt allocation (ben-wpan) http://qi-hw.com/p/qi-kernel/5cdcaf4
<stefan_schmidt>
wpwrak: callback into the reset handler inside atusb works. Not reset itself but the callback. Now checking the your tools for the reset
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved atben_reset and at86rf230_platform_data from board to driver (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/9a7d79a
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved qi_lb60_atben platform device from board to spi_atben (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/00fded8
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved spi_board_info of atben from board to spi_atben (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/b9def22
<qi-bot>
[commit] Werner Almesberger: spi_atben: announce atben_reset and don't modify global variables (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/add45cd
<qi-bot>
[commit] Werner Almesberger: spi_atben: we set prv->board_info.platform_data later, don't mis-initialize (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/8a07eed
<qi-bot>
[commit] Stefan Schmidt: Merge remote-tracking branch 'origin/ben-wpan-atben' into ben-wpan-stefan (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/42c875a
<qi-bot>
[commit] Stefan Schmidt: Merge remote-tracking branch 'origin/ben-wpan-atben' into ben-wpan-stefan (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/3ce7e2e
<qi-bot>
[commit] Stefan Schmidt: kernel/irq: Export IRQ functions we need for the ATUSB build as module (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/562e0da
<qi-bot>
[commit] Werner Almesberger: spi_atben: added detection of FORCE_TX_ON commands for interrupt synchronization (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/46b0b6b
<qi-bot>
[commit] Werner Almesberger: re-applied at96rf230.c part of commit 8684b7aecce3963a04d1aeb9ac4154c0c235791e (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/233a114