#qi-hardware IRC log for Friday, 2012-06-08

cladamwwpwrak, good morning !01:00
cladamwwpwrak, i recalled that new features of Fped will have three densities (Max. Median, Min. ) depends on IPC-7351, i am going to make a generic TC package from page 37 of http://www.kemet.com/kemet/web/homepage/kechome.nsf/vapubfiles/KEM_TC102_LOWESR.pdf/$file/KEM_TC102_LOWESR.pdf  I'll use Median scale. Is it supposedly Fped tried to use Median to scale up / down ?01:06
wpwrakcladamw: it doesn't work like that. fped itself doesn'tknow anything about densities. you have to express that in your footprint definition.02:00
wpwrakhere is my current "work in progress" for QFP: http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules/qfp-gen.fpd02:01
wpwrakas you can see, i have a density table with parameters that change depending on the density02:01
cladamwman! are you trying to say that all fpd had better to have such three densities ? 02:10
wpwrak;-) you get to choose where you want to have them or not :)02:12
cladamwthis example is definitely great to show how densities they work. but I found its hi-lighting shown are not very good to 'review'. this code is mostly like a PHD work instead of nominal purpose though. :-)02:16
cladamwno hi-light can be shown. If someone learns this Fped, the code is relatively not to read easily.02:18
cladamwhe needs very very familiar with this Fped to click to hi-light. :-)02:20
wpwrakyou'll notice that the latest fped is a little better at highlighting than the old one02:22
wpwrakbut yes, the structure of these components is not trivial02:22
wpwrakof course, already figuring out what IPC-7351 says is quite a pain ...02:22
wpwrak(and i'm not sure i really got it all - my footprints don't look like any of the vendor footprints that supposedly follow IPC-7351)02:23
wpwrak(though my footprints should work. when i print them and place a real chip on them, they look quite reasonable)02:24
cladamwall *.fpd are surely good to follow IPC-7351 in the end, but this would be taken more researches for each package, especially there's lots of them. 02:26
wpwrakoh yes. it's a lot of work02:27
cladamwthe footprints get met completely with IPC, the samples on hand should quite meet 1:1 scaling paper design work for sure.02:27
wpwrakbut if we get the hang of it, we can avoid a lot of guesswork in the future02:28
wpwrakthe fped language is a but more powerful that it looks because you also have access to the c preprocessor, cpp. so you have macros and include files.02:29
cladamwbut now i won't do such to meet all fpd to this IPC in short time excepts like KEMET has complete table there, then I make it to be.02:29
wpwrakwith this, some of the IPC-7351 math could be kept in a central location, instead of doing it in each footprint02:29
wpwrakbut that would need some way to express such things in the gui02:30
cladamwagreed, if do so, needs to work out good expression in gui.02:30
wpwraki consider my work on IPC-7351 footprints experimental for now. so yes, no need to rush with copying it :)02:31
qi-botThe build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.full_system-20120607-0926 05:05
qi-bot[commit] Adam Wang: c-t-smd.fpd: added variants named: TC-$Case-$EIA-$Density for relevant EIA size of Tantalum capacitors (master) http://qi-hw.com/p/kicad-libs/9a717ee05:31
qi-bot[commit] Adam Wang: stdpass.fpd: added 1812 size which referred from TycoElectronics (master) http://qi-hw.com/p/kicad-libs/17ae71b07:51
qi-bot[commit] nbd: iproute2: fix build errors with newer versions of eglibc (master) http://qi-hw.com/p/openwrt-xburst/27057b909:23
qi-bot[commit] nbd: eglibc: use 2.15 by default (master) http://qi-hw.com/p/openwrt-xburst/67b7bdf09:23
qi-bot[commit] jow: [package] base-files: implement network_defer_device() and network_ready_device() wrappers for upcoming netifd iface deferring support (master) http://qi-hw.com/p/openwrt-xburst/ab865f709:23
qi-bot[commit] blogic: [tools] fixes python related autokrampf install bug (master) http://qi-hw.com/p/openwrt-xburst/5aab29d09:23
qi-bot[commit] nbd: e2fsprogs: add posix_memalign related portability patch from #8508 (master) http://qi-hw.com/p/openwrt-xburst/9c88d9609:23
qi-bot[commit] nbd: include/netfilter.mk: clean up, remove junk for old kernel versions (master) http://qi-hw.com/p/openwrt-xburst/7bd3c3f09:23
qi-bot[commit] nbd: xburst: remove an obsolete CompareKernelPatchVer call (master) http://qi-hw.com/p/openwrt-xburst/cc530eb09:23
qi-bot[commit] nbd: prereq-build: flex is built in tools/ - do not require it to be installed on the host (master) http://qi-hw.com/p/openwrt-xburst/a16549409:23
qi-bot[commit] nbd: kernel: add module packages for usbip (from the packages feed) (master) http://qi-hw.com/p/openwrt-xburst/a1b2ddf09:23
qi-bot[commit] Mirko Vogt: add <http://downloads.qi-hardware.com/software/mirror-openwrt-sources/> (master) http://qi-hw.com/p/openwrt-xburst/8001e2909:23
qi-bot[commit] Xiangfu Liu: uboot-xburst: update to 2010.06 (master) http://qi-hw.com/p/openwrt-xburst/d1d808409:23
qi-bot[commit] Xiangfu Liu: uboot-xburst: enable-silent-console.patch (master) http://qi-hw.com/p/openwrt-xburst/ccd938709:23
qi-bot[commit] Xiangfu Liu: uboot silent console (master) http://qi-hw.com/p/openwrt-xburst/7200ed709:23
qi-bot[commit] Xiangfu Liu: uboot-xburst: change load kernel size (master) http://qi-hw.com/p/openwrt-xburst/2705c2009:23
qi-bot[commit] Xiangfu: xburst: add WPAN support (master) http://qi-hw.com/p/openwrt-xburst/cfa381609:23
qi-bot[commit] Xiangfu Liu: add WPAN(atben,atusb) kernel module file thansk blogic #qi-hardware @freenode.net (master) http://qi-hw.com/p/openwrt-xburst/521615a09:23
qi-bot[commit] Xiangfu: xburst qi_lb60 disable WPAN kernel options, should build as module (master) http://qi-hw.com/p/openwrt-xburst/fb07ad209:23
qi-bot[commit] Xiangfu: xburst: add Ben NanoNote kernel logo (master) http://qi-hw.com/p/openwrt-xburst/4e3f88b09:23
qi-bot[commit] Xiangfu: xburst: qi_lb60 select the nanonote slash screen (master) http://qi-hw.com/p/openwrt-xburst/cd994e809:23
qi-bot[commit] Xiangfu: remove xburst target borken (master) http://qi-hw.com/p/openwrt-xburst/d5ee22409:23
xiangfuopenwrt-xburst rebased on latest openwrt upstream (Jun 7 svn://svn.openwrt.org/openwrt/trunk@32117)10:02
xiangfunow the only diff is uboot and WPAN patches. :-)10:02
qi-bot[commit] Xiangfu Liu: uboot-xburst: update to 2010.06 (master) http://qi-hw.com/p/openwrt-xburst/af1689d10:44
qi-bot[commit] Xiangfu Liu: uboot-xburst: enable-silent-console.patch (master) http://qi-hw.com/p/openwrt-xburst/fea83e410:44
qi-bot[commit] Xiangfu Liu: uboot silent console (master) http://qi-hw.com/p/openwrt-xburst/a02cee810:44
qi-bot[commit] Xiangfu Liu: uboot-xburst: change load kernel size (master) http://qi-hw.com/p/openwrt-xburst/a6bc3df10:44
qi-bot[commit] Xiangfu: xburst: add WPAN support (master) http://qi-hw.com/p/openwrt-xburst/b62282110:44
qi-bot[commit] Xiangfu Liu: add WPAN(atben,atusb) kernel module file thansk blogic #qi-hardware @freenode.net (master) http://qi-hw.com/p/openwrt-xburst/2dface310:44
qi-bot[commit] Xiangfu: xburst qi_lb60 disable WPAN kernel options, should build as module (master) http://qi-hw.com/p/openwrt-xburst/3f2875610:44
qi-bot[commit] Xiangfu: xburst: add Ben NanoNote kernel logo (master) http://qi-hw.com/p/openwrt-xburst/d87ac1f10:44
qi-bot[commit] Xiangfu: xburst: qi_lb60 select the nanonote slash screen (master) http://qi-hw.com/p/openwrt-xburst/e3e188c10:44
qi-bot[commit] Xiangfu: remove xburst target borken (master) http://qi-hw.com/p/openwrt-xburst/fd4e7e410:44
mthwolfspraul: is it possible to do something about the crashing web frontend for git?13:02
mthit makes it difficult to point new people to the sources13:03
viricwhy it crashes?13:03
mthdunno, but it ends quickly with a 500 error13:03
viricah13:04
mthit is caused by something in the archive, I think, because qi-kernel has the problem and other repositories don't13:04
viricaha13:04
mthhttp://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/master/13:04
viricis the git web implemented in perl?13:05
mthPHP, I think13:06
viricoh13:06
mthwolfspraul was thinking about replacing it13:09
mthbut unless that can be done soonish, it might be better to try and fix it13:09
AylaxReplacing it by what?13:10
mtha different project viewer package13:11
wolfspraulmth: oh, hmm13:11
wolfspraulI didn't know you were suffering from that13:12
kristianpaulcgit :-)13:12
kristianpaulreplace^13:12
mthif I can help resolve the issue, let me know13:16
wolfspraulgive me the weekend then we talk13:33
mirkoxiangfu: Again: please stop putting my very private and spam-free email-address into CC when mailing to mailing lists.. I don't want to have it published in the web13:42
mirkouse mirko@openwrt.org instead13:42
Artyomkristianpaul hi19:05
kristianpaulArtyom: oh hi 19:08
ArtyomI've added a text file with the license (creative commons share a like) to KiCAD project19:11
kristianpaulnice !19:11
kristianpaulArtyom: http://projects.qi-hardware.com/schhist/m1-gps-expansion/19:12
kristianpaulis WIP, for now removing uncesary stuff for the board19:12
Artyomdo you want to use exactly the same scheme?19:13
kristianpauloh you upated to ise 14.1 19:13
kristianpaulnot at all, but make some clean up and fill the boom19:13
kristianpaulnot as simple as the maxim evb board, but without fpga and the other mcu19:14
kristianpauloh u are using verilator19:14
kristianpaulTNKernel?19:14
ArtyomWill you keep USB-bridge? (cy7c68013a)19:15
kristianpaulnope19:15
Artyomonly max2769, tcxo and that's all?19:15
kristianpauland power supply yes19:16
ArtyomI have some ideas about making dual frequency front-end (L1/L2)... What do you think about it?19:17
kristianpaulI agree19:18
kristianpaulbut i'll more focused on the getting a working solution simular to the other comercial receivers19:19
kristianpauland L1 is okay for now (for me)19:19
Artyomif you are interested I can prepare a scheme for dual band front-end...19:19
kristianpaulhmm19:19
kristianpaulusing maxin ic?19:20
kristianpaulnot really interested at all at the moment19:20
ArtyomI don't have a lot time to make everything, but if you are making a redesign... that would be a step forward...19:21
kristianpauli want cutoff some parts19:21
kristianpaulthat apply for layout as well19:22
kristianpaulnot too many drastical changes19:22
ArtyomTNKernel is open-source RTOS. Not very popular but seems better then freeRTOS for example...19:22
kristianpaulbut L2C is currently operational?19:23
kristianpaulif, then worth that step forward19:23
Artyomnot sure about gps but there is also glonass that is fully operational in both L1 and L2 ;)19:25
kristianpaulhe :)19:25
kristianpauldid you get Takuji board finally?19:28
kristianpauls/get/got19:28
kristianpaulso are you playing back with the cpu + fpga combo?19:29
ArtyomI didn't receive Takuji's board :(19:36
ArtyomYeah, I decided to switch back due to some reasons. The first one is that TNKernel has ports for lpc22xx family. Secondly more correlator channels can be implemented without MM SoC in FPGA that I have to use. Thirdly I have plans to teach some people to program on embedded systems and arm is more appropriate for this task...19:39
kristianpaulYou could have tried to get a M1 first, more powefull :)19:40
ArtyomI used ISE 14.1 because I had some trouble during implementation of asym static mem bus interface and I decided that some problems could happen because of ISE. So I decided to upgrade to the latest version...19:41
ArtyomWhen I'll get any sponsore this will be the first thing to do ;)19:41
Artyom(getting M1 ;) )19:42
kristianpaulbut the async issue was not the problem made you chosse milkymist soc at first?19:42
ArtyomI used verilator for verification because icarus-verilof is toooooo sloooowwww for this task...19:43
kristianpaulhe indeed :)19:43
ArtyomYeah, I switched to MM SoC because of async memory interface. But with MM SoC I faced with the task of choosing apropriate RTOS. As I know RTEMS is used in M1. But this OS seems too complicated for my task...19:45
ArtyomAnd the task of rewriting some hdl-code seemed easier then the task of porting RTOS to new architecture (Especially because I didn't have any experience with RTOS beforehand)19:48
ArtyomAnd what about you? Have you received Takuji's board?19:50
kristianpaulyup19:51
kristianpaulfinally19:51
ArtyomNot long time ago?19:51
kristianpauli think i need make some fix on the board before try19:51
kristianpaulyup a month ago19:51
ArtyomColombia's post work better then russian one ;)19:51
kristianpaulyou are big country :)19:52
kristianpaulanyway i would choose arm, if this ran linux,so i feel like in home19:53
ArtyomA little frozen ;)19:53
Artyom(country)19:53
Action: kristianpaul at 33°C :-|19:54
lekernelArtyom: what do you need the rtos for?19:54
ArtyomWell, the main reason because I wanted to check how to work with RTOS. Then Takuji uses RTOS ;) 19:55
kristianpaulgpl-gps port is ecos :)19:57
ArtyomI see the following advantages: program can be split to independent tasks and they can be debuged independently. Besides it helped me to solve problem with transmition data trough uart (com-port).19:57
Artyomwhich I faced with MM SoC + namuru19:58
Artyomyeah, gpl-gps uses ecos but TNKernel seems to be much smaller and easier to understand19:58
kristianpaulbut wast this a problem because your spartan3 dince sinthesize well a cpu cache or something related?19:58
kristianpaul easier to understand, is valid19:59
kristianpaulbut honestly at first look TNKernel dint look very friendly ;)19:59
ArtyomI think the main problem was that UART-core in MM SoC is rather slow. Mainly because it's use in M1 is very limited. But of coarse this problem could be overcomed by addtional C-code ;)20:02
ArtyomAnd also cpu without cache is very slow. Ohnestly speaking I don't know exactly what influenced more: uart-core or cpu without cache20:04
ArtyomAnyway I don't have anything better then fpga-board-with-s3e500 and fpga(s3e500)+mcu(lpc2478) board... So I'm very limited with this development...20:06
ArtyomYes, I would agree that first impression about TNKernel is that it's unfriendly. And there are just few examples on web... I chose it because I found good reviews on electronix forum from local-guru... BTW Sony uses this RTOS in one of it's products ( http://www.tnkernel.com/news.html )20:09
ArtyomBut I don't exclude possibility to switch to some other RTOS like freeRTOS...20:11
Artyomif strong reasons will appear...20:12
lekerneluart core is very slow? wtf?20:12
kristianpaul*g*20:12
lekernelit's not slower than any other. 115200 is the maximum rs232 bitrate.20:13
lekerneland yes, a cpu executing from dram or flash without cache is slow. so use sram or just enable the damn cache.20:14
Artyomcomparing to lpc with buffer for some (16?) bytes it seems slower. I mean that I can send several bytes to uart core and start to make other things.  And in MM SoC it will require extra C-code to implement something similar.20:15
lekernelif you can't write those ~100 lines of C code or just copy mine, I'm afraid you'll have difficulty writing a GPS stack20:17
lekernelor add the same buffer in verilog, it's really not that difficult20:17
kristianpaulstart to make other things, you mean multiple threads support? no just a single thread, right?20:19
lekernel...which is another thing that works out of the box with rtems, mm and xiangfu's build script. but of course, arm and lpcxxx are so much better.20:22
kristianpauli had some issues recently building rtems latelly20:23
kristianpaulreported on #milkymist actually :)20:23
kristianpaulbut indeed, Artyom rtems is not that hard to use20:23
kristianpauland there are plently example by checking flickernoise source code20:24
kristianpaulArtyom: perhaps you could get a M1 cheaper by just adquiring the board20:25
kristianpaullike the early development kit i got20:25
kristianpaulArtyom: just ask wolfspraul about that options 20:25
Artyomlekernel: I've compared two simple things: uart-core that is used by default in MM SoC and uart core in lpc24xx. The second one seems faster because it doesn't require extra C-code (which is of course easy but requires extra time to implement or to understand anyone else code). As I have already noticed I'm limited with free resources and have to work with what I have. I don't know about...20:28
Artyom...RTEMS a lot. But I've read your own unpleasant comments about it's parts (I don't remember exactly but I think you described flash-card api)20:28
lekerneltnkernel has an unfair advantage here: I have never touched it20:30
lekerneland to use the uart with rtems just call printf(). how hard is that?20:32
ArtyomThat is why I decided to check all possible alternatives and I have chosen the one that seems apropriate for my task. But as I said I had zero experience with RTOS beforehand and my choise was made on the base of reading electronix forum.20:32
lekernelelectronics forums are full of crap20:33
Artyomagree - What would you do o my place?20:33
lekernelfirst choose if you want to use ARM or not20:36
lekernelmost people in electronics forums know only about microcontrollers - if you already have a fpga in your system, you probably don't need one20:40
ArtyomAmong RTOS ports most popular are for ARM. That is why I made a step backward. I thought about possibility of porting TNKernel for MM SoC later. Or may be using RTEMS...20:40
kristianpaulporting take time, consider that..20:41
lekerneland I guess you are running Windows, considering it's the most popular OS?20:41
ArtyomLekernel: the bad thing is that I have only fpga spartan 3e 500. Compared to s6slx45 it's tiny... I could hardly insert 4 correlator channels with MM SoC in it...20:42
ArtyomIf TNkernel will be apropriate for my task porting wouldn't be difficult. It's code is well split. And there are ports for different architectures (like 16bit-pic for example)20:44
Artyomlekernel: I prefer not to contrapose (new word for me from the dictionary ;) ) ARM and MM SoC. Both are good. The choise depends only on the task and available resources. When I'll get extra resources for MM1 then I would definitly try to use only it for GNSS.20:48
Artyomlekernel: Windows is fine when you combine it's use with virtualbox with Linux. The main reason are my collegues that are afraid of Linux... It's something terrible for them. And even most of the students are afraid when I say "Linux"...20:51
kristianpaulwe dont need more people been scared for/from any reason :-) 20:52
ArtyomMy friend was very surprised that during traineeship in german university had to work only with PCs under Linux...20:55
kristianpaulthen you just said namuru and milkymist and they got hurt attack ;-)20:56
Artyom1 person from 100 ;)20:57
Artyomgentelmen, sorry that I have dissapointed you with some of my thoughts. And it's time to sleep for me. bye.20:58
kristianpauli'm not dissapointed20:59
kristianpaul..20:59
viricmth: I had a hang in the sheevaeplug again... 22:29
viricthe relevant part is:22:31
viric[<c0008d94>] (__irq_svc+0x34/0x98) from [<c006a0a4>] (out_of_memory+0x12c/0x354)22:31
viric[<c006a0a4>] (out_of_memory+0x12c/0x354) from [<c006d2f8>] (__alloc_pages_nodemask+0x5e4/0x60c)22:31
viric[<c006d2f8>] (__alloc_pages_nodemask+0x5e4/0x60c) from [<c0068be4>] (filemap_fault+0x1e0/0x4b0)22:31
viric[<c0068be4>] (filemap_fault+0x1e0/0x4b0) from [<c007e3dc>] (__do_fault+0x68/0x4b4)22:31
viricit looks like out_of_memory does not success choosing a process to kill... but I don't know why22:31
viric(this hangs the whole system)22:31
viricAny idea, kernel hackers?22:31
GNUtooviric, hi  it's not a kernel problem22:32
GNUtooviric, it's just that all the RAM is used22:32
GNUtooah ok I didn't saw that line:22:32
GNUtoo<viric> it looks like out_of_memory does not success choosing a process to kill... but I don't know why22:32
viricthe OOMK should kill some process22:32
viricbut it does not.22:33
GNUtooyes22:33
GNUtoonanonote?22:33
viricno, sheevaplug. Without swap.22:33
GNUtoook22:33
GNUtoowhat kernel? mainline?22:33
viricthat was 3.2.8 iirc22:33
viricmainline.22:33
GNUtoook22:34
viricBut I see this bug since the 2.6 series22:34
GNUtoook22:34
GNUtoohmmm22:34
viric(the OOMK not playing well)22:34
viricI'm building 3.4 now22:34
GNUtooit's nice to have a mainline kernel22:34
GNUtoowithout the need of any patches22:34
viricsure22:35
viricI should have listed the oomk scores... I think sysrq allows that22:35
viricit would help me a lot a sysrq key that would dump the kernel log ring-buffer *again*22:38
viricOuhm.. I forced a call to oomk by sysrq, and I see I don't have any task with oom points > 0.22:41
viricall are zero or below zero22:41
viricbut oomk can kill some...22:43
--- Sat Jun 9 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!