<kristianpaul>
wolfspraul: I did some test on natural light today, and i was specting more from the sony ccd, i have to increase brightness again, but i was waiting more bright
<kristianpaul>
tests were made in the morning was sunny outside.
<roh>
kristianpaul: are you working on xie?
<roh>
or xue?
<kristianpaul>
what? no
<roh>
too bad ;)
<kristianpaul>
he, i just got some ccd cameras for doing some fun and test
<kristianpaul>
why bad?
<kristianpaul>
is not my topic
<kristianpaul>
ha, i still trying to do something decent with the gps thing, cameras are not my interested now
<kristianpaul>
(that not include the ccd cameras i have)
<kristianpaul>
wich is not *really* related with xue specs. etc..
<roh>
not bad.. i just hoped somebody would
<kristianpaul>
hopefully me too
<kristianpaul>
s/would/still
<roh>
nih. the battery of my camera is nearly dead.. and replacement is crazy expensive
<roh>
atleast the original.. weird.. why should a single lipo cell cost more than 40E?
<kristianpaul>
argg, how i could forgot, now i have two addressed in the same bus.. fixing now and other 40~ minutes of wait.. :/
<kristianpaul>
roh: why not just replace for compatible batteries?
<roh>
well.. there are 3rd party ones.. but the one i already head died almost a year ago
<roh>
and i didnt even use it that much
<roh>
it 'blew up' .. got thicker
<roh>
we'll see..
<kristianpaul>
hopefully my camera have AA baterries and rechargables ones still alive..
<kristianpaul>
<3 his canon camera
<wolfspraul>
kristianpaul: ok, but what's the point/bottom line?
<wolfspraul>
are the sharp or cmos cameras better? Or the sony is still the best, it's just that you are not satisfied with brightness (?)
<wolfspraul>
did you increase brightness to max?
<kristianpaul>
sony still best
<kristianpaul>
max is not very likelly to see
<wolfspraul>
it sounds like more of a problem that is fixable in the software side on m1. when I connected the cameras to a normal TV to test (before buy), they were absolutely bright
<wolfspraul>
ok what is your main point then?
<kristianpaul>
yeah, on my TV was nice indeed, B&W but nice
<kristianpaul>
wolfspraul: just show my complain no more
<wolfspraul>
does it look better on your tv than on the m1?
<wolfspraul>
yes, that part I understood :-) But I wasn't sure what the conclusion/next steps should be.
<wolfspraul>
why is it b&w on your tv?
<kristianpaul>
dunno
<kristianpaul>
tv old?..
<wolfspraul>
does it look better (brighter) on your tv than on the m1?
<kristianpaul>
brighter yes
<wolfspraul>
like I said my feeling is that this is something that could be improved somewhere in software on m1
<kristianpaul>
i trust you
<kristianpaul>
:-)
<wolfspraul>
well, you are testing
<wolfspraul>
I am just guessing from your data...
<kristianpaul>
ah
<kristianpaul>
Sure, it seems software can improve things
<wolfspraul>
but if it looks better on TV than on m1, what's the explanation for that?
<kristianpaul>
hmm well TV may have analog input/processing and not an ADC on the middle?
<kristianpaul>
s/on/in
<wolfspraul>
yes, possible
<wolfspraul>
if it's a really old tv :-)
<kristianpaul>
man i dont even have HDTV here, it is for sure ;-)
<wolfspraul>
ok for now let's focus on two key questions:
<wolfspraul>
1) how do the 3 cameras (cmos, sharp 1/4, sony 1/3) perform compared with each other
<wolfspraul>
2) after we picked the one we like the best, is it a good idea to include it in the m1 package
<kristianpaul>
okay i'll start a wiki page for, i'll try take pictures from what is on the screen
<wolfspraul>
#2 is partially a cost decision, and partially a use-case decision
<kristianpaul>
okay ;) (#2)
<wolfspraul>
I don't even think you should spend that much time on it.
<kristianpaul>
ah ok
<wolfspraul>
your feedback is great, just keep me posted if anything major pops up
<wolfspraul>
I will contact the camera factory next (szoboke.com)
<kristianpaul>
i was doing comparisons on my side, but not documented ALL, just a few random notes ...
<wolfspraul>
they have _A LOT_ of models and I need to understand a bit the various pros and cons
<kristianpaul>
ok
<wolfspraul>
like even for this little square camera you have there, they have 20x20mm, 25x25mm, 30x30mm and 34x34mm
<roh>
that one would be nice to see working on the mm1. sell as a amiga500 replacement ;)
<kristianpaul>
ha, i also missed some bits for the CRS chnages in the cores..
<kristianpaul>
terpstra: hi
<kristianpaul>
terpstra: Are you using gEDA at CERN right?
<kristianpaul>
at least for some projects
<kristianpaul>
haha !
<kristianpaul>
finally, got second serial port working
<kristianpaul>
well at least scope confirm i have the signal after a  mw 0xe0010000 0x56
<kristianpaul>
:D
<kristianpaul>
Now i need organize some patches here
<kristianpaul>
looks at Fallenou
<lekernel>
hi
<lekernel>
kristianpaul: (second uart) good :)
<kristianpaul>
yeah :-)
<kristianpaul>
you have new mail btw
<kristianpaul>
bbl (breakfast)
<Fallenou>
congratz kristianpaul !!
<Fallenou>
you maped the uart to the gpio header pins ?
<kristianpaul>
yes Fallenou
<Fallenou>
ok nice
<kristianpaul>
now rtems
<Fallenou>
I'll have a look at how to integrate a second uart in rtems
<kristianpaul>
looks at Fallenou again
<kristianpaul>
thanks !
<Fallenou>
putting just one is easy
<Fallenou>
but having two
<Fallenou>
I don't even know how we could output to it
<kristianpaul>
i was thiking that
<Fallenou>
since the printf and printk are already mapped to the first one
<kristianpaul>
indeed
<lekernel>
Fallenou: it shouldn't be hard, but please don't commit that to the main branch
<Fallenou>
but I guess looking at the termios code will give us an hint
<Fallenou>
lekernel: sure ;)
<kristianpaul>
hmm i have a fork rtems milkymist branch
<kristianpaul>
maybe i can give you permissions for that
<kristianpaul>
or you can send a patch
<kristianpaul>
like patches
<Fallenou>
I guess you can just copy the console driver directory
<Fallenou>
and change the name of the device to like /dev/console2
<Fallenou>
and some registers addresses obviously
<kristianpaul>
And also xiangfu can learn more abou drives from your mail :-)
<kristianpaul>
Fallenou: that fair i could just use cat and echo i guess
<Fallenou>
kristianpaul: ok I have one way
<Fallenou>
look at the flickernoise main.c
<Fallenou>
like 164
<Fallenou>
you have the console to use, /dev/console
<Fallenou>
just put the other one in it :)
<kristianpaul>
temios is a terminal emulator?
<Fallenou>
yes
<kristianpaul>
so you mean run it like a custom rtem command?
<Fallenou>
you could just start two shells in flickernoise if you want
<kristianpaul>
hmm
<Fallenou>
yes you could do that too
<Fallenou>
or start the other shell at startup
<xiangfu>
164
<kristianpaul>
i prefer use it for debugging (in case i wanted) i just wanna test a 5bits CSR is posible
<xiangfu>
(wrong window)
<kristianpaul>
;)
<Fallenou>
ok well I guess it may work with echo and cat :o
<Fallenou>
but if i does not, just try changing console by console2 in flickernoise
<kristianpaul>
so whats the driver located?
<kristianpaul>
can i add it in flicernoise?
<Fallenou>
as usual c/src/lib/libbsp/lm32/shared/milkymist_console
<kristianpaul>
he, sure i just forgot that patch every time ;_)
<Fallenou>
oh yes I forgot about that
<Fallenou>
you may have to add it to the driver table
<kristianpaul>
i need copy this folder for the new drivr right?
<Fallenou>
yes
<Fallenou>
well I have to go
<Fallenou>
see you and good luck !
<kristianpaul>
bye
<Fallenou>
bybye
<kristianpaul>
lekernel: (please don't commit that to the main branch) i'm also not expecting you acept my patches so thats taken for grant ;-)
<lekernel>
well, I can accept your patches, but the device has little use for a second UART - so I won't merge that particular functionality
<kristianpaul>
ok
<kristianpaul>
btw is soc_architecture.dia okay now?
<lekernel>
it still says microsd, but except that yes
<kristianpaul>
ah sorry !
<kristianpaul>
wait i'll fix and send to list again
<kristianpaul>
xiangfu: If i'm pushing to a github repo, it said all is upto date, but i just did some commits before the push, what could be wrong?
<xiangfu>
kristianpaul: 1. check the 'git branch'Â Â 2. check the commit by 'git log'
<xiangfu>
kristianpaul: you maybe in wrong branch.
<kristianpaul>
is a new brancg
<kristianpaul>
branch*
<kristianpaul>
but i did git remote add foo foo@blblbl.git
<xiangfu>
kristianpaul: have you push the 'new branch' to server?
<kristianpaul>
should i? :p
<kristianpaul>
not xiangfu
<xiangfu>
when you do. 'git push' it will only check the branch that both on server and local
<kristianpaul>
i see
<kristianpaul>
i take for granted it just check the current branch i swiched of
<kristianpaul>
of course i was wrong
<Fallenou>
you can git push origin branchname:branchname
<kristianpaul>
oh ok
<xiangfu>
kristianpaul: where is your second UART codes. I want learn :)
<Fallenou>
will push the local branchname to remote branchname
<kristianpaul>
xiangfu: i'll commit soon :-)
<kristianpaul>
i know what was wrong now with my procedure
<Fallenou>
*away*
<kristianpaul>
xiangfu: last question before the big commit. how i can add automatically severals files that are modified and also i know just correspond  to a single commit?
<xiangfu>
kristianpaul: hmm... git commit -a -m "..." will commit all files that modified.  (maybe I misunderstand you question?)
<kristianpaul>
xiangfu: no is okay :-)
<kristianpaul>
my english not good sometimes :p
<xiangfu>
kristianpaul: do you mean you want merge two commits to one?
<kristianpaul>
xiangfu: no no
<kristianpaul>
xiangfu: just easilly add several files to a commit
<xiangfu>
like you modified 10 files. and you only want commit 5 of them? (sorry I still don't understand what you want)
<kristianpaul>
i modified 10 files and i want commit all of then at same time
<kristianpaul>
commit -a -m "..." right?
<xiangfu>
yes
<xiangfu>
btw. if there is new files. add them first by "git add FILE_NAME"
<xiangfu>
kristianpaul: some question about your UART. 1. have many git repo you need modify. milkymist.git and flickernoise.git is enough? do we need add driver in rtems?(rtems-milkymist.git)
<kristianpaul>
suposelly all commits related to second UART are in the gps-sdr branch
<kristianpaul>
xiangfu: yup new driver is on the way too
<kristianpaul>
xiangfu: but i tested using bios and writing to the corresponding register then reading TX pin with scope to confirm
<kristianpaul>
xiangfu: the driver at least for rtems handle the new UART as  a /dev/console1
<kristianpaul>
dammit, every time i want to compare branches with github my browser get freezed..
<Fallenou>
I must admit I don't understand everything, about the doted line and the wishbone bus
<kristianpaul>
Fallenou: Can you tell me more about your methof for reserving memory about DMA and Minimac Module
<kristianpaul>
dots..
<kristianpaul>
hm
<Fallenou>
there is no special method
<kristianpaul>
what do you do?
<Fallenou>
just make sure the memory area is 4-bytes aligned
<Fallenou>
and it's good for dma
<kristianpaul>
yes
<kristianpaul>
sorry i dont understand memory area is 4-bytes aligned
<Fallenou>
and make sure you invalid the L1 cache before reading a memory area written by DMA
<Fallenou>
kristianpaul: memory address is a multiple of 4
<Fallenou>
aligned to a 32 bits boundary
<kristianpaul>
hmm
<kristianpaul>
(dots) wel may be is not necesary i just wanted to point wich devices have a DMA-like comunication
<kristianpaul>
but i guess DMA label is enought..
<Fallenou>
is there 2 buses ?
<Fallenou>
or just 1 ?
<kristianpaul>
for *me* two
<Fallenou>
oh ok
<kristianpaul>
original combus was a shared wishbone bus
<Fallenou>
ok
<kristianpaul>
but  sebastien did some changes adding a crossbar like stuff there
<kristianpaul>
so at some level you see it like one bus (xbar)
<kristianpaul>
but internally (xbar) is made of two buses is like i see it
<Fallenou>
ooh ok
<Fallenou>
you know more about it than I do
<mwalle>
mh shouldnt there be as much busses as masters inside a crossbar switch?
<Fallenou>
anyway it's good to keep the soc block diagram up to date :)
<mwalle>
or min(master, slaves)
<kristianpaul>
mwalle: good question
<Fallenou>
really don't know about these stuff
<Fallenou>
I should read a little bit about it :)
<Fallenou>
I'm really not familiar with wishbone
<kristianpaul>
oh, thats a big paper
<kristianpaul>
i jus read a bit plus the wikipedia article :p
<lekernel>
mwalle: it's not really a crossbar
<lekernel>
it wouldn't really make sense to expend all the resources needed for a full crossbar, as the vast majority of transfers involve the shared system memory
<kristianpaul>
the Minimac generates an intertupt every time the 4 slots are full or any of then ?
<Fallenou>
any of them
<Fallenou>
any time *one* slot gets full, there is the RX interrupt
<kristianpaul>
now i got  the sense of the word mini
<kristianpaul>
There is way to check stats about cpu interrupts related to minimac driver?
<kristianpaul>
Fallenou: you define the address in each RXÂ Â slot like a driver initialiazation task?
<Fallenou>
I allocate 10 memory areads for receiving packets
<Fallenou>
at initialization I load the 4 first memory into the 4 slots
<kristianpaul>
areads?
<Fallenou>
areas*
<kristianpaul>
addres?
<kristianpaul>
ah
<kristianpaul>
ok
<Fallenou>
and when one of the rx slot gets full
<Fallenou>
I load a new area from the pool
<Fallenou>
when the area gets copied it's put back in the pool
<kristianpaul>
hmm, thats how the new driver works
<kristianpaul>
before there was no pool? or?
<Fallenou>
yes
<kristianpaul>
btw you have to clear the reception slot inst?
<Fallenou>
correct
<Fallenou>
before there was 4 memory areas allocated in total
<Fallenou>
and each memory area was allocated and associated forever to one slot
<Fallenou>
kristianpaul: the reception slot is either in the state "loaded", which means there is a dma address in it, but not data yet, or full which means there is data
<Fallenou>
or "not loaded"
<Fallenou>
which means there is no dma address in it
<Fallenou>
well I hope I don't tell you bullshit, just look at the minimac doc
<Fallenou>
it's really short
<Fallenou>
and easy to understand
<kristianpaul>
yeah looking now, i just wanted to confront it with the driver developer ;-)
<Fallenou>
:)
<Fallenou>
sure
<kristianpaul>
btw
<kristianpaul>
about serial port
<kristianpaul>
Fallenou: uart.h
<Fallenou>
yep
<kristianpaul>
i already add second uart at system_conf.h
<kristianpaul>
also copy new drivr and update to correspond to system_conf.h new values
<kristianpaul>
but uart.h not
<kristianpaul>
also do i need something else to this driver be integrated in rtems?
<kristianpaul>
btw i found the uart.txt file :-)
<kristianpaul>
sadly just that one ;)
<Fallenou>
ahah
<Fallenou>
yes didn't have the time to document more :x
<kristianpaul>
i understand
<kristianpaul>
all i need to care about M1 bsp is at /home/paul/rtems-milkymist/c/src/lib/libbsp/lm32 ?
<kristianpaul>
ignoring my home folders of course
<Fallenou>
yes
<Fallenou>
and more over
<Fallenou>
it's at shared/ and milkymist/
<Fallenou>
and you have several testsuites in rtems-milkymist/testsuites/samples/
<kristianpaul>
do you understand my previous question about uart.h?
<kristianpaul>
(i'm not good to get the right point most of the times..)
<Fallenou>
no I didn't get it sorry
<kristianpaul>
i already copy milkymist_console to milkymist_console1
<kristianpaul>
milkymist_console1 <-Â Â secon uart driver
<kristianpaul>
second*
<kristianpaul>
i updated both console.c and uart.c to match new uart values added in system_conf.h
<Fallenou>
ok
<Fallenou>
seems good for me
<Fallenou>
what about uart.h ?
<kristianpaul>
you tell me :-)
<Fallenou>
well it's just the header
<kristianpaul>
i saw it used for the bsd init
<kristianpaul>
bsp**
<Fallenou>
I guess you can try just including it from console1.c
<Fallenou>
I do'nt think you have to modify what's in it
<kristianpaul>
what about the ifdef?
<Fallenou>
well it makes sure there is no infinite inclusion
<Fallenou>
so if it's not needed, it won't be included
<kristianpaul>
okay i'll let this file unchanged
<kristianpaul>
and no more i need to do?
<kristianpaul>
of course bootstrap this lm32 i guess
<kristianpaul>
and make again in the bsp-milkymist
<kristianpaul>
isnt?
<Fallenou>
you have to add the files in the Makefile.am
<Fallenou>
in lm32/milkymist/Makefile.am
<kristianpaul>
oh ok
<Fallenou>
and I guess you have to add the console driver in the driver array of your application
<Fallenou>
as there is no #define APPLICATION_USE_UART2 in rtems :)
<kristianpaul>
in this case i'll fork from flickernoise
<kristianpaul>
haha ok
<Fallenou>
yep with flickernoise you have an example of adding "custom" drivers
<kristianpaul>
lots of customs :-
<kristianpaul>
)
<kristianpaul>
shell comand too
<Fallenou>
sure ;)
<Fallenou>
yep
<kristianpaul>
realy nice examples there
<Fallenou>
anyway, what you're doing, I've never done it
<Fallenou>
I know a few things about rtems
<Fallenou>
but not all :)
<Fallenou>
so maybe I'm forgetting something
<kristianpaul>
sure you're not Joel :-)
<Fallenou>
yep ;)
<kristianpaul>
I'll ask the list in anycase for recomendations
<Fallenou>
so don't hesitate to ask again and to post errors if it still does not work
<Fallenou>
Not sure if I would be able to help but i will try
<kristianpaul>
termios i dint investigate yet. is included in rtems?
<Fallenou>
hum yes
<Fallenou>
it's in the documentation about how to make a console driver at least :o