<DocScrutinizer>
checks if wpwrak maybe isn't completely awake from last nap :-P
<Fusin>
;)
<rejon>
wpwrak, looks good
<rejon>
heya, can you bring some ATBEN / ATUSB
<wpwrak>
rejon: i hope so :)
<wpwrak>
depends on tuxbrain-in-absentia :)
<wpwrak>
wolfspraul: btw, did the massive press pickup have any ripple effects at sharism so far ?
<wpwrak>
rejon: they're giving you the siesta slot ! :) (for the 2nd talk)
<wolfspraul>
wpwrak: interestingly, not at all
<wolfspraul>
I've had 1 order so far
<wolfspraul>
it's probably because the links point in all directions, some of the more prominent ones to tuxbrain
<wolfspraul>
it's amazing how quick people give up - you need to hold something right in front of their mouths to sell :-)
<wolfspraul>
also I don't see many new suscribers on the discussion or the announce list, or new people here. oh well...
<wolfspraul>
I am very curious how many atben/atusb tuxbrain is selling :-)
<wolfspraul>
but he's MIA
<freakazoid0223>
wpwrak, I ordered one (nanonote)
<rejon>
freakazoid0223, that's great!
<rejon>
wolfspraul, sure, having one solid URL is best, but this is the scatter at the moment
<rejon>
better if can have one entry and buy buttons on it
<wolfspraul>
oh sure, all fine
<wolfspraul>
the coverage is excellent
<wolfspraul>
I haven't read comments carefully, but looks mostly negative to me
<wolfspraul>
I see two ways out of this - one is that with our tech, we just engadge in actual use cases that are interesting.
<wolfspraul>
the other one is that we put the focus on the software we run, rather than the hw specs
<wolfspraul>
but I think the moment anyone compares hw specs with the latest Android stuff, we are screwed, no matter what we do. So I'll stay away from going there.
<wolfspraul>
it doesn't matter whether ben-wpan is 250kbps, 2mbit/s, even 20mbit/s. THey would just say "LTE Advanced has a peak of 1gbit/sec, bla bla" :-)
<wolfspraul>
so have to just talk about apps and use cases instead
<wolfspraul>
I think ben-wpan is awesome, especially how it was created, with free tools, PCB antenna, home PCB process, etc.
<wolfspraul>
and even at 250kbs, there are plenty of fantastic apps that can be driven over it, obviously as of today we haven't maxed that out by far, because there is no single useful app yet
<wolfspraul>
the entire creation process was documented on the mailing list too, with plenty of pictures, discussions, free tools, etc.
<wolfspraul>
not to forget
<wolfspraul>
clears out a lot of FUD and builds a base for future endeavors
<wolfspraul>
rejon: we probably agree on this. The main sucess gauge for ben-wpan coverage is not how many more bens we sell, but how many people start using the atusb on their notebooks, and start developing the Linux stack, eventually into kernel.org
<rejon>
yes
<rejon>
totally
<rejon>
esp. at this point
<wolfspraul>
there's a huge workload there and that's what would unlock apps later - we need it in the Linux kernel of every notebook as badly as on the Ben...
<rejon>
yes, that is why i hoped to get more documentation down about ben wpan
<rejon>
and what needs to be done
<wolfspraul>
that's why I say I am more interested to understand how many boards tuxbrain is selling now, versus me selling more Bens
<rejon>
one big thing that has to happen on dev side is to project the goals and break down the tasks so people of varying levels of skill can get involved
<wolfspraul>
especially I hope (and try to help him) that he sells a lot of atusb, and kernel hackers start to support it from the notebook side
<rejon>
this is helpful for paid ppl
<rejon>
that's why its good lekernel is using a tracker for all the tasks
<wolfspraul>
I should write a grand 'call for action' on the announce list. Linux kernel hackers sought to join Wi-Fi replacement project.
<rejon>
yes
<rejon>
that is great
<rejon>
what is the % of kernel hackers that are employeed now
<rejon>
its really high like 85%
<wolfspraul>
oh huge, 90% or so
<wolfspraul>
definitely
<wolfspraul>
that has some bad consequences too, imo, some people are really becoming fat and lazy and just 9-5 wait-for-paycheck types
<wolfspraul>
but it's ok, it's mature...
<wolfspraul>
you can always fork, drive something crazy outside a little, then try to get it back in
<wolfspraul>
from reading between the lines what Werner and others say, the state of ZigBee for example, and probably also 802.15.4, in the kernel is really bad
<wolfspraul>
the paid guys are all on server/backend tasks, and the client/mobile crowd doesn't give a damn about kernel.org and loves implementing their stuff in little proprietary extensions, closed user-mode drivers, etc.
<wolfspraul>
that is my understanding at least
<wolfspraul>
so when I plug my atusb into my notebook, I expect: nothing
<wolfspraul>
:-)
<rejon>
i emailed some kernel devs to try to get them on board
<DocScrutinizer>
wow
<DocScrutinizer>
you found kernel devs to mail :-)
<rejon>
fat canonical employees ;)
<DocScrutinizer>
hard to find a species they are
<DocScrutinizer>
most claim to know about kernel, but even I can tell they don't have that much of a clue ;-)
<DocScrutinizer>
those who really are in business with kernel development are rarely short of tasks
<DocScrutinizer>
I faced a similar problem when it was about a proper fixed hostmode USB kernel driver
<DocScrutinizer>
again a lot of "kernel hackers" gave up on that messed up USB driver code. And I'd expect situations for wireless stack to be almost identical
<DocScrutinizer>
you probably don't need a kernel hacker short of taks to tackle, you rather need a wifi-stack hacker savvy to implement a proper kernel/mainstream compliant 802.15 stack
<DocScrutinizer>
just my uneducated 2 cents
<DocScrutinizer>
ponders about a simple MAC interface for wpan, that does nothing a simple NIC wouldn't do in hardware as well - basically filter inbound stuff for correct MAC and tag outbound stuff with own MAC (is the latter done by a NIC at all?)
<DocScrutinizer>
wpan as the wireless 10Bt thin ethernet cable
<DocScrutinizer>
can't be too hard
<DocScrutinizer>
of course you're running into "OHMY what's with ENCRYPTION" in no time :-)
<DocScrutinizer>
I never looked into 802.15 RFCs neither into the TX datasheets or atmel driver code of atusb
<DocScrutinizer>
is there any mandatory protocol defined in 802.15? Some that isn't already handled by the transceiver chip?
<DocScrutinizer>
given the usable range not being farther than I can spit, I think any over-sophisticated protocol is maybe mere overkill
<DocScrutinizer>
for a first approach at least
<DocScrutinizer>
has vivions of a 802.15->CIR adapter, to place directly next to the IR-detector of appliances
<DocScrutinizer>
visions*
<DocScrutinizer>
wpwrak: how about revamping atusb to act as a standalone wpan->CIR that only needs some 5V supply
<DocScrutinizer>
next step: a smal PCB to retrofit in place of (or parallel to) the IR_LED of remotes
<DocScrutinizer>
so you can use not only Ben but also your remote you are used to, to control that friggin TV despite there's that wooden table that doesn't let IR from remote directly to the TV a bit lower
<DocScrutinizer>
the you also can use remote to control Ben \o/
<DocScrutinizer>
then*
<DocScrutinizer>
hmm, starting at RFC4944...
<DocScrutinizer>
probably hard to get sth about IEEE 802.15.4
<DocScrutinizer>
as usual
<DocScrutinizer>
mhm, 802.15.4 defines PHY and MAC layer
<DocScrutinizer>
perfect
<DocScrutinizer>
I gather atusb is using 2.4GHz ISM band, class B ?
<DocScrutinizer>
I.E. free of all licencing, but has to live with microwave oven on same frequency
<wolfspraul>
DocScrutinizer: yes, I think so. 2.4ghz
<DocScrutinizer>
just learning in Germany the 9-10kHz(SIC!) band is a ISM band - darn, never knew my walkman had a general cert for SRD ;-P
<DocScrutinizer>
even worse, depending on the music it transmits on bands not allowable, like 18kHz
<DocScrutinizer>
wolfspraul: (wiki) >>Charakteristisch für die Knoten eines IEEE-802.15.4-Netzes sind die langen Ruhephasen, wodurch ein Knoten die meiste Zeit in einem energiesparenden Betriebszustand verweilen kann. Sobald er Daten senden oder empfangen möchte, kann er in lediglich 15 ms aufwachen, anschließend die Kommunikation abwickeln und sich wieder schlafen legen. Dadurch können batteriebetriebene Netzknoten typische Laufzeiten von sechs
<DocScrutinizer>
Monaten bis zu zwei Jahren erreichen.<<Â Â you probably want to emphasize this aspect more in your crusade for wpan :-)
<DocScrutinizer>
wonders if hise momematic home automation components are using wpan
<DocScrutinizer>
wonders if his homematic home automation components are using wpan
<DocScrutinizer>
damn
<DocScrutinizer>
the door lock for example works from battery for ~1 year or longer
<wolfspraul>
DocScrutinizer: yes I think that's one of the things learnt from Bluetooth, which takes several seconds to wakeup (maybe a little less now, but still far more than 802.15.4)
<wolfspraul>
but before hyping things too much, there's a lot of work in the stack to do first, imho
<DocScrutinizer>
wpwrak: what's atusb's best case power consumption? or maybe better what's that of atben?
<DocScrutinizer>
are we already there with months of standby operation from 2 button cells?
<DocScrutinizer>
wolfspraul: reading about 802.15.4 and what the standard defines, I see why implementations for Full Function Devices in linux still suck.
<DocScrutinizer>
esp tree topology has a bunch of duties for FFD-coordinators that are non-trivial nd way beyond what you need for a point2point data transfer
<DocScrutinizer>
(cluster tree)
<DocScrutinizer>
wow, 802.15.4 defines encryption as mandatory optional function that's handled by the mac layer aka the wpan chip
<DocScrutinizer>
CCM and AES
<DocScrutinizer>
key management is up to the higher protocol layers of course
<DocScrutinizer>
mhm, now I think I know what's 6lowpan and what's 802.15.4
<wpwrak>
DocScrutinizer: (power consumption) difficult to tell. neiher atusb nor atben are designed for low duty cycles. (= turn off everything until you know it's time to listen.) in theory, they could go quite low, but the rest of the system will be comparably power-hungry anyway.
<DocScrutinizer>
wpwrak: aiui for now atben does no 6lowpan at all? just 802.15.4?
<wpwrak>
DocScrutinizer: correct
<DocScrutinizer>
wpwrak: (power) I'm thinking about my 802.15.4->CIR adapter and the 5V PSU you maybe can omit
<DocScrutinizer>
wpwrak: there's a whole lot of nice applications for that hw that's <<6lowpan complexity
<DocScrutinizer>
thinking home automation for example
<wpwrak>
wolfspraul: (stack in bad shape) yes. something interesting happened 2-3 days ago, though: the original leader of the linux-zigbee project woke up. seems that he's been able to get the go ahead for some work. so things may improve.
<DocScrutinizer>
I could see a market for a whole range of nice DIY sensors and actors bat-powered and based on 802.15.4
<wpwrak>
DocScrutinizer: not sure 6lowpan complexity is so bad. the coordinator is a bit of a pain, but the rest is comparably simple.
<DocScrutinizer>
well, the whole coordinator thing is still mainly 802.145.4, no?
<wpwrak>
DocScrutinizer: (comparably simple) in the sense that, once it's implemented, you don't care. of course, you have to implement it once or a few times first :)
<wpwrak>
yes
<DocScrutinizer>
aiui ther coordinator should partially be integrated into the hw. Not clear about that yet
<wpwrak>
naw, coordinator can be in sw
<DocScrutinizer>
sending and sensing baecons...
<wpwrak>
there are a number of low-level functions, like acks and retransmissions that should be in hw or close to it, though
<DocScrutinizer>
sending ACKs clearly is hw domain
<wpwrak>
(beacons) a classical RT task ;-)
<DocScrutinizer>
spec says so
<wpwrak>
(beacons) besides, you don't even need them
<DocScrutinizer>
siperframes also sounds like RT, like hw
<DocScrutinizer>
super*
<DocScrutinizer>
for slotted you need them
<DocScrutinizer>
but yeah, who wants slotted
<wpwrak>
correct. but do you really need slotted ? :)
<DocScrutinizer>
:-)
<DocScrutinizer>
aiui slotted is the mezhod of choice to power down the "clients"
<DocScrutinizer>
no idea how much power the RX eats for always-on
<DocScrutinizer>
otoh saving power at one end at the expense of sending(!) beacons at the other end seems like a tradeoff not always desirable
<wpwrak>
slotted is mainly about QoS. if you really want to be low-power, you'll have a much lower duty cycle
<DocScrutinizer>
wonders how those homematic devices tackle the problem
<DocScrutinizer>
I guess they just send like mad, until some ack comes in
<DocScrutinizer>
and have a duty cycle of sth like 100/1 for standby
<wpwrak>
or much much lower
<DocScrutinizer>
could that atusb controller+transceiver couple do such a thing?
<wpwrak>
or could go low duty cycle. but then it'
<wpwrak>
s usb, which isn;t the most power-saving technology
<DocScrutinizer>
envisions an atusb with 2 or 3 button cells mod, plus 2 wires running to arbitrary sensors/actors
<DocScrutinizer>
nah, I'm thinking standalone
<wpwrak>
also, you can't shut down the transceiver without also shutting down the MCU, and usb with it
<DocScrutinizer>
using USB just for config
<wpwrak>
you'll get a baseline consumption of about 20 mW
<DocScrutinizer>
take a atusb, add some batery and e.g. a IR-LED
<DocScrutinizer>
that's definitely way too much
<DocScrutinizer>
can't the atmel suspend for seconds or hours?
<DocScrutinizer>
can't the transceiver power down at all?
<wpwrak>
if you drop usb, then you could go lower. e.g., atusb can use an internal oscillator for the mcu, which would decouple it from the transceiver. but you lose usb that way.
<wpwrak>
i haven't experimented with that, though. get one and try ;-)
<DocScrutinizer>
I'm ok with losing USB most of the time
<DocScrutinizer>
yeah, considering that. But honestly... too expensive for my wallet atm
<wpwrak>
if you think it's expensive, you may want to consider that each board is de facto subsidized with something like USD 100-200 from me ;-)
<DocScrutinizer>
darn, Ben as the logger in a network of wireless sensors, I have quite some requests for such things
<DocScrutinizer>
wpwrak: it's too expensive for my purse, not for my mind
<wpwrak>
a ben would make a very nice controller for things, indeed. kind of a super-arduino :)
<DocScrutinizer>
wpwrak: now add to that controller a complete set of (basically 2 different, or even just one) universal sensor/actor wireless dongles, operating from battery. Now if Ben had USB hostmode to configure them directly at location without additional gear...
<DocScrutinizer>
well, you probably get away with configuring the whole set at hoem with your PC
<DocScrutinizer>
then have the right firmware in the dongles to e.g read out temperature or humidity sensors... I could've sold that to an architect like 1 year ago, to monitor old houses' roofs
<DocScrutinizer>
use reed contact instead NTC and you get nice home automation detectors for open windows/doors/whatnot
<DocScrutinizer>
control lights etc with the actor dongle
<DocScrutinizer>
Ben for central controler displaying status and UI
<DocScrutinizer>
all basing on just one PCB basically
<wpwrak>
sure. domotics are one of the areas 802.15.4 seems quite suitable for.
<DocScrutinizer>
indeed
<DocScrutinizer>
we could sell Bens to people who don't even know what's a CPU ;-)
<wpwrak>
ben+atben is a bit of a hack, though. you'd want a more integrated solution.
<DocScrutinizer>
yeah, hoping for next-gen-Ben, with atben integrated, with hostmode USB...
<DocScrutinizer>
maybe we find even Logitech is using 802.15.4 for their proprietary wireless crap, and you can interface mice and kbds to NN directly ;-)
<DocScrutinizer>
glares at the sealed Logitech dongle
<wpwrak>
802.15.4 would certainly fit in that area, yes
<DocScrutinizer>
but it happens I have a disassembled MX revolution here ;-)
<DocScrutinizer>
seems TX chip is on the bottom side of PCB, need to desolder it to get there
<DocScrutinizer>
we should ask wolfgang if next nano could get a housing that can get ruggedized by user. Like adding some plastic foil on top of kbd, sealing the case with silicon, dunno what
<DocScrutinizer>
I guess there's quite a bit that can be done by merely keeping such things in mind
<DocScrutinizer>
maybe even ship matchin rubber plugs for the holes of receptacles, etc
<DocScrutinizer>
IP65 or even IP67 for sure is a nice point on the list of selling arguments
<DocScrutinizer>
even a "can reach IP55 when user does the needed mods" is better than nothing
<DocScrutinizer>
ooh, and add some mounting holes, to mount the whole thing to switchboards etc
<lekernel>
wpwrak, mh? didn't spot any personal attacks in the comments
<wpwrak>
i'm not too worried about the comments. there are basically three groups: 1) the usual nay-sayers, 2) valid criticism (although not always expressed nicely), and 3) approval.
<wpwrak>
there isn't much you can do about 1). so the masses won't camp outside of tuxbrain's shop before launch day. fine. we can live with that for a while. we always knew that this was a compromise, so 2) have a point. again, little we can do except provide a few clarifications.
<wpwrak>
of course, 3) are the most likely to actually be useful for us, e.g., by buying something or even by contributing
<wpwrak>
lekernel: (personal attacks) well, you or your product :)
<wolfspraul>
cultural graveyard
<wolfspraul>
that's what we are dealing with in many cases
<wolfspraul>
need to step out entirely, be positive, point to a good future
<wpwrak>
lekernel: july/august. hah, in the one issue with 100 circuits ? didn't remember they even has space for regular articles there :) but very good. a real article is so much better than just a brief newsticker notice.
<lekernel>
wpwrak, yeah, it used to be a big small circuit dump. but they changed this.
<wolfspraul>
rejon: thanks jon :-) for the cultural graveyard, totally accurate imo
<dvdk>
kyak: the Ctrl+N key problem in ASE seems to be caused by my allegro keyboard driver "fixes"
<dvdk>
what's a "cultural graveyard"?  sounds like a description of the US society as a whole.
<wpwrak>
wolfspraul: yeah, people see it and realize there's someone (individual or group) who can do more than they can. they basically have four choices: a) decide it's not relevant to them and ignore it. that's for the confident type. b) try to benefit from it. that's for the efficient type. c) try to get even by learning from it. that's for the competitive and smart type. d) try to get even by tearing it down. that's for the competitive and
<wpwrak>
stupid type. the more stupid you are, the more often you have a chance to feel you'r in a competition and you're losing. it all makes sense :-)
<wpwrak>
lekernel: i kinda liked the small circuit dump. weeks of gold mining ;-) back then, i didn't really understand all those things, so very little came out of reading elektor for some years. but maybe it helped to shape some neural pathways :)
<lekernel>
what's that "cultural graveyard" theory?
<wolfspraul>
we just missed the one in Barcelona (for milkymist), but if it's good i'm sure there will be another one...
<lekernel>
wolfspraul, I have, remotely
<wolfspraul>
lekernel: slashdot = cultural graveyard
<wolfspraul>
:-)
<wolfspraul>
somehow the positive vibes are gone there, I just cannot feel it anymore
<wolfspraul>
it's just endless bickering, bitterness
<lekernel>
mh, yeah, I had the same impression reading the nanonote (and to a lesser extent milkymist) comments
<wolfspraul>
if you shutdown the domain, someone would turn on the lights in that lost cinema with the movie on infinite loop, people would have to step out into daylight and rediscover their lives...
<lekernel>
still it generated a lot of traffic, reposts, and some sales
<wolfspraul>
sure, I don't know a better alternative now
<kyak>
dvdk: btw, i'm using the latest liballegro
<wolfspraul>
how does this lxer.com function? never heard about it before...
<lekernel>
there might be ycombinator
<wolfspraul>
that's a very strange thing
<lekernel>
they brought us scribd, but apart from that I have nothing against them (yet)
<wolfspraul>
when I have something on ycombinator, I get _TONS_ of traffic, but _ZERO_ really _ZERO_ sales, subscriptions, emails, anything human
<wolfspraul>
it looks like a botnet :-)
<lekernel>
maybe it is? to give the impression they are bigger than one might think? :-)
<dvdk>
kyak: yeah that's the problem :)
<dvdk>
ycombinator is like slashdot done right. Â
<dvdk>
comment quality is much, much higher
<wolfspraul>
dvdk: yes, but amazingly, the traffic/human ratio is fishy. They are doing some strange stuff I think, technically.
<wolfspraul>
maybe necessary to stand out in the junk farming nowadays, don't know.
<wolfspraul>
ah sorry "content farming"
<dvdk>
look at topics like P=NP proof, where almost every comment on /. repeated misconceptions and basic problems at comprehending P=NP, while ycombinator had a very in-depth discussion
<wolfspraul>
comprehening :-) that feeds into Jon's cultural graveyard theory...
<wolfspraul>
nah but anyway, every individual that shows up and is interested in anything is welcome, right?
<wolfspraul>
wherever they come from, even if a lot of their friends are a little bit on the ranting side :-)
<dvdk>
i don't say that slashdot is a lost case; people like us are reading it.  we may not be the majority, but still more "good" audience on /. than all other sites combined
<wolfspraul>
sure it's great to be covered there, but for the future hopefully something better emerges
<wolfspraul>
something friendlier, more thoughtful, more positive
<dvdk>
where again is the website campaigning for stopping to read slashdot?  can't find it.  was a fun read + many links to better news sites
<wolfspraul>
more fun too maybe
<lekernel>
lol, there's a campaign against slashdot ?!
<dvdk>
lekernel: should that surprise us? :)
<wpwrak>
wolfspraul: btw, here's my abstract for the upcoming presentation at FISL: http://pastebin.com/dTbAzDmn
<wpwrak>
wolfspraul: and there's my bio with an implied (short) mission statement of qi-hw at the end: http://pastebin.com/mbbudceg
<wolfspraul>
"I want to be your friend, I want to guard your dreams and visions", that's what I'm missing at /.
<wpwrak>
wolfspraul: who needs friends and visions if you can have beer and wrestling ? ;-)
<wolfspraul>
I'm just becoming sensitive to these things living in China.
<wolfspraul>
I don't need more crap flying at me when I read /.
<wpwrak>
lekernel: free sw conference in brazil, june 29-july 2
<lekernel>
and chaos camp
<lekernel>
maybe even hacknight.se, though i'd go there mostly for fun and not milkymist promotion... but who knows
<wolfspraul>
wpwrak: nice. "review the objectives and constraints", I think 'the' can be removed to "review objectives and constraints"
<wolfspraul>
but not 100% sure, need to ask a native speaker
<lekernel>
who's going to brazil?
<wpwrak>
wolfspraul: yeha, that sounds even a little better. well, i've already sent it :)
<wolfspraul>
lekernel: I have 2 questions about the tv-out cable. one is, if we do get one, should we have that ddc short/loop? is that what you prefer? the other one - will the tv-out and s-video work in parallel? can you connect 2 targets then?
<wpwrak>
lekernel: rejon, me. methril, you'll be there too, right ? (of course, technically not "going to" brazil :)
<lekernel>
wolfspraul, the s-video and cvbs can work in parallel yes
<lekernel>
but I have no s-video cable to test it atm... will get one someday
<lekernel>
ddc loop is nice to have
<wolfspraul>
huh? the one from xiangfu has both rca and s-video, no?
<lekernel>
yes, but I need another cable to go from the s-video plug on the cable to the s-video plug on my TV
<wolfspraul>
ah got it
<lekernel>
though I might just as well stuff the plugs with bits of wire
<lekernel>
anyway, all this isn't a priority. the video signal generator in milkymist and its software drivers would need a major overhaul to support cvbs and s-video
<lekernel>
I will implement this at the same time as I implement HD rendering
<lekernel>
and maybe HDMI, since I'll have my mind deep into verilog and video signals
<wpwrak>
<rjeffries> wpwrak something tht could drive atusb sales would be a standalone 802.15 gadget that has various i/o for sensors including i2c, plus gpio and a few analog pins plus the radio
<rjeffries>
Ornotermrd long time no see
<rjeffries>
wpwrak thanks!
<wpwrak>
rjeffries: yup, you could use either the MCU from atusb, or make a non-USB device
<roh>
isnt there a atrf based arduino board?
<wpwrak>
rjeffries: if you use the same MCU, you could even reuse the same firmware
<rjeffries>
roh that is worth investigating
<wpwrak>
roh: i think so, yes
<roh>
wpwrak: flash a fw which speaks serial on the usb pins of atusb ;)
<rjeffries>
wpwrak in your atusb there were io pins you did not expose correct?
<wpwrak>
roh: atusb exposes a few GPIOs already. so .... :)
<wpwrak>
rjeffries: there are the ones used for ICSP. gives you three general-purpuse GPIOs plus power
<wpwrak>
rjeffries: admittedly not a lot
<roh>
wpwrak: welll... one could also use the atmega.. sure..
<wpwrak>
roh: dfu is rather nice to have around ;-)
<rjeffries>
one really wants/needs i2c as many sensors support that
<roh>
dfu is lightyears behind arduino bootloaders when it comes to practicality ;)
<roh>
no harm intended.
<wpwrak>
roh: what's impractical about  dfu-util -D stuff  ?
<roh>
wpwrak: it doesnt work from the users already-known devel environment.
<wpwrak>
rjeffries: alas, no hw I2C on that chip. but you could write a bit-banging master, why not
<wpwrak>
roh: duuuh :)
<roh>
wpwrak: and it works via serial too. makes for less complicated and expensive hw
<wpwrak>
roh: make that Fwhatever run dfu-util instead of whatever it is now. that can't be so hard :)
<roh>
wpwrak: that only works as long as you leave the pins usb
<wpwrak>
roh: they have no other use :)
<roh>
wpwrak: well.. its 2 pins on a connector. you could speak the i2c there.
<wpwrak>
roh: i'd rather use the big fat test points right next to it. remember, 3 gpios are available from icsp
<wpwrak>
roh: and that's if you can't be bothered to make your own board variant
<wpwrak>
roh: for lots of i/os, you'd of course want to do that. bring them out on headers, etc.
<rjeffries>
levrrasging astusb even if more expensive (doh) has advantage that it exists and is Known To Work. maybe lashing it together with some off the shelf Arduino talking serial between atben and Arduino would be a kludgy but ok way to start, no hardwra eneed be developed
<wpwrak>
rjeffries: if all you want is I2C, you could just hack a bit-banging I2C driver for atusb, then attach your sensor(s) to the test points. they have 0.1 in spacing, so you could even drill holes and use a header
<wpwrak>
rjeffries: (careful with the ground plane at the bottom, though)
<wpwrak>
err no, sorry. there are traces underneath. no drilling.
<wpwrak>
but you could solder the header sideways. that's even easier.
<rjeffries>
what puzzles me is how atusb as a standalone will have protocol smarts to talk to atusb or atben over 802.15.4 + whatever higher level protocol
<wpwrak>
rjeffries: you'd have to write that too, of course :)
<rjeffries>
adding i2c somehow to Ben is looking better and better. ;)
<wpwrak>
rjeffries: there's even a kernel driver that does this. but it would be easy enough to do in user space as well. for the physical interface, use UBB
<wpwrak>
(of course, you can't have UBB and atben at the same time)
<rjeffries>
but.... 8:10 slot will be occupied by the atben rf module. I did not make my intention/goal clear: want a REMOTE, wireless connection o a platform that supports i2c sensors (and ideally also supports other sensors )
<wpwrak>
rjeffries: your choices: 1) use atusb (mainly an execise in writing software), 2) make your own atusb variant (hint: the design files are open for a reason ;-), 3) get something like http://www.logos-electro.com/zigduino/
<wpwrak>
(or some other sufficiently open ieee 802.15.4 board)
<qi-bot>
[commit] Werner Almesberger: tools/lib/: split non-SPI code from atusb.c in preparation for SPI-based driver http://qi-hw.com/p/ben-wpan/13f031b
<qi-bot>
[commit] Werner Almesberger: atusb/fw/: new mechanism for SPI commands (more general than reg/buf requests) http://qi-hw.com/p/ben-wpan/9a0184c
<wpwrak>
rjeffries: so-so. quite often, it just leads you astray. also, doesn't always things that are on sites it "knows about"
<wpwrak>
rjeffries: but yes, if desperate, that's one place to try
<wpwrak>
larsc: may i pick you brain for a moment ? there is a driver that does request_irq(...). now, in my case, i would generate this interrupt from things i get from USB. as far as i know, there's no platform-independent mechanism for assigning a "fake" interrupt number and then invoking that fake interrupt, correct ?
<wpwrak>
Jay7: google translate does funny things with that text ;-) "WARNING!  Piece of iron, which is stuck in MicroSD does not work with normal MicroSD." ;-))
<xMff>
heh
<Jay7>
hehe
<Jay7>
that is my comment
<Jay7>
because they are says this is plain microsd module
<wpwrak>
Jay7: (your comment) yeah, it has the "insider" tone ;-)
<Jay7>
ah well.. they are changed text in main article
<Jay7>
nice
<Jay7>
hehe.. same "The piece of iron"
<Jay7>
ah.. that was really my slang :))
<Jay7>
and this is right translation :))
<larsc>
wpwrak: irq_chip is what your are looking for i guess
<wpwrak>
lekernel: hmm not sure ... but create_irq looks promising
<larsc>
create_irq?
<larsc>
what do you want to do?
<larsc>
have an irq number an trigger it?
<larsc>
and
<wpwrak>
yes
<larsc>
irq_chip is what you want
<wpwrak>
the driver i want to use expects to be given an irq number
<wpwrak>
then it will request_irq it
<larsc>
take a look for example at the jz4740_adc driver in drivers/mfd
<wpwrak>
hmm ... platform_get_irq
<DocScrutinizer>
tags "real kernel hacker" label to larsc :-)
<mth>
larsc: I think I now know how to make the cpufreq driver clean and safe
<larsc>
wpwrak: platform_get_irq is for passing the irq number to the device which it passes to request_irq
<larsc>
mth: nice :)
<mth>
I implemented it for MMC, still a lot of other devices (USB, LCD etc) to be done
<DocScrutinizer>
ouch, again all based on CPU clock?
<DocScrutinizer>
nasty hw
<mth>
DocScrutinizer: it's based on the same PLL
<DocScrutinizer>
:nod:
<mth>
you can vary the CPU speed independently, but dividers are integer
<DocScrutinizer>
been a real PITA for FR S3C2442
<mth>
and most people on the Dingoo want to be able to overclock in very small increments
<DocScrutinizer>
the most annoying part is to avoid glitches on all the erial IF, when switching CPU clock
<DocScrutinizer>
as you can't witch clock and dividers atomically
<DocScrutinizer>
switch*
<mth>
I just claim the entire MMC host to ensure it's not doing I/O while the PLL is reconfigured
<DocScrutinizer>
:nod:
<DocScrutinizer>
hope you don't find inbound transmissions garbled
<larsc>
the jz4740 can luckly change dividers and the pll atomically
<DocScrutinizer>
oh, nice
<mth>
some dividers can be changed atomically, but not all of them
<larsc>
ah
<mth>
and the bit for toggling the atomic dividers is the one that caused problems for MMC
<mth>
I have to explicitly disable that bit after the PLL change
<mth>
by the way, even for the ones that can be changed atomically, the docs still instruct you to gate the clock during the PLL change
<wpwrak>
larsc: now, my device is a usb dongle ... let's see if we have an example for some platform device registration ... here, one, misc/ftdi-elan.c ... hmm, lovely code. weaponized newlines :(
<wpwrak>
larsc: ok, i think i have an idea how to proceed. thanks a lot !
<mth>
larsc: by the way, please don't forget to cherry pick the UDC fix
<mth>
into jz-2.6.39
<DocScrutinizer>
mth: so gating the clock sounds like inbound data gets garbled inevitably
<DocScrutinizer>
you'd need to suspend all inbound data paths prior to doing that clock meddling
<DocScrutinizer>
by whatever means
<mth>
yes, and it's going to be different for every peripheral driver
<DocScrutinizer>
or postpone clock switching until all IO finished and it's guaranteed that it doesn't resume
<DocScrutinizer>
mth: indeed, a PITA
<mth>
an easier but less elegant approach would be to suspend the system and set a new PLL on resume
<DocScrutinizer>
hey :-D
<DocScrutinizer>
that's what I call a brilliant hack :-)
<mth>
I think it was Ayla who originally mentioned that idea
<DocScrutinizer>
of course clumsy
<DocScrutinizer>
but anyway, should at least work
<mth>
it's always good to have a plan B
<DocScrutinizer>
hehe
<mth>
it's even better if you don't have to use it :)
<DocScrutinizer>
yup
<DocScrutinizer>
or just temporaraily use it, as a stepstone
<DocScrutinizer>
iirc some brave guy fixed that annoying mess for s3c2442 in the end
<DocScrutinizer>
after zillions of kernel locks and other 'nice' effects that were incredibly hard to debug
<DocScrutinizer>
probably it's not completely debugged and evaluated yet today
<DocScrutinizer>
as it's almost impossible to create a proper testbed for all the races you may face
<mth>
you can't really test parallel code
<mth>
well, you can test and see it fail, but if it passes you still know very little
<mth>
I had hoped for static code analysis to help out here, but it's not happening yet
<DocScrutinizer>
I'm not sure about the current sttae of things, wouldn't be surprised to find cpufreq/governour not yet used on a larger basis at all, in SHR
<DocScrutinizer>
mth: exactly
<DocScrutinizer>
well, static code analysis as I know it is a lot of work :-)
<DocScrutinizer>
and no fun for most people
<mth>
I know, I've done formal proofs of 3 pages for a 10-line parallel program
<mth>
that's why I was hoping it would be (semi)automated by now
<DocScrutinizer>
yup, and for a system consisting of virtually an arbitrary number of peripherals it's almost  impossible
<DocScrutinizer>
you just need 3..10 coders developing concurrently, the comparing their code and discuss the differences
<mth>
my solution was to move to async communication wherever possible
<mth>
but the Linux kernel is not built that way
<DocScrutinizer>
sure, but that's hard
<mth>
for networking I use Twisted nowadays
<mth>
and in our MSX emulator we handle all peripherals by posting events on the main thread and handling them there
<wpwrak>
mth: twisted ?
<DocScrutinizer>
thinking of a stupid simple tty interface, you need to consider latencies in periph, sw/hw handshake, whatnot
<mth>
wpwrak: async framework for Python
<wpwrak>
ah :)
<mth>
it has loads of modules for various protocols
<mth>
and the interfaces are usually well designed
<wpwrak>
mth: for verification, the spin model checker can be quite useful
<DocScrutinizer>
?
<wpwrak>
mth: and Promela beats writing pages of formal proofs ;-)
<DocScrutinizer>
I only know PROMEA
<mth>
wpwrak: thanks, I'll do some reading about those
<DocScrutinizer>
a siemens serial card for sicomp M-series
<wpwrak>
DocScrutinizer: you write a model in Promela (a C-like language), then the model checker can do state space explorations and test certain properties. e.g., that your protocol doesn't spend infinite time without making progress or that you
<wpwrak>
're always able to handle the respective next message
<DocScrutinizer>
mhm
<DocScrutinizer>
sounds nice
<wpwrak>
DocScrutinizer: there are also some fancier things you can do with it. but the basics already give you a good idea of how your protocol really works.
<wpwrak>
DocScrutinizer: often, you actually find the bugs while making the model ;-)
<DocScrutinizer>
I'd expect the bugs sneaking in from improper definitions of system properties
<mth>
I needed something like this when I designed a simple 3-line communication protocol
<DocScrutinizer>
e.g. dealing with tty IO, you need to take into account FIFO size and propagation delay of RTS/CTS handshake
<mth>
it worked great most of the time, but it could hang up on transmission errors
<DocScrutinizer>
for the usual things I have my builtin natural promela ;-)
<DocScrutinizer>
which is one of my better properties
<wpwrak>
DocScrutinizer: you'd be surprised how badly even simple-looking protocols can derail :)
<DocScrutinizer>
I'm well aware :-)
<DocScrutinizer>
not unusual I exploit such flaws ;-)
<DocScrutinizer>
generally it all boils down to "missing else" syndrome, most of the cases
<fusin>
moin jungs
<fusin>
hai
<fusin>
no 1 alive?
<fusin>
any guru awake?
<fusin>
needs to pray once again ;)
<xMff>
there are probably several gurus awake
<xMff>
but since you didn't pose a question yet they can't decide on the responsibility
<fusin>
I need 'enlightement'.
<fusin>
In other channel someone meant there ain't no need to use 64bit kernal, if memory < 4Gig.
<fusin>
He pretend it is bad because 64bit programms need twice the memory compared to 32bit programs
<fusin>
is this treu?
<xMff>
before we discuss this further please be aware that this is the wrong channel
<xMff>
its not about general hardware but the Qi project in particular
<fusin>
coz if so: I run 3 days now without swap, and memory is seldom more than 40% in use
<xMff>
and yes, its true that 64bit programs use a bit more space but not exactly twice as much
<fusin>
okay & thx.
<fusin>
So i shall reinstall in 32bits :D
<mth>
x86-64 has more registers though
<mth>
for some applications that might give a performance boost
<mth>
depends on whether it's limited by memory bandwidth or by raw processing power