| 00:19.48 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 00:23.43 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 01:00.49 | cladamw | wpwrak, good morning ! |
| 01:03.21 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 01:06.55 | cladamw | wpwrak, 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:35.39 | *** join/#qi-hardware marcan (marcan@marcansoft.com) |
| 01:52.45 | *** join/#qi-hardware liuqi (~liuqi@159.226.43.42) |
| 02:00.08 | wpwrak | cladamw: it doesn't work like that. fped itself doesn'tknow anything about densities. you have to express that in your footprint definition. |
| 02:01.12 | wpwrak | here is my current "work in progress" for QFP: http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules/qfp-gen.fpd |
| 02:01.20 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 02:01.44 | wpwrak | as you can see, i have a density table with parameters that change depending on the density |
| 02:10.18 | cladamw | man! are you trying to say that all fpd had better to have such three densities ? |
| 02:12.49 | wpwrak | ;-) you get to choose where you want to have them or not :) |
| 02:16.50 | cladamw | this 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:18.40 | cladamw | no hi-light can be shown. If someone learns this Fped, the code is relatively not to read easily. |
| 02:20.17 | cladamw | he needs very very familiar with this Fped to click to hi-light. :-) |
| 02:22.08 | wpwrak | you'll notice that the latest fped is a little better at highlighting than the old one |
| 02:22.27 | wpwrak | but yes, the structure of these components is not trivial |
| 02:22.48 | wpwrak | of course, already figuring out what IPC-7351 says is quite a pain ... |
| 02:23.11 | *** join/#qi-hardware Openfree` (~Openfreer@116.228.88.131) |
| 02:23.51 | 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:24.20 | wpwrak | (though my footprints should work. when i print them and place a real chip on them, they look quite reasonable) |
| 02:26.32 | cladamw | all *.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:27.31 | wpwrak | oh yes. it's a lot of work |
| 02:27.33 | cladamw | the footprints get met completely with IPC, the samples on hand should quite meet 1:1 scaling paper design work for sure. |
| 02:28.04 | wpwrak | but if we get the hang of it, we can avoid a lot of guesswork in the future |
| 02:29.08 | wpwrak | the 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.14 | cladamw | but 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.45 | wpwrak | with this, some of the IPC-7351 math could be kept in a central location, instead of doing it in each footprint |
| 02:30.07 | wpwrak | but that would need some way to express such things in the gui |
| 02:30.54 | cladamw | agreed, if do so, needs to work out good expression in gui. |
| 02:31.15 | wpwrak | i consider my work on IPC-7351 footprints experimental for now. so yes, no need to rush with copying it :) |
| 02:36.09 | *** join/#qi-hardware rejon_ (~rejon@jp.fabricatorz.com) |
| 03:29.22 | *** join/#qi-hardware gmork_ (~gmork@186.56.187.207) |
| 03:46.24 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 03:58.02 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 03:59.08 | *** join/#qi-hardware heberth (~heberth@190.97.216.127) |
| 03:59.50 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 04:14.30 | *** join/#qi-hardware heberth_ (~heberth@190.97.216.128) |
| 05:05.03 | qi-bot | The build has FAILED: http://fidelio.qi-hardware.com/~xiangfu/building/Nanonote/Ben/openwrt-xburst.full_system-20120607-0926 |
| 05:11.26 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 05:13.25 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 05:21.55 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 05:31.24 | 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/9a717ee |
| 05:54.31 | *** join/#qi-hardware rejon_ (~rejon@jp.fabricatorz.com) |
| 06:00.25 | *** join/#qi-hardware cladamw_ (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 06:21.01 | *** join/#qi-hardware cladamw (~adamwang@host-65.78-43-115.dynamic.totalbb.net.tw) |
| 06:32.54 | *** join/#qi-hardware B_Lizzard (~havoc@athedsl-431541.home.otenet.gr) |
| 06:50.27 | *** join/#qi-hardware larsc (~lars@eisbaer.ursus-maritimus.org) |
| 06:54.23 | *** join/#qi-hardware rejon_ (~rejon@jp.fabricatorz.com) |
| 07:32.22 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 07:45.25 | *** join/#qi-hardware kristoffer (~kristoffe@c-34dae555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 07:51.41 | qi-bot | [commit] Adam Wang: stdpass.fpd: added 1812 size which referred from TycoElectronics (master) http://qi-hw.com/p/kicad-libs/17ae71b |
| 08:55.27 | *** join/#qi-hardware lekernel_ (~lekernel@f052070048.adsl.alicedsl.de) |
| 09:01.24 | *** join/#qi-hardware kuribas (~user@94-227-36-245.access.telenet.be) |
| 09:20.58 | *** join/#qi-hardware uwe__ (~uwe_@dslb-088-064-209-125.pools.arcor-ip.net) |
| 09:22.58 | *** join/#qi-hardware xiangfu (~xiangfu@fidelio.qi-hardware.com) |
| 09:23.48 | qi-bot | [commit] nbd: iproute2: fix build errors with newer versions of eglibc (master) http://qi-hw.com/p/openwrt-xburst/27057b9 |
| 09:23.49 | qi-bot | [commit] nbd: eglibc: use 2.15 by default (master) http://qi-hw.com/p/openwrt-xburst/67b7bdf |
| 09:23.50 | 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/ab865f7 |
| 09:23.52 | qi-bot | [commit] blogic: [tools] fixes python related autokrampf install bug (master) http://qi-hw.com/p/openwrt-xburst/5aab29d |
| 09:23.54 | qi-bot | [commit] nbd: e2fsprogs: add posix_memalign related portability patch from #8508 (master) http://qi-hw.com/p/openwrt-xburst/9c88d96 |
| 09:23.56 | qi-bot | [commit] nbd: include/netfilter.mk: clean up, remove junk for old kernel versions (master) http://qi-hw.com/p/openwrt-xburst/7bd3c3f |
| 09:23.58 | qi-bot | [commit] nbd: xburst: remove an obsolete CompareKernelPatchVer call (master) http://qi-hw.com/p/openwrt-xburst/cc530eb |
| 09:24.01 | 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/a165494 |
| 09:24.03 | qi-bot | [commit] nbd: kernel: add module packages for usbip (from the packages feed) (master) http://qi-hw.com/p/openwrt-xburst/a1b2ddf |
| 09:24.05 | qi-bot | [commit] Mirko Vogt: add <http://downloads.qi-hardware.com/software/mirror-openwrt-sources/> (master) http://qi-hw.com/p/openwrt-xburst/8001e29 |
| 09:24.07 | qi-bot | [commit] Xiangfu Liu: uboot-xburst: update to 2010.06 (master) http://qi-hw.com/p/openwrt-xburst/d1d8084 |
| 09:24.09 | qi-bot | [commit] Xiangfu Liu: uboot-xburst: enable-silent-console.patch (master) http://qi-hw.com/p/openwrt-xburst/ccd9387 |
| 09:24.11 | qi-bot | [commit] Xiangfu Liu: uboot silent console (master) http://qi-hw.com/p/openwrt-xburst/7200ed7 |
| 09:24.13 | qi-bot | [commit] Xiangfu Liu: uboot-xburst: change load kernel size (master) http://qi-hw.com/p/openwrt-xburst/2705c20 |
| 09:24.15 | qi-bot | [commit] Xiangfu: xburst: add WPAN support (master) http://qi-hw.com/p/openwrt-xburst/cfa3816 |
| 09:24.17 | 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/521615a |
| 09:24.19 | qi-bot | [commit] Xiangfu: xburst qi_lb60 disable WPAN kernel options, should build as module (master) http://qi-hw.com/p/openwrt-xburst/fb07ad2 |
| 09:24.21 | qi-bot | [commit] Xiangfu: xburst: add Ben NanoNote kernel logo (master) http://qi-hw.com/p/openwrt-xburst/4e3f88b |
| 09:24.23 | qi-bot | [commit] Xiangfu: xburst: qi_lb60 select the nanonote slash screen (master) http://qi-hw.com/p/openwrt-xburst/cd994e8 |
| 09:24.25 | qi-bot | [commit] Xiangfu: remove xburst target borken (master) http://qi-hw.com/p/openwrt-xburst/d5ee224 |
| 09:58.02 | *** join/#qi-hardware vladkorotnev (~vladkorot@95.105.69.121) |
| 10:02.21 | xiangfu | openwrt-xburst rebased on latest openwrt upstream (Jun 7 svn://svn.openwrt.org/openwrt/trunk@32117) |
| 10:02.32 | xiangfu | now the only diff is uboot and WPAN patches. :-) |
| 10:03.42 | *** join/#qi-hardware panda|x201 (~hzhang@58.83.252.241) |
| 10:04.23 | *** join/#qi-hardware xwalk (~crosswalk@rrcs-98-102-156-195.central.biz.rr.com) |
| 10:12.00 | *** join/#qi-hardware jekhor (~jek@46.216.132.36) |
| 10:26.54 | *** join/#qi-hardware jivs_ (~jivs@nat-sta-slph1.tvu.ac.uk) |
| 10:44.33 | qi-bot | [commit] Xiangfu Liu: uboot-xburst: update to 2010.06 (master) http://qi-hw.com/p/openwrt-xburst/af1689d |
| 10:44.34 | qi-bot | [commit] Xiangfu Liu: uboot-xburst: enable-silent-console.patch (master) http://qi-hw.com/p/openwrt-xburst/fea83e4 |
| 10:44.35 | qi-bot | [commit] Xiangfu Liu: uboot silent console (master) http://qi-hw.com/p/openwrt-xburst/a02cee8 |
| 10:44.37 | qi-bot | [commit] Xiangfu Liu: uboot-xburst: change load kernel size (master) http://qi-hw.com/p/openwrt-xburst/a6bc3df |
| 10:44.39 | qi-bot | [commit] Xiangfu: xburst: add WPAN support (master) http://qi-hw.com/p/openwrt-xburst/b622821 |
| 10:44.41 | 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/2dface3 |
| 10:44.43 | qi-bot | [commit] Xiangfu: xburst qi_lb60 disable WPAN kernel options, should build as module (master) http://qi-hw.com/p/openwrt-xburst/3f28756 |
| 10:44.45 | qi-bot | [commit] Xiangfu: xburst: add Ben NanoNote kernel logo (master) http://qi-hw.com/p/openwrt-xburst/d87ac1f |
| 10:44.47 | qi-bot | [commit] Xiangfu: xburst: qi_lb60 select the nanonote slash screen (master) http://qi-hw.com/p/openwrt-xburst/e3e188c |
| 10:44.49 | qi-bot | [commit] Xiangfu: remove xburst target borken (master) http://qi-hw.com/p/openwrt-xburst/fd4e7e4 |
| 11:18.18 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 11:37.24 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 11:42.54 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 11:55.08 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 11:57.12 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 11:58.00 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 12:00.52 | *** join/#qi-hardware GNUtoo (~gnutoo@host138-148-dynamic.4-87-r.retail.telecomitalia.it) |
| 12:04.26 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 12:13.04 | *** join/#qi-hardware DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:13.53 | *** join/#qi-hardware DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 12:22.04 | *** join/#qi-hardware jekhor (~jek@46.216.231.80) |
| 12:25.46 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 12:27.18 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 12:33.00 | *** join/#qi-hardware phirsch (~phirsch@xdsl-89-0-79-115.netcologne.de) |
| 12:48.47 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 13:02.43 | mth | wolfspraul: is it possible to do something about the crashing web frontend for git? |
| 13:02.58 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 13:03.11 | mth | it makes it difficult to point new people to the sources |
| 13:03.34 | viric | why it crashes? |
| 13:03.57 | mth | dunno, but it ends quickly with a 500 error |
| 13:04.01 | viric | ah |
| 13:04.21 | mth | it is caused by something in the archive, I think, because qi-kernel has the problem and other repositories don't |
| 13:04.39 | viric | aha |
| 13:04.48 | mth | http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/master/ |
| 13:05.01 | viric | is the git web implemented in perl? |
| 13:06.00 | mth | PHP, I think |
| 13:06.45 | viric | oh |
| 13:09.24 | mth | wolfspraul was thinking about replacing it |
| 13:09.43 | mth | but unless that can be done soonish, it might be better to try and fix it |
| 13:10.44 | Aylax | Replacing it by what? |
| 13:11.51 | mth | a different project viewer package |
| 13:11.59 | wolfspraul | mth: oh, hmm |
| 13:12.06 | wolfspraul | I didn't know you were suffering from that |
| 13:12.08 | kristianpaul | cgit :-) |
| 13:12.46 | kristianpaul | replace^ |
| 13:15.14 | *** join/#qi-hardware kyak (~kyak@95-28-9-170.broadband.corbina.ru) |
| 13:15.15 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 13:16.49 | mth | if I can help resolve the issue, let me know |
| 13:23.48 | *** join/#qi-hardware GNUtoo (~gnutoo@host138-148-dynamic.4-87-r.retail.telecomitalia.it) |
| 13:31.09 | *** join/#qi-hardware B_Lizzard (~havoc@athedsl-431541.home.otenet.gr) |
| 13:33.25 | wolfspraul | give me the weekend then we talk |
| 13:38.05 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 13:42.12 | mirko | xiangfu: 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 web |
| 13:42.23 | mirko | use mirko@openwrt.org instead |
| 13:50.38 | *** join/#qi-hardware Aylax- (~Aylax@90.84.144.73) |
| 13:51.11 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 13:55.37 | *** join/#qi-hardware freespace (foobar@stark.pictorii.com) |
| 14:01.41 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 14:22.57 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 14:30.58 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 14:39.18 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 14:52.19 | *** join/#qi-hardware Aylax (~Aylax@90.84.144.73) |
| 14:56.36 | *** join/#qi-hardware Aylax- (~Aylax@90.84.144.228) |
| 15:08.26 | *** join/#qi-hardware pabs3 (~pabs@d175-38-169-112.per801.wa.optusnet.com.au) |
| 15:26.06 | *** join/#qi-hardware kyak (~kyak@unaffiliated/kyak) |
| 15:29.57 | *** join/#qi-hardware jekhor (~jek@134.17.6.250) |
| 15:33.03 | *** join/#qi-hardware B_Lizzard (~havoc@athedsl-431541.home.otenet.gr) |
| 15:35.10 | *** join/#qi-hardware Aylax (~Aylax@90.84.146.252) |
| 15:36.11 | *** join/#qi-hardware jurting (~jommpa90_@host-95-206-2-135.mobileonline.telia.com) |
| 15:43.36 | *** join/#qi-hardware jluis (~jluis@32.Red-79-152-171.dynamicIP.rima-tde.net) |
| 15:47.16 | *** join/#qi-hardware jekhor (~jek@46.216.205.120) |
| 16:17.09 | *** join/#qi-hardware paroneayea (~user@fsf/member/paroneayea) |
| 16:42.48 | *** join/#qi-hardware jekhor (~jek@46.216.145.56) |
| 16:45.03 | *** join/#qi-hardware kuribas (~user@94-227-36-245.access.telenet.be) |
| 18:24.01 | *** join/#qi-hardware rejon_ (~rejon@jp.fabricatorz.com) |
| 18:27.42 | *** join/#qi-hardware xwalk (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 18:35.16 | *** join/#qi-hardware jekhor (~jek@46.53.195.29) |
| 19:03.46 | *** join/#qi-hardware Artyom (~chatzilla@84.23.62.132) |
| 19:05.04 | Artyom | kristianpaul hi |
| 19:08.20 | kristianpaul | Artyom: oh hi |
| 19:11.32 | Artyom | I've added a text file with the license (creative commons share a like) to KiCAD project |
| 19:11.43 | kristianpaul | nice ! |
| 19:12.01 | *** join/#qi-hardware xwalk_ (~crosswalk@d47-69-35-236.try.wideopenwest.com) |
| 19:12.11 | kristianpaul | Artyom: http://projects.qi-hardware.com/schhist/m1-gps-expansion/ |
| 19:12.38 | kristianpaul | is WIP, for now removing uncesary stuff for the board |
| 19:13.20 | Artyom | do you want to use exactly the same scheme? |
| 19:13.20 | kristianpaul | oh you upated to ise 14.1 |
| 19:13.38 | kristianpaul | not at all, but make some clean up and fill the boom |
| 19:14.15 | kristianpaul | not as simple as the maxim evb board, but without fpga and the other mcu |
| 19:14.47 | kristianpaul | oh u are using verilator |
| 19:14.51 | kristianpaul | TNKernel? |
| 19:15.22 | Artyom | Will you keep USB-bridge? (cy7c68013a) |
| 19:15.31 | kristianpaul | nope |
| 19:15.58 | Artyom | only max2769, tcxo and that's all? |
| 19:16.11 | kristianpaul | and power supply yes |
| 19:17.26 | Artyom | I have some ideas about making dual frequency front-end (L1/L2)... What do you think about it? |
| 19:18.09 | kristianpaul | I agree |
| 19:19.12 | kristianpaul | but i'll more focused on the getting a working solution simular to the other comercial receivers |
| 19:19.21 | kristianpaul | and L1 is okay for now (for me) |
| 19:19.46 | Artyom | if you are interested I can prepare a scheme for dual band front-end... |
| 19:19.56 | kristianpaul | hmm |
| 19:20.09 | kristianpaul | using maxin ic? |
| 19:20.39 | kristianpaul | not really interested at all at the moment |
| 19:21.33 | Artyom | I don't have a lot time to make everything, but if you are making a redesign... that would be a step forward... |
| 19:21.58 | kristianpaul | i want cutoff some parts |
| 19:22.03 | kristianpaul | that apply for layout as well |
| 19:22.37 | kristianpaul | not too many drastical changes |
| 19:22.51 | Artyom | TNKernel is open-source RTOS. Not very popular but seems better then freeRTOS for example... |
| 19:23.19 | kristianpaul | but L2C is currently operational? |
| 19:23.59 | kristianpaul | if, then worth that step forward |
| 19:25.17 | Artyom | not sure about gps but there is also glonass that is fully operational in both L1 and L2 ;) |
| 19:25.32 | kristianpaul | he :) |
| 19:28.01 | kristianpaul | did you get Takuji board finally? |
| 19:28.19 | kristianpaul | s/get/got |
| 19:28.20 | qi-bot | kristianpaul meant: "did you got Takuji board finally?" |
| 19:29.20 | kristianpaul | so are you playing back with the cpu + fpga combo? |
| 19:33.16 | *** join/#qi-hardware antgreen (user@nat/redhat/x-uiynpuhoiewffrjz) |
| 19:36.12 | Artyom | I didn't receive Takuji's board :( |
| 19:39.21 | Artyom | Yeah, 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:40.54 | kristianpaul | You could have tried to get a M1 first, more powefull :) |
| 19:41.21 | Artyom | I 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.54 | Artyom | When I'll get any sponsore this will be the first thing to do ;) |
| 19:42.12 | Artyom | (getting M1 ;) ) |
| 19:42.47 | kristianpaul | but the async issue was not the problem made you chosse milkymist soc at first? |
| 19:43.14 | Artyom | I used verilator for verification because icarus-verilof is toooooo sloooowwww for this task... |
| 19:43.22 | kristianpaul | he indeed :) |
| 19:45.13 | Artyom | Yeah, 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:48.28 | Artyom | And 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:50.51 | Artyom | And what about you? Have you received Takuji's board? |
| 19:51.06 | kristianpaul | yup |
| 19:51.19 | kristianpaul | finally |
| 19:51.36 | Artyom | Not long time ago? |
| 19:51.41 | kristianpaul | i think i need make some fix on the board before try |
| 19:51.50 | kristianpaul | yup a month ago |
| 19:51.58 | Artyom | Colombia's post work better then russian one ;) |
| 19:52.33 | kristianpaul | you are big country :) |
| 19:53.08 | kristianpaul | anyway i would choose arm, if this ran linux,so i feel like in home |
| 19:53.24 | Artyom | A little frozen ;) |
| 19:53.45 | Artyom | (country) |
| 19:54.10 | kristianpaul | at 33°C :-| |
| 19:54.49 | lekernel | Artyom: what do you need the rtos for? |
| 19:55.54 | Artyom | Well, the main reason because I wanted to check how to work with RTOS. Then Takuji uses RTOS ;) |
| 19:57.36 | kristianpaul | gpl-gps port is ecos :) |
| 19:57.37 | Artyom | I 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:58.09 | Artyom | which I faced with MM SoC + namuru |
| 19:58.45 | Artyom | yeah, gpl-gps uses ecos but TNKernel seems to be much smaller and easier to understand |
| 19:58.48 | kristianpaul | but wast this a problem because your spartan3 dince sinthesize well a cpu cache or something related? |
| 19:59.09 | kristianpaul | <PROTECTED> |
| 19:59.26 | kristianpaul | but honestly at first look TNKernel dint look very friendly ;) |
| 20:02.12 | Artyom | I 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:04.00 | Artyom | And also cpu without cache is very slow. Ohnestly speaking I don't know exactly what influenced more: uart-core or cpu without cache |
| 20:06.38 | Artyom | Anyway 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:09.55 | Artyom | Yes, 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:11.35 | Artyom | But I don't exclude possibility to switch to some other RTOS like freeRTOS... |
| 20:12.31 | Artyom | if strong reasons will appear... |
| 20:12.52 | lekernel | uart core is very slow? wtf? |
| 20:12.59 | kristianpaul | *g* |
| 20:13.18 | lekernel | it's not slower than any other. 115200 is the maximum rs232 bitrate. |
| 20:14.17 | lekernel | and yes, a cpu executing from dram or flash without cache is slow. so use sram or just enable the damn cache. |
| 20:15.48 | Artyom | comparing 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:17.08 | lekernel | if you can't write those ~100 lines of C code or just copy mine, I'm afraid you'll have difficulty writing a GPS stack |
| 20:17.47 | lekernel | or add the same buffer in verilog, it's really not that difficult |
| 20:19.44 | kristianpaul | start to make other things, you mean multiple threads support? no just a single thread, right? |
| 20:22.08 | 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:23.21 | kristianpaul | i had some issues recently building rtems latelly |
| 20:23.33 | kristianpaul | reported on #milkymist actually :) |
| 20:23.59 | kristianpaul | but indeed, Artyom rtems is not that hard to use |
| 20:24.16 | kristianpaul | and there are plently example by checking flickernoise source code |
| 20:25.21 | kristianpaul | Artyom: perhaps you could get a M1 cheaper by just adquiring the board |
| 20:25.31 | kristianpaul | like the early development kit i got |
| 20:25.43 | kristianpaul | Artyom: just ask wolfspraul about that options |
| 20:28.43 | Artyom | lekernel: 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.45 | 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:30.50 | lekernel | tnkernel has an unfair advantage here: I have never touched it |
| 20:32.07 | lekernel | and to use the uart with rtems just call printf(). how hard is that? |
| 20:32.41 | Artyom | That 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:33.13 | lekernel | electronics forums are full of crap |
| 20:33.49 | Artyom | agree - What would you do o my place? |
| 20:36.01 | lekernel | first choose if you want to use ARM or not |
| 20:40.03 | lekernel | most people in electronics forums know only about microcontrollers - if you already have a fpga in your system, you probably don't need one |
| 20:40.43 | Artyom | Among 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:41.46 | kristianpaul | porting take time, consider that.. |
| 20:41.57 | lekernel | and I guess you are running Windows, considering it's the most popular OS? |
| 20:42.32 | Artyom | Lekernel: 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:44.01 | Artyom | If 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:48.42 | Artyom | lekernel: 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:51.07 | Artyom | lekernel: 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:52.12 | kristianpaul | we dont need more people been scared for/from any reason :-) |
| 20:55.00 | Artyom | My friend was very surprised that during traineeship in german university had to work only with PCs under Linux... |
| 20:56.42 | kristianpaul | then you just said namuru and milkymist and they got hurt attack ;-) |
| 20:57.59 | Artyom | 1 person from 100 ;) |
| 20:58.56 | Artyom | gentelmen, sorry that I have dissapointed you with some of my thoughts. And it's time to sleep for me. bye. |
| 20:59.09 | kristianpaul | i'm not dissapointed |
| 20:59.15 | kristianpaul | .. |
| 21:22.50 | *** join/#qi-hardware falstaph (~william@c-98-246-103-214.hsd1.or.comcast.net) |
| 21:39.08 | *** join/#qi-hardware jluis (~jluis@32.Red-79-152-171.dynamicIP.rima-tde.net) |
| 22:04.15 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 22:21.24 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 22:23.51 | *** join/#qi-hardware emeb1 (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 22:24.41 | *** join/#qi-hardware emeb1 (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 22:25.30 | *** join/#qi-hardware viric (~viric@unaffiliated/viric) |
| 22:26.46 | *** join/#qi-hardware emeb (~ericb@ip72-223-81-94.ph.ph.cox.net) |
| 22:29.17 | viric | mth: I had a hang in the sheevaeplug again... |
| 22:30.06 | *** join/#qi-hardware lekernel_ (~lekernel@f052070048.adsl.alicedsl.de) |
| 22:30.12 | *** join/#qi-hardware mth_ (rfhswnsf@dhcp-089-098-069-120.chello.nl) |
| 22:30.22 | *** join/#qi-hardware urandom__ (~user@p54B0EFD3.dip.t-dialin.net) |
| 22:31.15 | viric | the relevant part is: |
| 22:31.16 | viric | [<c0008d94>] (__irq_svc+0x34/0x98) from [<c006a0a4>] (out_of_memory+0x12c/0x354) |
| 22:31.19 | viric | [<c006a0a4>] (out_of_memory+0x12c/0x354) from [<c006d2f8>] (__alloc_pages_nodemask+0x5e4/0x60c) |
| 22:31.22 | viric | [<c006d2f8>] (__alloc_pages_nodemask+0x5e4/0x60c) from [<c0068be4>] (filemap_fault+0x1e0/0x4b0) |
| 22:31.25 | viric | [<c0068be4>] (filemap_fault+0x1e0/0x4b0) from [<c007e3dc>] (__do_fault+0x68/0x4b4) |
| 22:31.36 | viric | it looks like out_of_memory does not success choosing a process to kill... but I don't know why |
| 22:31.40 | viric | (this hangs the whole system) |
| 22:31.45 | viric | Any idea, kernel hackers? |
| 22:32.08 | GNUtoo | viric, hi it's not a kernel problem |
| 22:32.22 | GNUtoo | viric, it's just that all the RAM is used |
| 22:32.41 | GNUtoo | ah ok I didn't saw that line: |
| 22:32.45 | GNUtoo | <viric> it looks like out_of_memory does not success choosing a process to kill... but I don't know why |
| 22:32.55 | viric | the OOMK should kill some process |
| 22:33.00 | viric | but it does not. |
| 22:33.01 | GNUtoo | yes |
| 22:33.07 | GNUtoo | nanonote? |
| 22:33.19 | viric | no, sheevaplug. Without swap. |
| 22:33.31 | GNUtoo | ok |
| 22:33.44 | GNUtoo | what kernel? mainline? |
| 22:33.56 | viric | that was 3.2.8 iirc |
| 22:33.59 | viric | mainline. |
| 22:34.05 | GNUtoo | ok |
| 22:34.09 | viric | But I see this bug since the 2.6 series |
| 22:34.13 | GNUtoo | ok |
| 22:34.16 | GNUtoo | hmmm |
| 22:34.21 | viric | (the OOMK not playing well) |
| 22:34.35 | viric | I'm building 3.4 now |
| 22:34.44 | GNUtoo | it's nice to have a mainline kernel |
| 22:34.50 | GNUtoo | without the need of any patches |
| 22:35.09 | viric | sure |
| 22:35.54 | viric | I should have listed the oomk scores... I think sysrq allows that |
| 22:38.28 | viric | it would help me a lot a sysrq key that would dump the kernel log ring-buffer *again* |
| 22:41.44 | viric | Ouhm.. I forced a call to oomk by sysrq, and I see I don't have any task with oom points > 0. |
| 22:41.49 | viric | all are zero or below zero |
| 22:42.32 | *** join/#qi-hardware wpwrak (~werner@234-171-231-201.fibertel.com.ar) |
| 22:43.19 | viric | but oomk can kill some... |
| 22:52.24 | *** join/#qi-hardware hozer (~hozer@excalibur.hozed.org) |