<kyak>
xiangfu: hi! is there a final solution for that libiconv-full and gettext-full problem?
<xiangfu>
kyak: so far , no :( . my idea is wait Upstream a little.
<xiangfu>
kyak: by the way. I think we only build the SDK. I have remove the Imagebuilder and Toolchian in config.full_system.
<xiangfu>
kyak: I have try the SDK a little. seems it's easy develop package. in sdk.
<xiangfu>
kyak: there are so many packages in my TODO list. :)Â Â I need ask in mailing list for help.
<xiangfu>
kyak: but first. I will write a manual about how to develop package in SDK. I think I will finish that today.
<kyak>
yes, this sounds great
<kyak>
xiangfu: is there a bug report for *-full?
<xiangfu>
kyak: only me report me. :)
<xiangfu>
only me report one.
<kyak>
do you expect to get it fixed soon?
<kyak>
*do you expect it will be fixed soon?
<xiangfu>
kyak: I don't think so. but I want know their plan on this *-full. I mean what about other packages. who will test or they just wait for report package.
<xiangfu>
*report package error
<kyak>
i have a feeling they won't change anything
<xiangfu>
kyak:Â Â oh..
<kyak>
maybe we will have to override libiconv and gettext from openwrt-packages
<xiangfu>
kyak: another thing. for fix our problem. I upload the feeds.conf to the "image files" :
<kristianpaul>
argg no i changed the case stament by to if and still same..
<kristianpaul>
s/to/two
<kristianpaul>
why so muchs 0s between data..
<wpwrak_>
weak signal ?
<kristianpaul>
i'm about to find it, i'll dump data without wait for sync
<kristianpaul>
weak i hope not, i already tested edge of signals (clk  and sync from SiGE) on the fpga with a counter and worked fine
<wpwrak_>
i mean a weak analog signal.
<kristianpaul>
froma atenna?
<wpwrak_>
well, GPS analog signal, to be precise
<wpwrak_>
yes
<wpwrak_>
weak signal -> lots of zeroes :-)
<kristianpaul>
well i already tested my atenna with my closed source GPS and worked well (this was some weeks ago tought)
<kristianpaul>
the atenna is not on the roof but in  the window should be okay
<wpwrak_>
by the way, how much is "so much 0s" ? 99% of all bits ? 100% ? ...
<kristianpaul>
in a 10Mb samples every ~12 Bytes
<kristianpaul>
i dont have the method to get the % now
<wpwrak_>
a non-zero value every ~12 bytes ?
<kristianpaul>
yes
<kristianpaul>
the ~ scare me more ;)
<wpwrak_>
doesn't sound too horrible. something you could try: connect the FPGA inputs (for signals from the RF chip) to GPIOs of the SIE, and generate a test pattern by software. then see if it is received correctly.
<kristianpaul>
i did that before !!
<kristianpaul>
and works like a charm..
<wpwrak_>
why would the ~ be scary ? if you're receiving a real signal, you can expect some variation
<kristianpaul>
well may be i need a bigger test patterm
<wpwrak_>
(test) great !
<kristianpaul>
(scary) yes but... data is supposed to be synced
<wpwrak_>
synced with what ?
<kristianpaul>
SiGE sync/2
<kristianpaul>
every 8 bits of data there is a 1 bit sync signal
<kristianpaul>
in other registers
<kristianpaul>
(s) < ignore
<wpwrak_>
and that doesn't appear either ?
<kristianpaul>
i dint measure that yet, in a proper way
<kristianpaul>
wait a min
<kristianpaul>
i'll check that i was doing it but i swiched to something else (data dump) dont remenber why now
<kristianpaul>
Any recomedantion for a good hexeditor?
<kristianpaul>
able to highliht patterns given in binary or hex?
<larsc>
hd
<kristianpaul>
link?
<kristianpaul>
i founded but hdx. is that the same?
<kristianpaul>
wpwrak_: (sync) well i think i'm missing something when reading this registers, or may be the verilog module, cause i'm getting the sync bit, but in a not very good looking pattern..
<kristianpaul>
ah hexdump is better selfexplain ;-)
<Jay7>
kristianpaul: okteta :)
<Jay7>
(kde)
<Jay7>
or biew (console)
<wolfspraul>
wpwrak_: no worry about speed of kicad testing, take your time. the one thing that would help me is that you green-light the overall direction, and that we merge my patches and yours into one location, I suggest eda-tools, and that you are OK with me committing there directly.
<wolfspraul>
but I will wait (and again, zero urgency), so that we avoid scattering multiple patchsets around, that's the only reason why I don't move forward right now...
<Jay7>
like spanish language.. one time I'll learn it :)
<wpwrak_>
wolfspraul: i don't think there is much risk of causing confusions. and eventually such things should migrate from openmoko.org anyway
<wolfspraul>
yes but I don't want to trample over your sources :-)
<wolfspraul>
so since the next step would be to merge your --plot patch into something bigger (in eeschema), I wait a bit...
<wpwrak_>
naw, feel free :) your C++ is probably lots cleaner than my feeble attempts anyway :)
<wolfspraul>
alright then. I still wait a bit see whether the pcbnew stuff works for you. after that, we move kicad-patches to eda-tools, and I clean up my stuff a bit more, and add more options to eeschema.
<wolfspraul>
also, you will see in the pcbnew options that the structure of the options is still in flux. I expect KiCad to evolve as well.
<wolfspraul>
for example hpgl, postscript, gerber and dxf are in one dialog, and svg is in another.
<wolfspraul>
doesn't make real sense
<wolfspraul>
some dialogs are very big, and if you change the plot type, you will see some dialog controls getting enabled/disabled because they don't apply to that type.
<wolfspraul>
and so on
<wolfspraul>
then, we may want more options on the command line, that depends on your input too
<wpwrak_>
yeah. i also wonder if one of the two BOM outputs is preferred over the other
<wolfspraul>
there are _many_ options in the dialogs that you cannot control from the command line right now.
<wolfspraul>
adding them is easy though, the biggest part is to understand what we need and evolve the command line options in such a way that we don't always break backwards compatibility with Makefiles we already have.
<wpwrak_>
yup. stability is nice to have :)
<wolfspraul>
for bom formats, they draw from different base files, .sch or .brd
<wolfspraul>
and as you know in eeschema or pcbnew, there is pretty much no knowledge of the 'other' side
<wolfspraul>
so the bom of eeschema and pcbnew may diverge
<wolfspraul>
I think for something like boom, it doesn't matter which one it takes
<wolfspraul>
what we can do on the server is to do automated consistency checks between the two boms
<wolfspraul>
together with automatically generating erc and drc reports, and many other useful automated tasks
<wolfspraul>
but let's first stabilize the whole cmdline thing
<wolfspraul>
then get it deployed on the server (upon commits)
<wolfspraul>
and then think what additional value we can extract from the generated files
<wolfspraul>
in parallel (client side), you will hopefully be able to Makefilize your entire cam workflow...
<wpwrak_>
(bom) hmm, not sure if it's so easy for them to diverge. eeschema does seem to pass all the bom information along.
<wpwrak_>
(makefilize) yup, that's the plan
<wolfspraul>
wpwrak_: oh it's very easy for them to diverge. Someone just edits the schematics :-)
<wolfspraul>
one thing I could see at some point in the future is a small consistency check script we could run on the server. but that's so many steps out now, don't know when it would be the top of the priority list...
<wpwrak_>
wolfspraul: (edit schematics) okay, but when you then export the netlist and import it in pcbnew, the changes should propagate
<wolfspraul>
yes, 'when', or 'if'? :-)
<wpwrak_>
a check that .sch < .cmp, .net < .brd would indeed be useful
<wpwrak_>
i think we had such stale netlists already :)
<kristianpaul>
If FPGA in SIE shares IO with (SDRAM,
<kristianpaul>
Who manage or keep acess timing to both devices..
<kristianpaul>
Is funny but i'm reading fpga like a sram to then load this data on SDRAM.. so, i guess i'll fight agains latency or bus priority somehow at the end.
<kristianpaul>
read Ingenic datasheet again
<LunaVorax>
Hi everyone !
<kristianpaul>
hmm i need a buffer
<kristianpaul>
LunaVorax: hola :)
<LunaVorax>
Is qi-hw planning to make an ARM based device ?
<kristianpaul>
ergg no
<kristianpaul>
milkymist CPU based for sure i think :-)
<kristianpaul>
oh Burst ROM
<kristianpaul>
looks interesting aprouch for my current needs