Topic for #qi-hardware is now Copyleft hardware - http://qi-hardware.com | hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects | public logging at http://en.qi-hardware.com/irclogs
xiangfu has joined #qi-hardware
<qi-bot>
xiangfu: @qihardware @milkymistvj, Very cool documents on "Milkymist One SMT/DIP Process Flow" by @Adam : http://t.co/fdiE33ci ( 194218372148375553@xiangfu - 39s ago via Ping.fm )
cladamw has joined #qi-hardware
<wolfspra1l>
wpwrak: I want to kick the wpan in shape a little
<wolfspra1l>
first step is to cleanup the patches inside openwrt so that it can work on other routers too
<wolfspra1l>
do you have any guidance as to what's the best thing to do next there?
<wolfspra1l>
xiangfu: what are your plans?
<wpwrak>
hmm, i should finish the new driver then. and see what things have happened on linux-zigbee since. haven't touched any of this in months.
<wolfspra1l>
wait wait, I don't want to distract you
<wolfspra1l>
:-)
<wpwrak>
(new driver) i.e., make atusb fast enough that it can handle TCP over dirtpan
<wolfspra1l>
I need boom urgently
<wolfspra1l>
much more important from my side
<wolfspra1l>
but I think it's the right thing to move the patches in openwrt such that it can easily work on a router, no?
<wolfspra1l>
that's an easy thing to do
<wpwrak>
depends a bit on the state of the rest of 802.15.4 framework
<wpwrak>
if not much has changed, then it should be relatively easy
<xiangfu>
I have moved the atUSB patches to target/xburst.
<xiangfu>
now needs cleanup and move to linux/generic for all router that have usb host.
<xiangfu>
wpwrak, I haven't test atUSB under OpenWrt. but for now. atBen works just fine.
<wolfspra1l>
xiangfu: yes, sounds great!
<wolfspra1l>
so we can make it work between a ben and a router
<xiangfu>
yes.
<wolfspra1l>
perfect
<wpwrak>
xiangfu: atusb has the problem that it needs to many (slow) round-trips between host and board to actually send a packet. that causes it to run into problems with TCP very quickly. as long as a higher layer implements what amounts to half-duplex communication, it's fine, though. (just a little slow)
<wpwrak>
atben, on the other hand, doesn't have USB in the way to slow it down, and doesn't suffer such issues
<wpwrak>
it can still experience trouble (like stalled connections)
<wpwrak>
but that has other reasons, not really in the domain of the things i've done
<wpwrak>
(although one could alleviate them a bit by forking the at86rf23x driver)
<wolfspra1l>
I don't have a particular use case in mind right now
<wolfspra1l>
I just want to keep the work in a maintainable state, rather than the patches/drivers falling into coma
<wolfspra1l>
but yes, I hear you
<wolfspra1l>
"usb to slow it down"
<wolfspra1l>
:-)
<wpwrak>
maybe a good time would be once the driver is updated. then atusb should work quite smoothly. and then we can pimp it more efficiently ;-)
<wpwrak>
(usb to slow it down) the problem is that the host controller (UHCI, OHCI, etc.) does transfers in 1 ms slots
<wpwrak>
this means that you only get one round-trip communication in one slot, even if the actual dialog takes only a few usecs
cladamw_ has joined #qi-hardware
xwalk has joined #qi-hardware
<wpwrak>
and the atusb driver spend 99.something % of its time patiently waiting for the next slot ...
<wolfspra1l>
yeah but on the urgency scale, I need boom
<wolfspra1l>
I want to source m1r4 with boom, or compare sourcing status (what we have already) and what's missing with it, etc.
<wpwrak>
yup. i agree. boom first :) just explaining what's amiss with wpan
<wolfspra1l>
yes, perfect
<wolfspra1l>
xiangfu will start by moving things in a better place in openwrt
<wolfspra1l>
that's a small practical step to make the work more accessible
<kristianpaul>
wolfspra1l: had you noticed last dash7 news?
<kristianpaul>
good, i was re-organizing my stuff today and found rfm12b stuff and tought i dash and found this
<wpwrak>
their lawyers don't seem to believe in the simplicity of "click here to download the PDF" :)
<kristianpaul>
wpwrak: :)
Zhai has joined #qi-hardware
<qi-bot>
[commit] Adam Wang: changed VDDPLL, VDDRCV, VDDRX to input instead of Power input since a common power network generates local net/lable as usual. (master) http://qi-hw.com/p/kicad-libs/e6d4981
<qi-bot>
[commit] Adam Wang: changed HSWAPEN to input which pin controls the internal pull-up resistors on all of the user I/O pins from power-on through completion of configuration. A Low level applied to the pin during configuration enables the internal pull-up resistors, while a High level disables them. (master) http://qi-hw.com/p/kicad-libs/18ae19f
<cladamw_>
so this 'revert' will also change my local file back, right ?
<xiangfu>
cladamw_, yes.
<cladamw_>
xiangfu, okay. tks. :)
<xiangfu>
cladamw_, it will only change the local file. as long as you don't run 'git push'
<cladamw_>
xiangfu so the git server will still have last commit existed there since I just did 'revert' and i see that commit history still on there, right ?
phirsch has joined #qi-hardware
<xiangfu>
right. git revert it like: commit1(e6d4) --> commit2(be5f) --> commit3(18ae1), it will only revert commit1. keep the commit2 and commit3.
<xiangfu>
s/it/is
<qi-bot>
xiangfu meant: "right. gis revert is like: commis1(e6d4) --> commis2(be5f) --> commis3(18ae1), is will only revert commis1. keep the commis2 and commis3."
zhai_ has joined #qi-hardware
<qi-bot>
[commit] Adam Wang: Revert "changed VDDPLL, VDDRCV, VDDRX to input instead of Power input since a common power network generates local net/lable as usual." (master) http://qi-hw.com/p/kicad-libs/6291bf5
<qi-bot>
[commit] Adam Wang: pwr.lib : added VIDEOIN_A3V3, VIDEOIN_A1V8, ETH_A3V3, ETH_A1V8, ETH_PLL1V8 for application power. (master) http://qi-hw.com/p/kicad-libs/1bff27c
<wpwrak>
you may have to uninstall kicad when you reach the point of installing
<wpwrak>
but you can even test it first
<wpwrak>
so once you've compiled everything, you can, for example, start the new eeschema with /your/path/kicad/eeschema/eeschema
<wpwrak>
then see if it looks right
<wpwrak>
then, apt-get remove kicad (or similar, depends on how you installed your present kicad)
<wpwrak>
then make install
<cladamw>
i see a file "kicad.bzr" after "bzr checkout -r 3494 lp:kicad kicad.bzr" so keep following your README now i think. :)
<wpwrak>
then open a new xterm (or do PATH=$PATH), launch eeschema again, then check that the version is right
<cladamw>
okay, need to try. :)
<wpwrak>
very good. make the path above then /your/path/kicad.bzr/eeschema/eeschema :)
<wpwrak>
kicad is pretty friendly when it comes to installation. the hard part is getting it to compile at all ;-)
<cladamw>
alright
<cladamw>
wpwrak, the current latest m1r4 whole schematic i fixed it now leaves TWO warnings only, I can't figure them out why.
<wpwrak>
let's see
<cladamw>
phew~ from 66 warnings down to todays' last two wanings. :) so I would to use your this latest patches, then check it again hope I install successfully.
<wpwrak>
two warnings is a good value for such a large design
<wpwrak>
hah, i get 16 warnings ;-)
<cladamw>
i haven't uploaded all files( kicad-libs/components, and milkymist/board-m1/r4)
<cladamw>
so maybe that you just got 16 warnings. :-)
<wpwrak>
then i misread your "I can't figure them out why" :)
<wpwrak>
chances are that the new eeschema will find more rather than less. there's a general tendency that warnings get added, hardly ever removed :)
<cladamw>
wpwrak, ha... well... must be haven some tricky ways to cheat DRC/eeschema to pass them. :-)
<cladamw>
there's much funny things I re-edited different ways to let free warnings and passed, you will see. funny though !
<cladamw>
but I can't rely on my older version. so later we know. :)
<wpwrak>
sometimes there are indeed "invisible" problems. such as a net that looks as if it was connected but isn't.
<wpwrak>
hmm, all these board-specific power symbols are a bit troubling
<wpwrak>
alas, kicad more or less forces you to do things that way :-(
<wpwrak>
since you can't rename a power symbol in the schematics
<cladamw>
ln: creating symbolic link `patches': File exists
<wpwrak>
then you've already done it
<wpwrak>
if you did it wrong the first time, rm patches and try again
<wpwrak>
hmm, i think we should make our version of "PWR_FLAG" a bit more explicit that the original. lemme try ...
<cladamw>
there's four 'cmdline-*.patch under adam@adam-laptop:~/eda-tools/kicad-patches$
<wpwrak>
quilt patch -a
<wpwrak>
quilt takes care of the rest :)
<cladamw>
wait:)
<wpwrak>
(the link is to the directory. so, when in kicad.bzr, ls patches should also show you the files in eda-tools/kicad-patches/)
<cladamw>
type "quilt patch -a" under adam@adam-laptop:~/eda-tools/kicad-patches/kicad.bzr$ or ~/eda-tools/kicad-patches/ ?
<wpwrak>
under kicad.bzr
<cladamw>
yeah ... i found and now install 'quilt' :(
<wpwrak>
hah ! :)
<cladamw>
wpwrak, so like this ? and run each *.patch one-by-one ? adam@adam-laptop:~/eda-tools/kicad-patches/kicad.bzr$ quilt ~/eda-tools/kicad-patches/cmdline-common.patch -a
<wpwrak>
no
<wpwrak>
quilt push -a
<cladamw>
wpwrak, yes, i agreed that making our own version of "PWR_FLG".
<wpwrak>
just do as the README says :)
<cladamw>
adam@adam-laptop:~/eda-tools/kicad-patches/kicad.bzr$ quilt push -a
<wpwrak>
hmm, something's not right with "powered" ..
<wpwrak>
(slow) it's C++ ...
<cladamw>
wpwrak, i found eechema will everytimes changes *.sch once i used system's PWR_FLG and fixed err, the PWR??? (??? means number ) will always be changed. I don't know how eescheme it works. you can check for a while. :)
zedstar has joined #qi-hardware
<wpwrak>
uh, these numbers may not mean a lot
<cladamw>
since i've seen they are auto changed. :)
<cladamw>
maybe sschema manages internal pwr net, etc. :-)
<wpwrak>
with proper power flag, still 9 errors
<cladamw>
green or blue ?
<wpwrak>
uh ?
<cladamw>
green(warings) blue (err) :)
<cladamw>
9 errors includes green and blue ones. :)
<wpwrak>
didn't look at the markers. it counts 9 errors and 9 warnings
<cladamw>
wow..okay
<cladamw>
actually they should be easiler to fix. :)
<wpwrak>
e.g., FLASH_A0 ... A3 no connected
<wpwrak>
hmm. you have an A2 sheet in there ? :)
<cladamw>
yes
<cladamw>
since FPGA.sch is too large. :) Is it to related ?
<wpwrak>
naw. but it's too big. maybe one can still read A3 when printing, but A2 would be tiny
<cladamw>
we can split it into two A3 sheet if it's not displayed well for you. :)
<wpwrak>
yes, we should keep sheet sizes reasonable. i'm not even entirely sure about A3 ...
<cladamw>
hmm...sounds you're right. then we seperate A2 into two-A3 later.
<wpwrak>
i would also rename some of the sheets. don't name them by component but by function.
<wpwrak>
e.g., not "ADV7181CBSTZ" but "Video In"
<wpwrak>
same for micel, micron, xilinx, wolfson, the other analog devices, numonix
<wpwrak>
ah, s/rename/relabel/. in the overview sheet. the file names look okay
<cladamw>
wpwrak, sure ... okay. :)
<wpwrak>
but you hardly see them (the file names) on the big sheet :)
<wpwrak>
(build_ looks great
<cladamw>
wpwrak, yeah....needs to think another way to display text bigger for "Video In" "Audio In/Out" etc ...
<wpwrak>
now launch eeschema and check help / about eeschema
<cladamw>
i found text can't be placed within in eeschema's hierarchical rectangle. so need to study more. or you know how to. :)
<wpwrak>
(bigger text) i would just not mention the chips at that point. that's not really useful information there, and when we change a chip, you'll always have to remember to change it in the overview, too.
<wpwrak>
it can't ? i though it could. checking ..
<wpwrak>
works fine for me :)
<wpwrak>
it is hard to do things with it there, though. e.g., you can't easily move it around
<cladamw>
i tried to place text within that hierarchical rectangle but not.
<cladamw>
yeah
<cladamw>
oah..nice ! yours can do it. :)
<wpwrak>
yours too :)
<wpwrak>
did you check the version ? just run eeschema
<cladamw>
wait. help me to finish the PATH
<wpwrak>
you mean PATH=$PATH ?
<cladamw>
i typed "eeschema" under adam@adam-laptop:~/eda-tools/kicad-patches/kicad.bzr$ but it's older one(BRZ 2448), so how to set PATH ?
<cladamw>
yes
<wpwrak>
try which eeschema
<cladamw>
/usr/local/bin/eeschema
<wpwrak>
interesting. that's where you've just installed the new version
<cladamw>
yes. then ... ?
<cladamw>
:)
<wpwrak>
okay, PATH=$PATH
<wpwrak>
then eeschema again
<wpwrak>
if you still get the old version, try
<cladamw>
nice ! now 3494 :)
<wpwrak>
.... not needed :) ...
<wpwrak>
perfect ! ;-)
<cladamw>
(2012-0408 ZR 3494)-testing
<wpwrak>
now you can try to see for yourself what errors are there :)
<cladamw>
wpwrak, tks for your helps. and the new GUI is amazing though. :)
<wpwrak>
unfortunately, it also has a few quirks
<wpwrak>
you'll see. e.g., when dragging. that's now a bit inconvenient and takes a while to get used to
<cladamw>
wpwrak, INTERESTING! I got still those two warning!
<wpwrak>
that suggests that you didn't commit all your files :)
<cladamw>
really? wait. i need to upload my DRC default settings to compare to yours.
<cladamw>
except those files with timestamps changes I didn't commit, then i always use 'git checkout -- *.lib or *.dcm" after i see there's no differences after typed "git diff filename". :)
Ayla has joined #qi-hardware
<wpwrak>
git diff tells you which files are known and have changes
<wpwrak>
there's one more step: if you add files manually with git add, then they disappear from git diff. you can see them with git diff --cached
<lindi->
"git ls-files -m" lists modified files if you need them in a reusable format
<lindi->
and "git ls-files -o" lists files that are not in the repo
<wpwrak>
this will probably remove the two ERC warnings/errors you got
<wpwrak>
(this = the cleanup)
<wpwrak>
if we still diverge afterwards, we'll need to try tarballs ...
<cladamw>
wpwrak, yeah... since this board-m1 is my firstly done with frequently git commit, actually i don't know if I did well on git work though. :-)
<wpwrak>
so far, it looks good. oh, and we should track the changes in schhist
<cladamw>
wpwrak, be careful on my skill on git work now. :)
<cladamw>
so don't open permission unless you think that i'm qualified. :-O
<wpwrak>
schhist is a pretty good detector for commit problems ;-)
<wpwrak>
(permissions) naw, there's something wrong in the setup on project.qi-hw.com
<wolfspra1l>
wpwrak: you want to add board-m1 to schhist?
<wolfspra1l>
I needed to do it anyway...
<cladamw>
xiangfu, wpwrak i think from now on, who wants to contribute this project, should all sync to the latest tools(KiCad patches) how do you think ?
<wpwrak>
cladamw: agreed. if versions are too much out of sync you run into too many little problems
<cladamw>
yeah...
<cladamw>
xiangfu, so please also use latest KiCad patches. :-)