<qi-bot>
[commit] Werner Almesberger: When leveling, the center circle is now shown when the pointer approaches it. http://qi-hw.com/p/ben-scans/edb12b6
<tuxbrain_away>
wpwrak: I'm interpreting right the commits if I suppose you are  in the way of generate the full 3d mesh of NN?
<wpwrak>
tuxbrain_away: well, of the parts. since there doesn't seem to be anything that's useful for doing it, i'm hacking my own part combiner.
<wpwrak>
tuxbrain_away: it's easy to try. just check it out, make, then mkdir .cache; make run
<wpwrak>
tuxbrain_away: you'll get the top face and on the side three buttons. you can orient the top face with the scroll wheel. the goal is to have as much blue as possible.
<tuxbrain>
wants to be like you when I grow up
<wpwrak>
tuxbrain_away: then click on B and do the same with the bottom face. finally, click on A+B and make them overlap by shifting (scroll wheel inside the circle) or rotating (scroll wheel outside the circle)
<wpwrak>
tuxbrain: then press Q to exit. after that, make pov to render the scene in POV-Ray. lots of things don't quite work the way they should. e.g., the coordinate transforms in A+B aren't completely correct (the Z correction is missing) and the way user input gets applied is a bit counter-intuitive.
<wpwrak>
tuxbrain: the pov-ray stuff is worse. right now, i just dump the data without actually aligning, scaling, etc., anything. so the result just tells me that i got the height field right, but the rest is a big no-op
<tuxbrain>
cloning git
<wpwrak>
tuxbrain: the trick is to never grow up ;-)
<wpwrak>
hmm, if there's a way to clone only a subset of a git, that may be useful. else, you'll also clone all the 3D scans. they're biggish.
<tuxbrain>
about 250Mb of data... wow all is 3d info?
<wpwrak>
yup
<wpwrak>
lots of data and a tiny bit of code :)
<tuxbrain>
in which dir is the makefile?
<wpwrak>
in solidify/
<tuxbrain>
making
<wpwrak>
you have a very quick connection :)
<tuxbrain>
heheehh
<tuxbrain>
just downloaded at 1'6Mb :P
<tuxbrain>
hey I have an colorized thing in the screen cool!!!
<wpwrak>
when you move the mouse around, you'll see a yellow circle
<tuxbrain>
yes
<wpwrak>
mouse wheel inside the circle raises or lowers the z0 plane. where the plane intersects with the scan, you have blue color. anything below z0 is red. anything above green.
<wpwrak>
the steps at z0+1 and z0-1 are darker green and darker red, to make it easier to see where the plane goes.
<wpwrak>
mouse wheel outside the circle tilts the z0 plane.
<wpwrak>
the goal is to have as much blue as possible
<wpwrak>
"A" is difficult, because the piece seems to be a bit uneven. "B" is easier.
<wpwrak>
then, at A+B, you can rotate (mouse wheel outside the circle) and shift (mouse wheel inside the circle, in one of the four quadrants shown)
<tuxbrain>
man this is impresive
<wpwrak>
i'll have to add some more visual aids in A and B. it's too easy to get lost there.
<tuxbrain>
I barelly understand a fuck, but is like having a magnetic resonance  on NN
<wpwrak>
yeah, looks like x-ray images ;-)
<tuxbrain>
oh it doesn't scale full screen :P
<wpwrak>
naw, it uses the size of the scan :) each pixel is a scan point
<tuxbrain>
now I can read wpwrak thoughts from here... (damn lusers...)
<wpwrak>
;-))
<tuxbrain>
wpwrak: make sense :)
<kristianpaul>
SiENcE: jlime is great i use it too :)
<qwebirc70375>
i am trying to compile a simple hello world C code
<qwebirc70375>
plz help me with Makefile for it
<SiENcE>
ok. i'm going to test jlime. where to get the latest one?
<qwebirc70375>
kristianpaul : if we go with this procedure then we will have to flush the kernel again and agin if some minor change is there in the application
<qwebirc70375>
cant we compile it seperately and port the bin file via storage card and then execute it
<qwebirc91287>
i am getting error while reflashing kernel : cant read bulk data from Ingenic device
<xiangfu>
qwebirc91287: make sure there is no USB-HUB. and use the usb-cable that send with NanoNOte.
<SiENcE>
xiangfu, why the usb cable send with nanonote?
<wpwrak>
that seems to be another myth that ought to die. i don't think the nanonote cable is *that* superior to the average usb cable bought within the last years.
<xiangfu>
I should say use better usb cable :)
<wpwrak>
xiangfu: or "don't use the usb cable grandma knitted herself" ;-)
<larsc>
Ayla: have you managed to get rtc wakeup working?
<Ayla>
nope
<Ayla>
I'll work on that tonight
<Ayla>
it seems that the interrupt is never called, so I guess it is masked somewhere
<larsc>
hm, ok.
<larsc>
you should check /proc/interrupts to be sure that it really has not fired
<Ayla>
23:Â Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â Â Â Â INTCÂ Â jz4740-rtc
<Ayla>
no interrupt at all
<kristianpaul>
xbust have a sleep instruction or it go to low power mode?
<larsc>
sleep
<larsc>
kristianpaul: well it has both. there are two different sleep modes
<larsc>
so you can change the semantics of the sleep intstruction by writing to a mmio register
<larsc>
one is the normal sleep behaviour known from mips. the cpu will stop executing instructions until the next interrupt
<larsc>
the other is going to low power state until the next interrupt happens
<larsc>
the first one is used when the cpu is idle, the second one is used when we send the system to suspend
<Ayla>
larsc: the driver currently does not implement irq_set_state
<Ayla>
is that a problem?
<Ayla>
(ah no, it seems it's only for the periodic alarm)
<kristianpaul>
larsc: so interrupt can be trigger by a counter or a internal clock?
<kristianpaul>
just thinking how setup an alarm clock
<wpwrak>
kristianpaul: counters often aren't powered in deep sleep states (not sure without looking how it is on xburst, though)
<larsc>
well at least the rtc clock is of course running
<kristianpaul>
hmm
<kristianpaul>
ok
<kristianpaul>
so how the nanonote will wakeup?
<larsc>
and i think you can also keep the other SoC timers running
<kristianpaul>
keyboard pressing i guess
<kristianpaul>
but.
<kristianpaul>
an alarm clock is so nice :)
<Ayla>
larsc: hmm
<Ayla>
jz4740_rtc_ctrl_set_bits: mask=0x4, set=1.
<Ayla>
are you sure that this function actually works? :)
<larsc>
no
<Ayla>
is it possible that the interrupt is activated on the RTC subsystem, but not on the AIC?
<larsc>
don't think so
<Ayla>
that's funny, if I type "jz4740 RTC" on google I get your name everywhere :)
<Ayla>
larsc: could you give me a hint?
<larsc>
Ayla: do you have the jz4740 ds?
<Ayla>
JZ_RTC_CTRL_AE bit is enabled in rtc_set_alarm,
<Ayla>
I have a PDF document, but not really useful
<Ayla>
JZ_RTC_CTRL_AF_IRQ is enabled in rtc_alarm_irq_enable,
<Ayla>
but JZ_RTC_CTRL_AF is not enabled at all
<Ayla>
even if it is disabled in the IRQ handler
<Ayla>
or maybe I just can't see it... x_x
<larsc>
AF is set by the hardware
<Ayla>
ok
<Ayla>
larsc: no it's not
<larsc>
Ayla: but it should be
<Ayla>
bits 3,4,5 are not set on the first call of rtc_ctrl_set_bits
<Ayla>
(before applying flags)
<Ayla>
but maybe they're cleared before that
<Ayla>
but even if JZ_RTC_CTRL_AF is set by the hardware,
<Ayla>
the bit is cleared on the interrupt
<Ayla>
so there can be only one interrupt
<larsc>
yes. there should only be one interrupt
<larsc>
otherwise the handler will be called in a constant loop
<Ayla>
shouldn't that flag be set on rtc_alarm_irq_enable ?
<Ayla>
when I say there can be only one interrupt, I mean that it's not possible to reprogram the alarm for a new interrupt
<larsc>
why not?
<Ayla>
because the interrupt handler desactivates the AF bit
<larsc>
the AF flag indicates whether a interrupt is pending
<Ayla>
yes, I just read that....
<Ayla>
larsc: another idea,
<Ayla>
you do not call wait_write_ready on rtc_reg_read
<Ayla>
but on the doc it's written "The read
<Ayla>
value from the target register is also undefined.
<Ayla>
"
<Ayla>
(when the bit is 0)
<qi-bot>
[commit] Werner Almesberger: Instead of performing the tranformations stepwise for each point, pre-calculate http://qi-hw.com/p/ben-scans/898970b
<qi-bot>
[commit] Werner Almesberger: More corrections to handling of the "user" matrix. Made controls more intuitive. http://qi-hw.com/p/ben-scans/7c24783
<qi-bot>
[commit] Werner Almesberger: Like rotations, shifts can now be accelerated by changing the mouse position. http://qi-hw.com/p/ben-scans/a7105ad
<Ayla>
when I write to the /sys/class/rtc/rtc0/wakealarm file, it does not seem to set the IRQ flag
<Ayla>
the alarm_irq_enable function is never called...
<Ayla>
oh!
<Ayla>
rtc-dev.c: "RTC_WKALM_SET eliminates the need for a separate RTC_AIE_ON call"
<Ayla>
which enable the alarm interrupt
<Ayla>
which means that RTC_WKALM_SET should actually set the interrupt
<Ayla>
what it does, is call the rtc_set_alarm() function
<Ayla>
unfortunately,
<Ayla>
jz4740's version of that function only modify the RTC_SEC_ALARM and the RTC_CTRL_AE flags
<Ayla>
it does not set the RTC_CTRL_AF_IRQ flag
<larsc>
ok.
<larsc>
will you fix it?
<Ayla>
yes
<larsc>
good :)
<Ayla>
I just hope that's the reason why it does not work :)
<wpwrak>
Ayla: if not, you get to enjoy the adventure a bit longer. a win-win situation ;-)
<Ayla>
23:Â Â Â Â Â Â Â Â 21Â Â Â Â Â Â Â Â Â Â Â Â INTCÂ Â jz4740-rtc
<mth>
assuming you have no serial connection, there is not really much of a difference between "not waking up" and "crashes on wakeup"
<Ayla>
does it crash on wakeup?
<Ayla>
maybe it crash on suspend
<mth>
also possible
<mth>
maybe this is useful: Documentation/power/basic-pm-debugging.txt
<mth>
via /sys/power/pm_test you can specify how deep the kernel is allowed to sleep
<mth>
instead of doing a full suspend
<Ayla>
okay
<Ayla>
I'll check that tomorrow
<qi-bot>
[commit] Werner Almesberger: The #endif at end of header file must have a comment saying /* !name */ http://qi-hw.com/p/ben-scans/0c49406
<qi-bot>
[commit] Werner Almesberger: Step sizes are now auto-determined, allowing use of files of any resolution. http://qi-hw.com/p/ben-scans/2cc9a9e
<qi-bot>
[commit] Werner Almesberger: solidify now stores the context of sessions in project description files. http://qi-hw.com/p/ben-scans/f6ed3bf