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
xwalk has joined #qi-hardware
cladamw has joined #qi-hardware
rejon has quit [Ping timeout: 248 seconds]
<cladamw>
wpwrak, good morning !
xiangfu has joined #qi-hardware
emeb has quit [Quit: Leaving.]
<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 ?
marcan has quit [Read error: Operation timed out]
marcan has joined #qi-hardware
wej has quit [Ping timeout: 272 seconds]
liuqi has joined #qi-hardware
xiangfu has quit [Remote host closed the connection]
<wpwrak>
cladamw: it doesn't work like that. fped itself doesn'tknow anything about densities. you have to express that in your footprint definition.
<wpwrak>
as you can see, i have a density table with parameters that change depending on the density
liuqi_ has quit [Quit: leaving]
<cladamw>
man! are you trying to say that all fpd had better to have such three densities ?
<wpwrak>
;-) you get to choose where you want to have them or not :)
<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. :-)
<cladamw>
no hi-light can be shown. If someone learns this Fped, the code is relatively not to read easily.
<cladamw>
he needs very very familiar with this Fped to click to hi-light. :-)
<wpwrak>
you'll notice that the latest fped is a little better at highlighting than the old one
<wpwrak>
but yes, the structure of these components is not trivial
<wpwrak>
of course, already figuring out what IPC-7351 says is quite a pain ...
Openfree` has quit [Remote host closed the connection]
Openfree` has joined #qi-hardware
<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)
<wpwrak>
(though my footprints should work. when i print them and place a real chip on them, they look quite reasonable)
<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.
<wpwrak>
oh yes. it's a lot of work
<cladamw>
the footprints get met completely with IPC, the samples on hand should quite meet 1:1 scaling paper design work for sure.
<wpwrak>
but if we get the hang of it, we can avoid a lot of guesswork in the future
<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.
<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.
<wpwrak>
with this, some of the IPC-7351 math could be kept in a central location, instead of doing it in each footprint
<wpwrak>
but that would need some way to express such things in the gui
<cladamw>
agreed, if do so, needs to work out good expression in gui.
<wpwrak>
i consider my work on IPC-7351 footprints experimental for now. so yes, no need to rush with copying it :)
<mth>
but unless that can be done soonish, it might be better to try and fix it
<Aylax>
Replacing it by what?
<mth>
a different project viewer package
<wolfspraul>
mth: oh, hmm
<wolfspraul>
I didn't know you were suffering from that
kyak has quit [Read error: Operation timed out]
<kristianpaul>
cgit :-)
<kristianpaul>
replace^
kyak has joined #qi-hardware
kyak has quit [Changing host]
kyak has joined #qi-hardware
paroneayea has quit [Read error: Connection reset by peer]
<mth>
if I can help resolve the issue, let me know
GNUtoo has joined #qi-hardware
B_Lizzard has joined #qi-hardware
<wolfspraul>
give me the weekend then we talk
Aylax has quit [Quit: Bye]
Aylax has joined #qi-hardware
<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
<mirko>
use mirko@openwrt.org instead
Aylax has quit [Quit: Bye]
Aylax- has joined #qi-hardware
Aylax- has quit [Client Quit]
Aylax has joined #qi-hardware
freespace has quit [Ping timeout: 244 seconds]
Aylax has quit [Client Quit]
freespace has joined #qi-hardware
jurting has quit [Ping timeout: 260 seconds]
xiangfu has quit [Ping timeout: 246 seconds]
Aylax has joined #qi-hardware
Aylax has quit [Quit: Bye]
Aylax has joined #qi-hardware
B_Lizzard has quit [Remote host closed the connection]
Aylax has quit [Quit: Bye]
Aylax has joined #qi-hardware
Aylax has quit [Quit: Bye]
Aylax has joined #qi-hardware
Aylax has quit [Quit: Bye]
pabs3 has quit [Remote host closed the connection]
uwe__ is now known as uwe_
Aylax has joined #qi-hardware
Aylax- has joined #qi-hardware
Aylax has quit [Ping timeout: 245 seconds]
pabs3 has joined #qi-hardware
Aylax- has quit [Quit: Bye]
kyak has quit [Ping timeout: 245 seconds]
kyak has joined #qi-hardware
jekhor has joined #qi-hardware
B_Lizzard has joined #qi-hardware
jekhor has quit [Ping timeout: 240 seconds]
Aylax has joined #qi-hardware
jurting has joined #qi-hardware
jivs_ has quit [Quit: Leaving]
jluis has joined #qi-hardware
jekhor has joined #qi-hardware
jluis has quit [Remote host closed the connection]
paroneayea has joined #qi-hardware
jekhor has quit [Ping timeout: 245 seconds]
jekhor has joined #qi-hardware
kuribas has joined #qi-hardware
kuribas has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
jekhor has quit [Ping timeout: 245 seconds]
rejon_ has joined #qi-hardware
xwalk has joined #qi-hardware
jekhor has joined #qi-hardware
gmork_ has quit [Quit: Leaving]
Artyom has joined #qi-hardware
<Artyom>
kristianpaul hi
<kristianpaul>
Artyom: oh hi
<Artyom>
I've added a text file with the license (creative commons share a like) to KiCAD project
<kristianpaul>
is WIP, for now removing uncesary stuff for the board
<Artyom>
do you want to use exactly the same scheme?
<kristianpaul>
oh you upated to ise 14.1
<kristianpaul>
not at all, but make some clean up and fill the boom
<kristianpaul>
not as simple as the maxim evb board, but without fpga and the other mcu
<kristianpaul>
oh u are using verilator
<kristianpaul>
TNKernel?
<Artyom>
Will you keep USB-bridge? (cy7c68013a)
<kristianpaul>
nope
<Artyom>
only max2769, tcxo and that's all?
<kristianpaul>
and power supply yes
<Artyom>
I have some ideas about making dual frequency front-end (L1/L2)... What do you think about it?
<kristianpaul>
I agree
<kristianpaul>
but i'll more focused on the getting a working solution simular to the other comercial receivers
<kristianpaul>
and L1 is okay for now (for me)
<Artyom>
if you are interested I can prepare a scheme for dual band front-end...
<kristianpaul>
hmm
<kristianpaul>
using maxin ic?
<kristianpaul>
not really interested at all at the moment
<Artyom>
I don't have a lot time to make everything, but if you are making a redesign... that would be a step forward...
<kristianpaul>
i want cutoff some parts
<kristianpaul>
that apply for layout as well
<kristianpaul>
not too many drastical changes
<Artyom>
TNKernel is open-source RTOS. Not very popular but seems better then freeRTOS for example...
<kristianpaul>
but L2C is currently operational?
<kristianpaul>
if, then worth that step forward
<Artyom>
not sure about gps but there is also glonass that is fully operational in both L1 and L2 ;)
<kristianpaul>
he :)
<kristianpaul>
did you get Takuji board finally?
<kristianpaul>
s/get/got
<qi-bot>
kristianpaul meant: "did you got Takuji board finally?"
<kristianpaul>
so are you playing back with the cpu + fpga combo?
antgreen has joined #qi-hardware
<Artyom>
I didn't receive Takuji's board :(
<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...
rejon_ has quit [Ping timeout: 265 seconds]
<kristianpaul>
You could have tried to get a M1 first, more powefull :)
<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...
<Artyom>
When I'll get any sponsore this will be the first thing to do ;)
<Artyom>
(getting M1 ;) )
<kristianpaul>
but the async issue was not the problem made you chosse milkymist soc at first?
<Artyom>
I used verilator for verification because icarus-verilof is toooooo sloooowwww for this task...
<kristianpaul>
he indeed :)
<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...
<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)
<Artyom>
And what about you? Have you received Takuji's board?
<kristianpaul>
yup
<kristianpaul>
finally
<Artyom>
Not long time ago?
<kristianpaul>
i think i need make some fix on the board before try
<kristianpaul>
yup a month ago
<Artyom>
Colombia's post work better then russian one ;)
<kristianpaul>
you are big country :)
<kristianpaul>
anyway i would choose arm, if this ran linux,so i feel like in home
<Artyom>
A little frozen ;)
<Artyom>
(country)
* kristianpaul
at 33°C :-|
<lekernel>
Artyom: what do you need the rtos for?
<Artyom>
Well, the main reason because I wanted to check how to work with RTOS. Then Takuji uses RTOS ;)
<kristianpaul>
gpl-gps port is ecos :)
<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).
<Artyom>
which I faced with MM SoC + namuru
<Artyom>
yeah, gpl-gps uses ecos but TNKernel seems to be much smaller and easier to understand
<kristianpaul>
but wast this a problem because your spartan3 dince sinthesize well a cpu cache or something related?
<kristianpaul>
easier to understand, is valid
<kristianpaul>
but honestly at first look TNKernel dint look very friendly ;)
<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 ;)
<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
<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...
antgreen has quit [Read error: Connection reset by peer]
<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 )
<Artyom>
But I don't exclude possibility to switch to some other RTOS like freeRTOS...
<Artyom>
if strong reasons will appear...
<lekernel>
uart core is very slow? wtf?
<kristianpaul>
*g*
<lekernel>
it's not slower than any other. 115200 is the maximum rs232 bitrate.
<lekernel>
and yes, a cpu executing from dram or flash without cache is slow. so use sram or just enable the damn cache.
<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.
<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
<lekernel>
or add the same buffer in verilog, it's really not that difficult
<kristianpaul>
start to make other things, you mean multiple threads support? no just a single thread, right?
<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.
<kristianpaul>
i had some issues recently building rtems latelly
<kristianpaul>
reported on #milkymist actually :)
<kristianpaul>
but indeed, Artyom rtems is not that hard to use
<kristianpaul>
and there are plently example by checking flickernoise source code
<kristianpaul>
Artyom: perhaps you could get a M1 cheaper by just adquiring the board
<kristianpaul>
like the early development kit i got
<kristianpaul>
Artyom: just ask wolfspraul about that options
<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...
<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)
<lekernel>
tnkernel has an unfair advantage here: I have never touched it
<lekernel>
and to use the uart with rtems just call printf(). how hard is that?
<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.
<lekernel>
electronics forums are full of crap
<Artyom>
agree - What would you do o my place?
<lekernel>
first choose if you want to use ARM or not
<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
<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...
<kristianpaul>
porting take time, consider that..
<lekernel>
and I guess you are running Windows, considering it's the most popular OS?
<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...
<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)
<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.
<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"...
<kristianpaul>
we dont need more people been scared for/from any reason :-)
<Artyom>
My friend was very surprised that during traineeship in german university had to work only with PCs under Linux...
<kristianpaul>
then you just said namuru and milkymist and they got hurt attack ;-)
<Artyom>
1 person from 100 ;)
<Artyom>
gentelmen, sorry that I have dissapointed you with some of my thoughts. And it's time to sleep for me. bye.
<kristianpaul>
i'm not dissapointed
Artyom has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725]]
<kristianpaul>
..
falstaph has joined #qi-hardware
falstaph has quit [Quit: Leaving]
jekhor has quit [Ping timeout: 252 seconds]
jluis has joined #qi-hardware
viric has quit [Ping timeout: 240 seconds]
emeb has joined #qi-hardware
emeb has quit [Quit: Leaving.]
emeb has joined #qi-hardware
emeb1 has joined #qi-hardware
emeb1 has quit [Client Quit]
emeb1 has joined #qi-hardware
viric has joined #qi-hardware
emeb has quit [Ping timeout: 245 seconds]
emeb1 has quit [Read error: Connection reset by peer]
emeb has joined #qi-hardware
emeb has quit [Client Quit]
<viric>
mth: I had a hang in the sheevaeplug again...
lekernel_ has joined #qi-hardware
mth_ has joined #qi-hardware
urandom__ has joined #qi-hardware
kristoffer has quit [Quit: Leaving]
<viric>
the relevant part is:
<viric>
[<c0008d94>] (__irq_svc+0x34/0x98) from [<c006a0a4>] (out_of_memory+0x12c/0x354)
<viric>
[<c006a0a4>] (out_of_memory+0x12c/0x354) from [<c006d2f8>] (__alloc_pages_nodemask+0x5e4/0x60c)
<viric>
[<c006d2f8>] (__alloc_pages_nodemask+0x5e4/0x60c) from [<c0068be4>] (filemap_fault+0x1e0/0x4b0)
<viric>
[<c0068be4>] (filemap_fault+0x1e0/0x4b0) from [<c007e3dc>] (__do_fault+0x68/0x4b4)
<viric>
it looks like out_of_memory does not success choosing a process to kill... but I don't know why
<viric>
(this hangs the whole system)
<viric>
Any idea, kernel hackers?
<GNUtoo>
viric, hi it's not a kernel problem
<GNUtoo>
viric, it's just that all the RAM is used
<GNUtoo>
ah ok I didn't saw that line:
<GNUtoo>
<viric> it looks like out_of_memory does not success choosing a process to kill... but I don't know why
<viric>
the OOMK should kill some process
<viric>
but it does not.
<GNUtoo>
yes
<GNUtoo>
nanonote?
<viric>
no, sheevaplug. Without swap.
<GNUtoo>
ok
<GNUtoo>
what kernel? mainline?
<viric>
that was 3.2.8 iirc
<viric>
mainline.
<GNUtoo>
ok
<viric>
But I see this bug since the 2.6 series
<GNUtoo>
ok
<GNUtoo>
hmmm
<viric>
(the OOMK not playing well)
<viric>
I'm building 3.4 now
<GNUtoo>
it's nice to have a mainline kernel
<GNUtoo>
without the need of any patches
<viric>
sure
<viric>
I should have listed the oomk scores... I think sysrq allows that
lekernel has quit [*.net *.split]
wpwrak has quit [*.net *.split]
hozer has quit [*.net *.split]
mth has quit [*.net *.split]
<viric>
it would help me a lot a sysrq key that would dump the kernel log ring-buffer *again*
<viric>
Ouhm.. I forced a call to oomk by sysrq, and I see I don't have any task with oom points > 0.
<viric>
all are zero or below zero
wpwrak has joined #qi-hardware
<viric>
but oomk can kill some...
B_Lizzard has quit [Remote host closed the connection]