<qi-bot>
[commit] Werner Almesberger: modules/usd-card.fpd: renamed "depth" to "push" and increased from 1.3 mm to http://qi-hw.com/p/kicad-libs/e6fd40b
<wpwrak>
thanks !!
<kyak>
rafa: just try openwrt with setfont2 un-fuzzy-4x8-font.pnm, you'll understand :)
<kyak>
rafa: also, i didn't quite understand what about the colors
<kyak>
xiangfu: hi!
<xiangfu>
kyak: Hi
<kyak>
do you detect any problems with the latest openwrt-xburst image? for example, mkfs.ext2 is not working (it hangs)
<kyak>
i have the same problem with my self-built image and with default latest one
<kyak>
however, there was no such problem in 2010-06-15 image
<kyak>
i believe, it could happen after switching to uClibc-0.9.32
<kyak>
(i don't know what else software is affected)
<xiangfu>
kyak: yes. maybe. I just checked  mkfs.ext2/3/4 all doesn't work.
<xiangfu>
kyak: even "--help"
<kyak>
yes
<xiangfu>
kyak: ok. I will write down it in my TODO list. ahh maybe I send one email to openwrt upstream first. see if other people have the same problem.
<kyak>
i tryed now building from scratch (i.e. not only all possible make clean's, but also manually removed staging_dir which is left for some reason). i believe some old libraries could be mixed in
<kyak>
but i'll be able to flash only in the evening..
<kyak>
xiangfu: thanks!
<xiangfu>
kyak: yes. I also try to do that in my PC. "make distclean" :)
<kyak>
make distclean proved to be nto so clean , too
<kyak>
build_dir is not removed
<kyak>
staging_dir is kept, too
<kyak>
and there's a lot of old stuff in staging_dir/host
<kyak>
openwrt_xburst dir was 1.5 Gb after make clean's. Then, after i manually removed old things, it was arounf 950 Mb
<kyak>
also, make distclean removes dl/ dir, which is nonsense
<kyak>
the most harmless dir
<xiangfu>
kyak: yes. I already mv the dl to ..  , but I didn't notice it not remove the staging_dir and build_dir. thanks for the info.
<kyak>
no problem!
<xiangfu>
then I will "make distclean" then remove those two folders . compile again. if it's fix the mkfs.ext2/3/4 problem.
<kyak>
great!
<xiangfu>
we need release a new release :)
<kyak>
if this works
<xiangfu>
yes. :) it's need 3 ~ 4 hours compile in my pc.
<kyak>
i left it running for the night, not sure how much it took :) would be great to have some time output by make, too
<kyak>
or just "time make"
<xiangfu>
kyak: Hi "make distclean" remove the "stage_dir" and "build_dir" (I just finish the "make distclean")
<xiangfu>
kyak: after "make distclean" and "mv dl/ .." . it's only 144M.
<kyak>
xiangfu: hmm
<kyak>
let me re-check
<xiangfu>
kyak: now I am "time make"
<kyak>
xiangfu: also, distclean removes your .config :)
<kyak>
xiangfu: you are right, build_dir and staging_dir are removed
<kyak>
140M now
<xiangfu>
the dl is 785M. so total is 900+M.
<kyak>
i'll take the default config from data/ and time make
<kyak>
714MÂ Â Â Â dl
<kyak>
:)
<wolfspraul>
xiangfu: can we keep a second config somewhere to build a xbboot image with some rescue tools only?
<wolfspraul>
for example in data/qi_lb60/conf/config.xbboot ?
<kyak>
wow, what was that? is qi-hw server in a neighbour house? :)
<kyak>
hm, not really from the BUILD_LOG if mirco had the staging_dir removed..
<kyak>
*not really clear
<wolfspraul>
I am thinking about turning the latest/ symlink on the server back to 0615, not 0826, because 0826 seems to have a number of severe regressions
<wolfspraul>
what do you think?
<kyak>
maybe it needs to be renamed to devel
<xiangfu>
hmm.. I think we keep the latest symlink to 0826. if we found more issue in 0826. it's good for next release.
<kyak>
and the "latest" is official 0615
<wolfspraul>
ok, xiangfu argues for increasing the pain level :-)
<kyak>
xiangfu: should i ^C the beautiful clean make? :)
<xiangfu>
kyak: no need.  we put the command line in uboot. we can change the command when system boot. use uboot-env tools.
<kyak>
@IF 2I FC A@DB?C H5,
<kyak>
how do we change it?
<kyak>
are you saying it can be changed during runtime?
<xiangfu>
kyak: yes.
<xiangfu>
we have add the uboot-env to 0826 release.
<kyak>
how to use it?
<kyak>
does it take kernel command line from some env variable during flashing?
<kyak>
i'm intersted, because i recently played with qemu-JZ, but without any luck.. basically because our uboot detectes that U key is always pressed for some reason and uboot from qemu-JZ doesn't like our kernel command line
<xiangfu>
there are two command : fw_printenv  fw_setenv
<kyak>
where are those commands?
<xiangfu>
in your nanonote: /usr/sbin/
<xiangfu>
fw_setenv is to set the uboot'env.
<xiangfu>
and in uboot's ENV , there is "commandline"
<xiangfu>
after set we must reboot to make it works.
<xiangfu>
about the U key. it's hard code to u-boot.
<kyak>
oh, got it now!
<xiangfu>
you need edit the u-boot source to disable the detect U key.
<xiangfu>
if you set the wrong comandline. we must to connect the NN serial console to fix it.
<xiangfu>
press [S] when poweron. NN will goto u-boot console. then we can fix the u-boot envs.
<kyak>
ok, i understand !
<kyak>
xiangfu: are you interested in playing with qemu-JZ?
<xiangfu>
kyak: I just don't have enough time to play with qemu-JZ. but I'd like to if I have time
<kyak>
ok :)
<mth>
kyak: maybe the GPIO reading of non-connected pins returns the wrong value in qemu-jz?
<mth>
am I right in assuming that non-pressed keys should read in the same way as a non-connected keyboard?
<wpwrak>
mth: have you considered what you'd have to do to dis_connect_ the keyboard ? :-)
<mth>
I have no idea
<wpwrak>
(assuming we're talking about then ben) you'd have to split the pcb in half :)
<mth>
I'm not suggesting to actually disconnect it, just as a though experiment
<mth>
in a matrix keyboard, a non-pressed key reads as a not-connected pin afaik
<mth>
so if the keyboard is not emulated by qemu, all keys should read "not pressed"
<mth>
but the opposite seems to be the case
<mth>
I had the same problem when emulating the Dingoo (which uses direct GPIO keys, not a matrix keyboard)
<wpwrak>
thought experiment is less scary :) well, the keyboard is integrated into the pcb. so you can't disconnect it. but if a trace was severed, then this would appear as the absence of pressed keys, yes
<wpwrak>
as far as i recall, there are no external pull-ups either
<mth>
each GPIO can be configured to pull up or not
<Ornotermes>
i been up a while, working on my break out board
<wpwrak>
Ornotermes: the little board works quite well. some little issues i found: because it's thicker than uSD, it doesn't go in/out quite as easily. not sure if this is a problem. i may also have accidently deposited some adhesives this way, which would make the problem worse.
<Ornotermes>
so i noticed
<wpwrak>
Ornotermes: the mechanical tolerance for board width is relatively narrow. if it's too small, it won't "click"
<Ornotermes>
it is possible to snd souwn rhe card a little to make it easier to put in/out
<Ornotermes>
sand*
<Ornotermes>
down the*
<wpwrak>
Ornotermes: and you need about 1.4 mm between the edge of the "card" and any ben-facing edge of the outer board, or you can't push it in enough to click. but in think you're using a much bigger margin for this anyway, so not a problem there.
<Ornotermes>
i started out with big margins, i idea was that people other than ben users might be interested
<wpwrak>
Ornotermes: (sand) yup. didn't want to dremel at 3 am, though :) (my mill sits in a sound-proofed box, that it's not so easy to trim the board along the z axis with that one)
<wpwrak>
ah yes, good point
<wpwrak>
i looked around for the specs of the card holders, but didn't find any that said how much travel this thing really needs
<wpwrak>
kristianpaul: thanks ! :)
<wpwrak>
s/that it's/ but it's/
<wpwrak>
need some caffeine ...
<Ornotermes>
it's getting time to test if the board actually works
<Ornotermes>
i had to do some creative fileing
<wpwrak>
hehe :) hardware hacking in all senses of "hardware" :)
<Ornotermes>
a couple of pads shorted when the card was inserted
<Ornotermes>
but i just reflashed so i have to start by copy som things from my card
<wpwrak>
Ornotermes: i still need to find out if the corners need to be rounded or not. probably a good idea to do it in any case.
<Ornotermes>
i too think its a good idea, it makes less risky when inserting the card
<Ornotermes>
also, i found it more prectical to bridge ethernet with usb0 on my desktop and let ben get a dhcp adress
<wpwrak>
oh yes. that's the only sane way for communication at the moment. i really wouldn't want to connect ethernet this way. maybe ieee 802.15.4
<wpwrak>
(the latter is one of the reasons why i'm so interested in that idea :)
<Ornotermes>
oh, i meant instead the firewall method with static adress between ben and desktop
<Ornotermes>
i would peronally prefer bluetooth to connect my ben wireless
<Ornotermes>
i mean, even lego uses bluetooth
<wpwrak>
(address) aah, i see. well, depends. i like my gadgets to be easily identified. but i'd have to go to dhcp too if i wanted to talk to more than one at a time.
<wpwrak>
i've prefer bt, too. but then, even bt has openness problems :-(
<wpwrak>
e.g., try to find even the data sheet of an affordable BT module
<Ornotermes>
yeah, but if there were internal usb with a hub it bould use usb bluetooth
<wpwrak>
ah, digi-key goodies have reached buenos aires customs :)
<wpwrak>
yes, that it could do. not sure about power efficiency, though. and you'd still want a bit of documentation for all the non-usb things the modules have too.
<wpwrak>
plus, there are some special parameters also via BT that you may want to access. i don't quite remember what it was, but we ran into that problem at openmoko. couldn't determine one of those items.
<Ornotermes>
it could be an idea to try to get a dialog with a company that make bluetooth chips and try to make them to open them
<wpwrak>
good luck :-)
<Ornotermes>
atleast enough to use them in open source hardware
<wpwrak>
i'm quite sure this has been tried before
<wpwrak>
and remember, sharism is a customer who doesn't generate revenue. 1000 units it not even worth hitting "reply".
<Ornotermes>
yeah, but a open enough chip could make a greate impact
<kyak>
Ornotermes: the disadvantage of bridging is that interface has to be put down every time to build a bridge
<kyak>
no very useful when you connect/disconnect Ben often
<Ornotermes>
kyak: really? i have it set up in my network configuration, just plug it in and start ben
<kyak>
try pinging something, then connect Ben.. you should see your pings momentarily gone
<kyak>
your bridge is built via udev, when you connect Ben, right?
<Ornotermes>
no, static pridge
<Ornotermes>
bridge*
<kyak>
hm..ok, maybe.. anyway, i have no problems using NAT on Ben
<Ornotermes>
it's not a "problem" to use NAT but by bridging i have more access to ben from my network
<kyak>
i'd use DNAT for that, if i needed
<kristianpaul>
morning :)
<kristianpaul>
xiangfu: hey thanks you too for pointing this feature about uart emulation over usb
<xiangfu>
:)
<kristianpaul>
really awesome !
<kristianpaul>
i wonder what else i can emulate over usb ;D
<bartbes>
wait
<bartbes>
did
<bartbes>
I seriously break gmenu2x?
<bartbes>
I had no problems.. and I never heard someone had problems either
<bartbes>
anyway, I would update to the new image
<bartbes>
if sdl wasn't broken
<wolfspraul>
bartbes: yes it's broken. I was already worried it could affect you.
<bartbes>
well I wouldn't mind messing with gmenu2x, but I compiled my version, ran it on my version of the image
<bartbes>
no problems whatsoever
<bartbes>
I'll try again though
<bartbes>
so, what is the exact problem with SDL anyway?
<bartbes>
updates toolchain
<bartbes>
nanomap, huh?
<bartbes>
sounds cool
<zear>
ah yeah, i'd have some questions about the nanomap ;)
<zear>
first, wht is it exactly? i haven't tried it yet
<zear>
second, what libs does it use? SDL perhaps?
<zear>
i'd be interested in porting it to the dingoo, if it runs on sdl and can display offline maps
<bartbes>
yeah, I have no idea either
<bartbes>
well, if it ran on sdl it wouldn't run on the nanonote atm, would it?
<bartbes>
:P
<bartbes>
oh..
<zear>
i haven't been paying attention to owrt lately, was rather busy with jlime
<bartbes>
I think I know why gmenu2x might crash
<zear>
so we have broken sdl now?
<bartbes>
wolfspraul: do you have the gmenu2x crash too?
<wolfspraul>
bartbes: yes, for example starting dgclock will crash gmenu2x
<bartbes>
ehm
<bartbes>
I only touched the explorer..
<bartbes>
I thought it was about the explorer anyway
<zear>
bartbes, explorer in the gmenu2x?
<bartbes>
yes
<bartbes>
from the list:
<bartbes>
>>Â Â - the gmenu2x-explorer is unusable right now - gmenu2x is seg-faulting
<bartbes>
>> immediately - is anybody willing to take care of that?
<zear>
heh, that's not good
<bartbes>
because it *sounds* like the default dir doesn't exist
<zear>
we need gmenu2x soon for open-dingux release
<bartbes>
(though arguably it shouldn't segfault)
<zear>
bartbes, wasn't default set to / ?
<bartbes>
no
<bartbes>
/card
<zear>
it should read default from a config file
<zear>
instead of being hardcoded
<bartbes>
it's a compile-time define
<bartbes>
but yeah it should
<zear>
ah, so it's good
<bartbes>
well, I made it more flexible
<bartbes>
somebody already abstracted it
<bartbes>
but left some of the hardcoded lengths in
<bartbes>
oh no wait
<bartbes>
it's *not* a define
<bartbes>
OH GOD
<zear>
hmm.. wasn't the latest change in 28 days?
<bartbes>
I should really, really fix that
<bartbes>
I thought somebody committed..
<bartbes>
he told me he was fixing it
<zear>
or there is yet another repo?
<bartbes>
not that I know of
<bartbes>
hence the conclusion I broke it
<zear>
i thought you were talking about some new changes
<bartbes>
I see
<bartbes>
removing /card actually causes the segfault
<qi-bot>
[commit] Werner Almesberger: modules/stdpass.fpd: added experimental -M variants for manual soldering that http://qi-hw.com/p/kicad-libs/476841d
<roh>
wpwrak chandra is down, seems to be some scheduled rz stuff.
<roh>
means: it should be back soon
<wpwrak>
roh: ah, good. thanks !
<Ornotermes>
wpwrak: (bbl) the gpio is controlled by manipulating the memory, right?
<wpwrak>
Ornotermes: the port registers are memory-mapped, yes
<Ornotermes>
good, i was thinking of controlling the gpio from python
<wpwrak>
Ornotermes: the concept they use is interesting: you don't write values directly to the registers but you have a set and a clear register. each 1 you write to the set register gets set, each 1 you write to the clear register gets cleared. that way, there can be no conflicts with read-modify-write instructions
<unclouded>
this stuff is fantastic.  what about shipping a uSD breakout with every Ben?
<wpwrak>
Ornotermes: hmm, i once tried to do these things on the ben with python and i found that the mmap didn't quite work. not sure whether this was just my installation or not, though. so if it doesn't work, you may want to strace it to see if mmap is really called with the correct arguments.
<wpwrak>
Ornotermes: if i recall properly, the one i had trouble with was the address. i think it got shifted or such.
<Ornotermes>
unclouded: could be cool with a "hacker pack" that has several other hacking tools too (usb-uart converter and other stuff)
<Ornotermes>
wpwrak: it is worth giving a try, especially since the whole python thing is more beginner friendly
<wpwrak>
Ornotermes: yup. well, if it doesn't work and you can figure out why, you'll have done mankind yet another great favour :)
<wpwrak>
unclouded: thanks :) needs a bit more comments on the registers, though. i did it in a bit of a hurry :)
<unclouded>
it's really useful having something short enough to read in one go that gives a demonstration of how to drive the SDIO pins.  that's what I meant to say
<unclouded>
just need to remove the comment about "command line parsing", which is confusing
<wpwrak>
unclouded: ah yes, that's actually one of the ideas behind making it :)
<wpwrak>
oh :)
<wpwrak>
i'll do a bit of spring cleaning after dinner
<roh>
wpwrak btw: about the microchip enc28j60 stuff... spare yourself the pain
<roh>
that stuff sucks and dies if you cough a bit on the ethernet
<roh>
my current way of putting ip on avr's is using the serial and speaking zbus
<wpwrak>
roh: heh. i have no plan whatsoever to connect that thing to ethernet :)
<wpwrak>
roh: but this little connector should also be enough to put ieee 802.15.4 there :)
<roh>
which connector?
<wpwrak>
the microsd, with a little pcb inside, and bit-banging it
<roh>
my point is only: the enc thingie is crap. not worth the work. falls over and deadlocks a lot in realworld ethernet segments
<roh>
there is nothing to bitbang which makes sense.
<wpwrak>
maybe post that to the list for those who might want to try that ether thing
<roh>
also its not unusual nowadays to have atleast singledigit, if not even 2 digit mbits of multicast load on a ethernetsegment, even at home
<wpwrak>
(bitbang) the at86rf230 doesn't speak sd/sdio/mmc and the ben's mmc engine can't speak spi. so bitbang it is
<roh>
makes this thing not only saturate the phy, but also deadlock. it seems it deadlocks a lot.
<roh>
means: it doesnt even recover from a saturated phy
<wpwrak>
(mcast) ah, interesting. i don't think i have any on my net :)
<roh>
and its not that it wouldnt have mac-addr and multicast filters.
<roh>
wpwrak what do you think they use for iptv? ;)
<roh>
tcom-vdsl is multicast. you send group-joins and then get the traffic routed through your dsl line.
<wpwrak>
no iptv here :)
<roh>
same here. but we got a hw-mpeg encoder on our cnc mill machine with a robot-cam
<roh>
generates 8-10mbit multicast
<roh>
in the end its much easier to use a serial and let something else handle ethernet.
<roh>
if one wants 'ip connectivity' and not neccessarily 'ethernet'
<roh>
about the at86rf230.. bitbanging doesnt sound that bad... or is the chip that fast on datarate?
<wpwrak>
naw, data rate is 250 kbps. maximum spi speed (from buffer) is 8 Mbps.
<roh>
doesnt sound so bad.
<roh>
does the ingenic cpu have no spi at all? or is the limitation to 'no spi' only for the mmc engine?
<wpwrak>
it has spi, bit it's blocked by the keyboard on the ben
<wpwrak>
also, you can't have the spi engine on the mmc pins
<wpwrak>
(unless you connect them in some way, of course)
<roh>
gnnnh.
<wpwrak>
so for connecting boards to the uSD connector of the ben, it's bit-banging
<roh>
ok.. old problem.. keyboard suckage
<wpwrak>
or hardware that speaks SD/SDIO/MMC :)
<wpwrak>
yeah, the choice of signals for the keyboard is pretty much pessimal, if this word existed in english :)
<wpwrak>
actually .. it does. just has a different meaning :)
<roh>
hrhr
<Ornotermes>
i'm back
<Ornotermes>
a microcontroler sdio - spi converter would be so cool :)
<wpwrak>
Ornotermes: you could probably do it with a psoc3/5 and the little cpld inside
<Ornotermes>
i think that would be a bit over my head for now :P
<Ornotermes>
i use AVRs
<wpwrak>
consider it an opportunity to lean something new :)
<wpwrak>
leaRn
<wpwrak>
alas, these chip still aren't in production. they've been available for evaluation only for more than a year now. not sure what's keeping them.
<wpwrak>
so it's still possible that they won't really make it to the market. that would be a pity.
<Ornotermes>
there is atleast eval kits to buy
<wpwrak>
btw, one very nice thing about uSD is that there's also a clock output there (the SD/MMC clock). just what i need for ieee 802.15.4 ;-)
<wpwrak>
should be able to multiplex miso and mosi over a single data line (the transceiver seems to support such a thing). so even the small number of signals shouldn't be a big issue.
<roh>
fooood
<wpwrak>
roh: does your food come when you call it ? :)
<roh>
nah.. was fetching it outside
<wpwrak>
grr. mail still down :-(
<wpwrak>
roh: (food) ah, good old hunter and gatherer style :)
<roh>
berlin is great. <300m and choice of food
<Ornotermes>
wpwrak: but i think a cheap avr might be good enough to convert SDIO to SPI or I2C
<wpwrak>
Ornotermes: sdio is a bit tricky. you need to synchronize with the master clock and you have to be prepared to receive any time.
<Ornotermes>
what is the clock frequency?
<wpwrak>
Ornotermes: but if the SD/MMC clock is slow enough and you have short response time, then why not
<wpwrak>
not much meat on the mechanical side there :-(
<Ornotermes>
oh well, i have to sleep
<Ornotermes>
good night
<wpwrak>
wolfspraul: btw, how open can we discuss features of the various ingenic cpus, especially those of the jz4760 ?
<wpwrak>
wolfspraul: btw2, do you know the dsv (data sheet viewer) system i use in ben-wpan ? (a successor of the one in gta02-core)
<wolfspraul>
wpwrak: 4760, I think we can discuss openly, why not. There is not that much to discuss anyway.
<wpwrak>
great. things like the number of SDIO units or what other peripheral blocks are there. nothing fancy, i agree. just wanted to be sure they didn't explicitly ask you to keep all this secret or such.
<larsc>
jz4760 = more of everything ;)
<wolfspraul>
my passion is not around such chips anyway, they are just temporary stepping stones.
<wpwrak>
larsc: yeah, it's a bit of a wet dream come true :)
<wpwrak>
larsc: e.g., 3 SD/MMC units. wow.
<wolfspraul>
well when I started to work with Ingenic my hope was that their engineering would be so bad that they couldn't do major upgrades that would destroy our GPL work.
<wpwrak>
;-)))
<wolfspraul>
so by now, larsc has been doing phantastic work on the Linux kernel side. Now let's see whether Ingenic holds their part of the teamwork.
<wolfspraul>
in other words - how easy it will be to support the 4760...
<wolfspraul>
I will try to explain to Ingenic that they should re-base their work on kernel.org
<wolfspraul>
not sure whether they get it though...
<wolfspraul>
about the 3 SDIOs
<wolfspraul>
Ingenic will first try to throw everything in, like lars said "more of everything"
<wolfspraul>
then on the way to actual customers, things are thrown out again
<wpwrak>
oh yes, they should definitely do that. and be more open about the specs. it's really bad for open collaboration if you never quite know how much the person you're talking to knows.
<wolfspraul>
either because they failed on the engineering side (their people just can't get the stuff to work)
<larsc>
well, even the 4750 has some substatial changes. So I doubt that most of the 4740 drivers will work for the 4760
<wolfspraul>
or because of packaging
<wolfspraul>
one interesting thing in the 4760 is the dual-core
<wpwrak>
(now work for the 4760) that would be unusual. normally, function blocks are just copied with as few changes as possible
<wolfspraul>
maybe one core can be dedicated for GPS signal processing or such
<wpwrak>
btw, 4755 is too
<wolfspraul>
my rough Ingenic roadmap looks like this:
<wolfspraul>
first - meeting with them to talk about upstream (2.6.36). I will ask them to release the 4740 programmer's manual under cc-by-nd. And I will ask them to re-base their work on upstream.
<wolfspraul>
Xiangfu does have a 4760 EVB, and we did some hacking on it already, u-boot etc.
<wolfspraul>
so I will ask for another 2 EVBs, bringing the total to 3
<wpwrak>
sounds good so far
<wolfspraul>
then I can have one for Adam to study, and one for Germany, for exampe if Lars is interested
<wpwrak>
also the 4720_ds, please. you really need both.
<wpwrak>
yup. perfect
<wolfspraul>
then I need to talk with them seriously about 4760 packaging
<wolfspraul>
so far I have only heard about a 350-ball bga package
<wolfspraul>
basically that's the one where everything of the 'more of everything' will be brought out
<wpwrak>
you prefer COB ?
<wolfspraul>
no no
<wolfspraul>
wait
<wpwrak>
;-)
<wolfspraul>
I am not sure whether this 350-ball bga package will ever really be sold, or demanded by customers
<wpwrak>
ah, i see. well, it's not bigger than the others
<wolfspraul>
it could be that there is too much failed and random stuff in there, the down-side of the 'more of everything' strategy
<wolfspraul>
so last time the CEO also spoke about 2 other packages they are planning - 256-ball BGA and 128-pin qfp.
<wolfspraul>
these things are changing quite a bit, btw. it's super demand driven.
<wpwrak>
not sure just putting more of the same is a big design risk. i'd worry much much more about new things.
<wolfspraul>
so I have to find out - which of the 4760 variants (if any) will actually become a high-volume product.
<wolfspraul>
I think one reason we had quite a lot of fun with the 4740, including say larsc (let me know if I'm wrong), is that the 4740 is found in many products
<wpwrak>
fun = obscure bugs ?
<wolfspraul>
so the kernel work we did applies to Sungale, Hanvon, Dingoo - not just the exotic 'copyleft' Qi stuff
<wolfspraul>
no, interesting devices
<wpwrak>
ah, fun = motivation
<wolfspraul>
yes
<wolfspraul>
also meaningful
<wolfspraul>
great kernel.org support for a bunch of EVBs? come on...
<wolfspraul>
we are wasting everybody's time
<wpwrak>
bah, just focus on hack value ;-)
<wolfspraul>
there are too many things to hack on
<wolfspraul>
anyway
<wolfspraul>
that's why I stay away from 4750 and 4755
<wolfspraul>
they did not 'catch on'
<wolfspraul>
so some people are forced into them, but there really is no adoption wave, and never will be anymore
<wpwrak>
oh, i see. 4750 would be a "plan B", feature-wise
<wolfspraul>
I will not touch it.
<wolfspraul>
rather do Milkymist NanoNote right away
<wpwrak>
heh ;-)
<wolfspraul>
my work needs to make sense (create value) from a free software perspective
<wolfspraul>
the fact that the NanoNote helped to get 4740 support into kernel.org is good for a lot of projects
<wpwrak>
i niche 4750 would also be a sourcing risk
<wolfspraul>
I cannot get lost in tons of proprietary features that are popping up here and there. life is too short :-)
<wolfspraul>
sourcing is OK
<wolfspraul>
there is only 1 source anyway, so strategically the risk is always the same. and I have a good relationship.
<wolfspraul>
so about 4760
<wolfspraul>
I need to understand which package may have the chance to catch on.
<wolfspraul>
then I know which features are inside (or rather come out in that particular package)
<wpwrak>
(sourcing) i mean, if nobody else uses it and you're small, they may have to scrap it, no matter how much they like you
<wolfspraul>
if we do a Ya NanoNote, we are still free to choose - 350-ball bga, 256-ball bga, even 128-pin qfp (although I am afraid that one will have very little of anything)
<kristianpaul>
wolfspraul: hey
<wpwrak>
you may want to consider having a 32 bit ram bus
<wpwrak>
also, 4760 supports DDR
<wolfspraul>
wpwrak: making another wafer is cheap
<kristianpaul>
wolfspraul: just curios about  issues in SIE manufacturing process
<wolfspraul>
I think they currently still use 6 or 8'' wafers
<wpwrak>
so you could be up to 4x as fast as the ben
<wolfspraul>
so that's maybe 1000 ICs
<kristianpaul>
i just read carlos mail about getting time short for hist studets start hacking the boards :)
<kristianpaul>
so i just feel curios to ask about :)
<wpwrak>
(making another wafer) hmm, usually things that sound so easy aren't ;-)
<wolfspraul>
kristianpaul: no all is fine. there was a couple days delay in getting all tests to work. the components are with the SMT factory already, run should be Friday/Saturday this week.
<wolfspraul>
wpwrak: I will ask a bit more about it, always curious to learn these things.
<wolfspraul>
I want to focus on high-volume chips anyway.
<kristianpaul>
wolfspraul: usual delays i guess? nothign to worry or take care next time?
<wolfspraul>
so that's where 4760 stands, and that's why I don't know whether it's 3 SDIO, or 2, or 1
<wpwrak>
yup. safe choice in all regards
<wolfspraul>
kristianpaul: the 'delay' Carlos is talking about is relative to the wiki schedule Adam wrote up.
<kristianpaul>
wolfspraul: ah ok ;)
<wolfspraul>
but that's not really fair. We are writing up the schedule as a first 'good guess', and share it.
<wpwrak>
okay. let's hope for the best. something like 2 SDIO and >= 2 SPI would be nice, preferably >= 3 SPI.
<wolfspraul>
two weeks into the work you realize, oh well, you need another week
<wolfspraul>
so you push out the schedule
<wpwrak>
you cna't have too many SPI anyway ;-)
<wpwrak>
or SD with SPI mode support
<wolfspraul>
if this wiki schedule would have been written by wpwrak it would first be finished in 2 weeks, and 6 months later wpwrak would still be working on very valuable stuff
<kristianpaul>
:)
<wolfspraul>
so yes, there were 'delays' on the wiki schedule, but in my experience all is smooth and moving forward.
<wolfspraul>
the next big thing will be whether the SMT run is successful, and functioning boards come out
<kristianpaul>
sure delays happens
<wolfspraul>
we know Monday
<wolfspraul>
it's not a real delay IMO
<wolfspraul>
rather a miscalculation
<wolfspraul>
if Carlos would have asked me, I would have doubled all numbers from Adam anyway.
<wpwrak>
wolfspraul: you should know by now that there's no point in asking me for a schedule ;-))
<wolfspraul>
on my schedule, there is no delay.
<kristianpaul>
ah thats explain it more !
<wolfspraul>
there you go
<kristianpaul>
:)
<wolfspraul>
I understand Carlos sentiment however. we are trying to make these boards asap.
<wolfspraul>
we have dropped the ball on everything else to get this done. Not more I can do. And neither can Carlos that's why he writes the mail :-)
<wolfspraul>
I know the students are waiting since August 10.
<wolfspraul>
and they even have paid already by now.
<kristianpaul>
wpwrak: kernel modules or programas? i need to write a sort of logic analizaer and draw on screen 3 signals at ~ 2Mhz rate using gpio, what you recommend based on your experience?
<kristianpaul>
wolfspraul: sure thats emotinal stress happens after the "cash get out the hands"
<wpwrak>
kristianpaul: you mean kernel or user space ? where does the data come from ? gpios ?
<kristianpaul>
i just was worried about some more tecnical process or soemthing
<wolfspraul>
well on my side too. I hate pre-pay/pre-order. And essentially I accepted that because I sold the boards before I had them manufactured.
<wolfspraul>
what if there is a manufacturing problem now? very bad for me.
<wolfspraul>
but like I said, we are breaking all the rules just to get these boards made asap, because the students cannot wait
<kristianpaul>
wpwrak: yeah sorry, kerl or user space, from a SPI-like out-put from a IF chips, gpios from ben
<wpwrak>
kristianpaul: sounds more like all user space than kernel of you don't mind running with privileges. that way, you safe the time it takes to get in and out of the kernel
<wolfspraul>
wpwrak: before the dsv, I'm curious about ben-blinkenlights
<wpwrak>
kristianpaul: you'll probably need elevated cpu priority. do you write to the screen directly ?
<wolfspraul>
you made it yourself? do you need a new kernel driver or can you control the lights with the current kernel already?
<kristianpaul>
wpwrak: yeah all to make it fast
<kristianpaul>
also because later need do some FFT
<wpwrak>
wolfspraul: yup, i made it. you just run bbl (fro bbl.c) as root
<kristianpaul>
of course in that step i dont need write to screen
<wpwrak>
kristianpaul: do you need to respond to interrupts ?
<kristianpaul>
i just need to start debugging what i'm reading from the chip
<kristianpaul>
wpwrak: dont know yet..
<wpwrak>
wolfspraul: the idea to use the uSD port came from Ornotermes. he also made a nice 1200 dpi scan of a uSD card that helped to get this done more rapidly
<wolfspraul>
wpwrak: so no new drivers needed. just run user-space as root?
<wpwrak>
wolfspraul: yup
<wpwrak>
wolfspraul: bbl just reprograms the gpios. kicks out sd/mmc ;-)
<kristianpaul>
i think wpwrak relly like user space :=)
<wpwrak>
(fortunately, sd/mmc doesn't mind. i didn't actually check if this was safe. but if it wouldn't be, i'd know by now :)
<kristianpaul>
hey i forgot ask you about reading data using uSD
<kristianpaul>
now that wpwrak is making good examples to use it on the openwrt
<kristianpaul>
may be i can use uSD instead of gpio..
<wolfspraul>
does your discovery of the sdio possibilities mean that ben-wpan will now be attached to the microSD-connector, rather than on the side of the LCM?
<wpwrak>
kristianpaul: you can tell a good kernel developer by how well he/she is at avoiding to do things in the kernel ;-)
<wpwrak>
kristianpaul: you should be able to read back things without a problem
<wpwrak>
wolfspraul: well, the story is a bit more complicated. for the ya/ben II, i still think the lcm is the place to go
<wpwrak>
wolfspraul: but i can prototype on uSD. and the prototype could become an upgrade for the existing ben.
<wolfspraul>
yes I would love to manufacture crazy microSD cards
<wolfspraul>
:-)
<wolfspraul>
also, you know my opinion on proprietary microcontrollers
<wolfspraul>
not that I want to stop anybody
<wolfspraul>
but every new proprietary tool or compiler we introduce slows us down
<wolfspraul>
I'm talking about that CapSense stuff
<kristianpaul>
wpwrak: i'm just really worried that the monolic kernel we use all days, may slowdown acess and fast response talking about GPIO
<wolfspraul>
I agree the 8051+cpld is already a bit better.
<wpwrak>
wolfspraul: so this saves me having to worry about tricky cabling for a while. the tricky cabling is particularly bad because i don't even have the right kind of cable (fpc with customized shape), so it'll be an uphill battle all the way, with many annoying failure modes that just distract from what i want to do
<wolfspraul>
yes yes
<kristianpaul>
wolfspraul: good point about microcontrollers
<wolfspraul>
totally agree
<kristianpaul>
wolfspraul: so add micro fpgas (kidding about micro) is better for you?
<wolfspraul>
so with any (new or old) proprietary ICs, at least I want to understand how they help on the path to more freedom. if I have such a path in mind, the proprietary IC becomes acceptable.
<kristianpaul>
or just re-ue and avbuse from ingenic xbust as much as we can ;)?
<wolfspraul>
yes sure, if that means some of the work we do in the micro-fpga can be carried forward into our own ICs later
<wpwrak>
wolfspraul: that was just to answer carlo's question. i don't quite see capacitative sending in the main keyboard. and for the slider/softbuttons next to the screen, i think having to add an MCU just for that would have a poor cost/benefit ratio
<wolfspraul>
if anything I want to make my own ICs
<wolfspraul>
we need a good (small) starting point for that anyway
<wpwrak>
wolfspraul: so i'm all for not having MCUs unless we really really have to. and of course, the more open and better supported with tools and the like, the better
<wolfspraul>
we are on the same page
<kristianpaul>
wpwrak: i hope you order from digikey some cpld's too ? :)
<wolfspraul>
and if it's a fpga/cpld programmed in verilog/vhdl, and we can later carry this forward into a bigger fpga, or into our own asic, then that's the way to go
<wpwrak>
wolfspraul: in fact, i'll probably kick the MCU from IDBG and switch to FT232R. the latter now seems competitive and we don't really need the ability to run our own code in IDBG on the ben.
<wpwrak>
wolfspraul: (in case that changes, i can always bring the MCU back, of course :)
<kristianpaul>
FT232R !
<wpwrak>
kristianpaul: no cpld/fpgas for me for now. first, lekernel has to write his Open/Free fpga synthesizer ;-)
<kristianpaul>
wpwrak: wut?
<kristianpaul>
well.
<kristianpaul>
a PHd take time i guess
<wpwrak>
kristianpaul: i'm not particularly fond of those ft232 chips, but in this case, it just looks like the better solution. slightly fewer external components, no programming required, similar price, same size.
<kristianpaul>
wpwrak: i dont understand you said not to fpga/cpld but still using propietary Micro-controllers, so whats diferences?
<wpwrak>
kristianpaul: ft232r is a black box for me. i don't care about what's going on inside. it does serial and bit-banging for me. that's enough.
<kristianpaul>
wpwrak: indeed
<kristianpaul>
same with micro-controllers?
<wpwrak>
kristianpaul: microcontrollers, i have to program. so they're not a black box
<kristianpaul>
even when you know you can implement one SoC with the already made MM ?
<kristianpaul>
wpwrak: you program a blackbox..
<wolfspraul>
wpwrak: sorry I have a stupid question for you
<kristianpaul>
the manufacture just give you the manual wich tell what is inside the box
<kristianpaul>
you buy it
<kristianpaul>
use it
<wpwrak>
kristianpaul: fpgas are tricky. i would generally want them for the ability to hack them. but yes, if i just needed it to load mm and be happy with it, fpga would be okay.
<kristianpaul>
and belive it works as he said
<wpwrak>
kristianpaul: i also don't mind that my usrp has a proprietary fpga. again, just a black box for me.
<wpwrak>
wolfspraul: fire away :)
<wolfspraul>
someone wants to manufacture a wifi design around xburst with me. he says he can give me the entire design, and I can open it up if I want to.
<kristianpaul>
sure fpga uses propietary sinteshys sofware but at least you can model some digial hardware, is that bad??
<wpwrak>
wow
<kristianpaul>
:O
<wolfspraul>
so now, he writes "we have a power amplifier that brings RF power to antenna to 23-25dbm, I guess you don't need that"
<wpwrak>
wolfspraul: what are the semantics of "entire" ? :)
<wolfspraul>
oh, it's still a closed wi-fi chip, nothing special, not on our level here :-)
<wolfspraul>
I am just trying to understand what he means with "we have a power amplifier ... to 23-25dbm"
<wolfspraul>
and why I would or would not need that
<wpwrak>
most transceiver chips have a relatively low power output
<wpwrak>
(that is, transceicers with built-in power amplifier)
<wpwrak>
so sometimes you add another one to boost the signal more
<wolfspraul>
ah so it's stronger than usual?
<wpwrak>
this one would be 300-320 mW
<wpwrak>
err, 200-320 mW
<wpwrak>
yes. 100 mW would be normal for wifi
<kristianpaul>
thats more a my wrt54gl, isnt?
<kristianpaul>
oh
<wpwrak>
(if i got all the regulations right ;)
<wolfspraul>
so with that power amplifier it would not be cerfitiable as a regular wi-fi retail ap by the fcc?
<wolfspraul>
s/cerfitiable/certifiable/
<wolfspraul>
:-)
<wpwrak>
kristianpaul: according to mine, it can go up to 251 mW
<kristianpaul>
wpwrak: wrt54gl?
<wolfspraul>
how hard is it to remove such a power amplifier from a design?
<wpwrak>
wolfspraul: dunno. it may be a case of "as long as you promise not to use it where you're not allowed to" ...
<wpwrak>
wolfspraul: 100 mW isn't strictly the limit of the regulations. you can go up to 1 W, but with additional constraints
<kristianpaul>
1 W :O
<wpwrak>
wolfspraul: at least in FCC land. EU is another story again.
<wpwrak>
kristianpaul: yup
<wpwrak>
wolfspraul: i read most of the regs with the question "could we be in conflict with this one ?", so i'm not so sure on the things that i can exclude a priori, e.g., xxl power amps
<wpwrak>
for reference, my wrt54gl is set to 42 mW output by default
<kristianpaul>
ahh i knew it !
<wpwrak>
(remove the PA) should be easy. you're likely to find more documentation on the design without extra PA than the one with it.
<kristianpaul>
but that up to 251 mW is a openwrt thing or firmware that mye not obey to you?
<wpwrak>
except if your transceiver needs a PA either way. they you would have to find a different PA
<wpwrak>
kristianpaul: dunno. i just see that it offers 251 mW and i assume its not lying to me :)
<kristianpaul>
k
<wpwrak>
well .. let's see what happens when i set it ...
<kristianpaul>
ah you never tried that before? !
<wpwrak>
nope. i just knew that tx power is usually something you can change, yet i rarely do
<wpwrak>
most of the time, the ap's tx isn't the problem anyway
<wolfspraul>
ok I think I got it, roughly.
<wolfspraul>
well if he pays me enough money and I can open up some nice (if high-level) design files in the process, I'll manufacture the stuff for him :-)
<wolfspraul>
we won't crack open the wifi thing like this ever, anyway
<wolfspraul>
unfortunately
<kristianpaul>
:(
<wolfspraul>
wpwrak: did you digi-key shipment make it through customs?
<wpwrak>
wolfspraul: still sitting there. they're slow today :-(
<wpwrak>
wolfspraul: never had problems with things from digi-key, though. so unless they don't like the antennas for some reason, i don't expect any this time either.
<wpwrak>
wolfspraul: they once dropped a shipment from openmoko off the regular process and made me clear customs myself (trip to the airport, day lost going from one office to the next, etc.) because they thought this could be something to crack stolen phones.
<wpwrak>
wolfspraul: little do they know :)
<wolfspraul>
wpwrak: 'dropped off the regular process' - was this with fedex?
<wpwrak>
wolfspraul: not sure if it was fedex or dhl. it wsn't ems. (ems goes elsewhere)
<kristianpaul>
wpwrak: how do you argue those itemes were not to crack phones?
<wpwrak>
kristianpaul: i just tell them what they are for. and i don't explain to them that i wouldn't need all this if i really wanted to set up a phone cracking shop, and that, yes, i could explain them in detail how to do it. well, almost :-)
<wolfspraul>
in reality, the complexity of all this has long surpassed what governments can actually regulate
<wolfspraul>
but in a move of massive inertia, they are able to hold up the perception of regulation for a bit
<kristianpaul>
heh
<wolfspraul>
wpwrak: I was just asking because fedex claims to have their own customs brokers, so with fedex theoretically it should never 'drop out of the regular process'
<wolfspraul>
the broker will always drive the process, maybe unless you really smuggle some drugs or weapons or fissile material etc...
<wpwrak>
wolfspraul: yeah, when talking to those customs guys, it's always tricky to assess where exactly between sticks and stones and the transistor they are :)
<wolfspraul>
well they have no chance
<wolfspraul>
it's a show
<wolfspraul>
but the show must go on
<wpwrak>
ah no, fedex, dhl, they all have their brokers. they do the simple process.
<wolfspraul>
dsv (data sheet viewer) - no I didn't know yet. tell me more...
<wolfspraul>
what is that? where can I see it?
<wpwrak>
if it drops out of this, you're on your own. they don't even have a broker they can recommend you. (although that may be because of some arrangements/regulations, not because they wouldn't want to help you)
<wpwrak>
(dsv) check out ben-wpan
<wpwrak>
then  make dsv
<wpwrak>
wait until it's done. then
<wpwrak>
scripts/dsv antenna
<wpwrak>
scripts/dsv at86rf230
<wpwrak>
scripts/dsv mcu
<wpwrak>
etc.
<wpwrak>
or just scripts/dsv
<wpwrak>
note the time between experiencing the desire of seeing a data sheet and the moment it appears :)
<wolfspraul>
it tries to be smart and sometimes tell you to use git@, sometimes git://
<wolfspraul>
:-)
<wolfspraul>
instead of explaining the whole situation
<wpwrak>
it could show both :)
<wolfspraul>
if you log out from your account, it will give you the git:// URL for sure
<wolfspraul>
yes I agree
<kristianpaul>
i wasnt logged frist time i try
<kristianpaul>
okay i uploaded my public key !
<wolfspraul>
ok can you try the command I just gave you? the git:// url. what do you get?
<kristianpaul>
ah sure that works
<wolfspraul>
okay, maybe that also works as long as you only read. you should not be able to commit unless your account is an admin or member of the projects (depending on projects settings, but that's the default)
<kristianpaul>
now the git@ too :)
<wolfspraul>
wpwrak: ok yes, it is really downloading some PDFs
<wpwrak>
some sites are a bit on the slow side :(
<wolfspraul>
btw, quite a few websites have fine print against 'deep links'
<roh>
wolfspraul doesnt support ssl at all
<wolfspraul>
they pull it out when their legal dept has you on the radar
<wpwrak>
"pull it out" = change the path ? or make you not link ?
<wpwrak>
(try to)
<wolfspraul>
it's not really enforced until there is a bigger reason to go after you
<wolfspraul>
"In addition, you may not "deep-link" or use robots, spiders or other automatic devices, programs, algorithms or methodologies to monitor, access, copy or acquire any Materials or portions of this Site."
<wolfspraul>
so if your script goes to such a site, it violates the terms of use of that site
<wolfspraul>
sorry, just fyi (you do this to me with 'regulations' all the time :-))
<kristianpaul>
gn8
<wpwrak>
there doesn't seem to be a safe way to access such sites then
<wpwrak>
even written instructions in plain english could be read by a script, etc.
<wolfspraul>
you have to describe the steps to go to the document you mean in prose ("go to the homepage. click on ..., then click on ..., then ...")
<wolfspraul>
no need to argue with me, I just quote the terms of use :-)
<wolfspraul>
it's my regulation 1:1 with you...
<wolfspraul>
we are even now
<wpwrak>
;-)
<wolfspraul>
they will pull this out if they have you on the radar for something
<wolfspraul>
of course they will. they have lawyers sitting around who need to justify their jobs.
<wpwrak>
so the solution would be something that actually parses step by step instructions
<wolfspraul>
I guess it's still a "program, algorithm or methodology"?
<wolfspraul>
I don't know, it's stupid.
<wolfspraul>
let's ignore this shit
<wolfspraul>
:-)
<wpwrak>
so would be any description a human being can be reasonably expected to repeat accurately :)
<wolfspraul>
hey: and this is logged!
<wpwrak>
yeah, ignoring it seems to be the best approach :)
<wpwrak>
if they don't like it, one can always send it to some warez site and link that one ;-)
<wpwrak>
the "deep link" stuff usually comes up when you try to pretent the content is yours. that's not the goal here at all
<wolfspraul>
they can pull it out whenever they like to.
<wolfspraul>
if you go down to 'supporting documentation', you have the legally accepted way to link to the PDF on the mips.com site
<wolfspraul>
right before "Bit/little endian" - do you see it?
<wpwrak>
yup, i see it. hmm, isn't the full title, combined with google, as "deep link" too ? :)
<wpwrak>
wolfspraul: the URL "dsv" uses are in the file BOOKSHELF. so would you rather not have them on projects ?
<wolfspraul>
no no
<wolfspraul>
relax
<wolfspraul>
:-)
<wpwrak>
just checking :)
<wolfspraul>
I just bring this up because it's a fact, same as the regulations you are pulling up.
<wolfspraul>
I don't know how many tech sites have deep links rules in their terms of use now.
<wolfspraul>
but I could imagine that it grows, for sure. the lawyers are writing and writing and writing...
<wolfspraul>
and they have the law on their side
<wolfspraul>
so if they would ever understand what this script does, they will write you a nice letter to stop violating their terms of use.
<wolfspraul>
if you are lucky, the letter does not come with an invoice.
<wpwrak>
yes. i know of the issue in general. but also all the work-arounds don't quite convince.
<wolfspraul>
the best is to get rid of proprietary IP altogether
<wolfspraul>
kick all those comanies out
<wolfspraul>
they have too much money, for the wrong things, obviously
<wpwrak>
find a cure for lawyers ;-)
<wolfspraul>
in this case it starts with proprietary IP that they need to 'protect'
<wolfspraul>
the deep link nonsense is just one small little tool in the 'protection' arsenal
<wolfspraul>
but if you think they won't use it, for whatever reason, well, wrong
<wolfspraul>
they will
<wpwrak>
i wonder how alldatasheets do it. after all, they even have copies. now that should enrage the nazguls.
<wolfspraul>
the opencores plasma homepage is so clean because they got some help from MIPS :-)
<wpwrak>
lovely
<wpwrak>
one of these days i'll write that english -> url parser :)
<wolfspraul>
I don't know how alldatasheets does it
<wolfspraul>
maybe somewhat undergroundish?
<wolfspraul>
is there a legal entity behind it? where are they located? where are their servers? etc. etc.
<wolfspraul>
it's a big world :-)
<wolfspraul>
and what is their legal strategy? react quickly to take-down notices?
<wolfspraul>
there are many strategies
<wolfspraul>
obviously the servers are still there, so whatever their strategy is, it seems to work in the real world
<wpwrak>
maybe it's time for making a little satellite with a few TB of storage :)
<wpwrak>
"serve *that* task-down notice" :)
<wolfspraul>
there you go
<wpwrak>
s/task/take/
<wolfspraul>
good idea
<wolfspraul>
the freedom satellite!
<wolfspraul>
I love it
<wolfspraul>
PCBs made in werner's diy lab
<wpwrak>
;-))
<wpwrak>
anyway, what dsv tries to solve is the generally much worse IP violations caused by the need to send around copies of data sheets
<wpwrak>
need or perceived need in this case
<wolfspraul>
we launch it, and it hosts datasheets, ha ha!
<wolfspraul>
:-)
<wolfspraul>
but unfortunately I read that both the Chinese and Americans are working on the ability to take down satellites
<wolfspraul>
even 'dock' on one for 'servicing'
<wpwrak>
we can add some active meteorite protection :)
<wolfspraul>
oh
<wolfspraul>
you are trying to circumvent non-redistribution clauses?
<wolfspraul>
nice :-)
<wpwrak>
plus make it all a bit more efficient
<wolfspraul>
wpwrak: ok dsv finished and it all works. so it's just a way to download files into a cache and view them.
<wpwrak>
yup
<wolfspraul>
it's nice, a way to document urls
<wolfspraul>
unfortunately like I said, with many of those datasheets there may be some nasty terms of use associated with those urls and pdfs
<wpwrak>
the idea is that each project user/participant can get the document set this way efficiently
<wpwrak>
yes. i guess we really need that english to url parser :)
<wolfspraul>
yes, unless there could be a central repository somewhere of greater stability/longevity than these vendor urls, it's good
<wolfspraul>
and such a central repository is too hard to setup right now, so it's the best compromise
<wpwrak>
of course, there's also the question of whether "dsv" falls under the things they can prohibit
<wpwrak>
e.g., the MIPS exclusion would also include your Web browser
<wpwrak>
the central repository would also be a pretty clear violation of traditional copyright law
<wolfspraul>
ah sure, I try to focus on realistic threats only. we just need to keep it in mind, those policies and people to enforce them are out there.
<wolfspraul>
and we are not planning to steal any of their wonderful intellectual property anyway, so it's definitely different from a company that wants to sell cloned ICs, for example.
<wolfspraul>
but unlike the schematics diff scripts, dsv is of no use on the server, I think
<wolfspraul>
(running on the server)
<wpwrak>
yup. we're not the enemy. of course, that doesn't have to prevent their lawyers from becoming ours
<wpwrak>
at least when you view BOOKSHELF in the tree (on projects), the URLs just appear as plain text. so we're not worse than heise.de :)
<wpwrak>
no, dsv is the contrary of being something for the server :)
<wpwrak>
but if you can get companies to make things available at least at the level at which dsv can use them, that would be a win
<wolfspraul>
strange. if I read this correctly, they only give you a license for non-commercial use.
<wolfspraul>
but I cannot imagine that they mean no professional (paid) party can download and use their documentation
<wolfspraul>
so maybe they mean the use of the documents per se must be non-commercial
<wolfspraul>
so I cannot act as a print-shop and print-out the PDFs for a fee
<wolfspraul>
probably... who knows...
<wolfspraul>
I mean I can download the PDF, go down to the street here and have a nice booklet sometime this afternoon still :-)
<wpwrak>
they seem to equate "use" with "reproduction"
<wpwrak>
"termination of this license" ... "Atmel may terminate this agreement immediately without notice, for any reason. Upon such termination, you must destroy all Materials."
<wpwrak>
so, if they dojn't even notify you, how do you know ? :)
<wolfspraul>
well basically the rule is: whatever Atmel wants, will happen.
<wpwrak>
nothing new then :)
<wpwrak>
btw, regarding potential IP problems, the antenna is probably the riskiest bit. after all it's a TI design we're using with an Atmel product. the antenna document doesn't mention any restrictions, so it's anyone's guess if this passes as "fair use" or not
<wolfspraul>
I understand, but let's just move forward.
<wolfspraul>
the most interesting part is that you document the process, test results, etc.
<wolfspraul>
that gives us the knowledge, hopefully, one day if someone comes and bullies us out of a particular thing, to come up with a replacement fast
<wpwrak>
worst case, we can always fall back to a chip antenna
<wolfspraul>
for example I have the feeling the setup of your apartment, with diy pcb etching, usrp, puts you in a position to out-innovate quite a few of the dinosaurs
<wpwrak>
incidentally, there are a few cheap ones in my digi-key order :)
<wolfspraul>
so let's see what you find, what you think works, and then we proceed and I'm fairly optimistic we will not wake up the sleeping dogs too early
<wpwrak>
trial and error cycles can indeed be short :)