--- Log opened Wed Aug 04 19:47:12 2010
19:47 -!- fmibot [~fmibot@static.225.178.40.188.clients.your-server.de] has joined #linux4nano-dev
19:52 < TheSeven> cmwslw: fyi, you could just use cprintf(1, "formatstring", values); instead of that snprintf trick
19:55 < TheSeven> [18:26] <cmwslw> this is what I got: R0 = device id, R1 = I2C address, R2 = data, R3 = length
19:55 < TheSeven> correct
19:57 < TheSeven> and i2crecvbyte looks broken indeed
19:59 < TheSeven> temporary fix:
19:59 < TheSeven> +	strne	r0, [r2], #1       @ write it to our buffer
20:00 < TheSeven> +	streq	r0, [sp]
20:00 < TheSeven> or just use i2crecv directly
20:11 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
20:28 < cmwslw> TheSeven: yea i figured out that i should just use i2crecv instead
20:28 < cmwslw> but it doesn't help since that outputs garbage anyways
20:28 * TheSeven wonders why
20:28 < cmwslw> it's the same exact code as your ibugger one
20:29 < cmwslw> i ran through every single instruction and the only difference was the "ldr	r0, [sp]"
20:29 < TheSeven> well, with some regs changed... did you try just using the nano2g embios code?
20:30 < TheSeven> even though i must admit that i have never verified that reading using that actually works
20:30 < cmwslw> and that instruction loads the device id I think
20:30 < TheSeven> yes, it does, because r0 was trashed above
20:31 < TheSeven> and adding this was the reason i2crecvbyte broke, as r0 is restored from the stack at the end of the function, overwriting the return code with the device address
20:31 < TheSeven> a possible fix could be to just restore it into r1
20:31 < cmwslw> is the return code always r0?
20:31 < TheSeven> yep
20:32 < TheSeven> restoring r0-r3 isn't required anyway, we just need to pop it to some reg for stack consistency
20:32 < TheSeven> so changing the r0 to r1 in the ldmfd should actually fix i2crecvbyte
20:34 < cmwslw> if you change the ldmfd shouldn't you change the stmfd at the top?
20:34 < TheSeven> nope
20:35 < TheSeven> we need r0 to be on the stack when loading the device id
20:35 < TheSeven> but we only restore it to some dummy reg to ensure that the stack is balanced
20:35 < TheSeven> the function may trash r1-r3 and r0 is the return code, so we can just restore it to r1 instead to avoid overwriting the return code
20:36 < cmwslw> oh ok
20:37 < cmwslw> well that did fix i2crecvbyte in the sense that it returns the same as i2crecv would
20:37 < cmwslw> but still 255
20:38 < cmwslw> so your i2c code works on the 2g?
20:38 < TheSeven> the c one yes, i don't know about the asm one
20:38 < TheSeven> afair i have only used it for writing until now
20:39 < TheSeven> well, that garbage is apparently coming from the i2c itself...
20:40 < cmwslw> i could test writing to the backlight and see if that works for me
20:40 < cmwslw> could be only reading is broken
20:40 * TheSeven hopes it won't write garbage to the pmu
20:40 < TheSeven> hm, reading the accelerometer via ibugger works though
20:41 < TheSeven> have you checked if that one uses the same clocking?
20:42 < cmwslw> that could be it, but is there a separate clock for i2c than the main processor?
20:46 < TheSeven> i meant the divider in the IICCON reg
20:46 < TheSeven> the 0xf3 value written to [r12]
20:47 < TheSeven> i've seen 0xb0 bein used instead in some code, which would be 10khz instead of (slightly out-of-spec) 450khz
20:48 < cmwslw> i dont understand why 0xf3 would work in ibugger, but ill try 0xb0 anyways
20:48 < TheSeven> if it's also 0xf3 in ibugger, then this won't be the issue
20:48 < TheSeven> i just wasn't sure about this
20:49 < cmwslw> yea no values changed between this and ibugger
20:49 < TheSeven> hm
20:49 < cmwslw> only different registers and slightly more organized code
20:50 < TheSeven> try checking for semantic equivalence again. we might be missing something.
20:51 < TheSeven> i doubt that clock gates are the showstopper here, as you're probably running it through ibugger and embios doesn't change any
20:51 < cmwslw> i tried the new divider and it still outputs the same pattern
20:51 < cmwslw> ok i will
20:52 -!- Kebianizao [~kvirc@95.214.62.192] has joined #linux4nano-dev
20:52 < cmwslw> unless the lcdconsole code messes things up
20:52 < TheSeven> it shouldn't
20:53 < TheSeven> i'd rather suspect the multitasking scheduler, but as long as you aren't receiving any interrupts, this can't have an effect
20:54 < TheSeven> the lcdconsole code is probably yielding, but as there's only one thread, that shouldn't cause trouble
20:54 < cmwslw> well this revision doesnt even have multitasking unless im missing something
20:57 * TheSeven needs to look at the log
20:58 < TheSeven> it does, and it does have the buggy version of it
20:58 < cmwslw> do you think that might be causing it?
20:58 < TheSeven> oh, wait, r13, read the wrong message :)
20:59 < TheSeven> that should be working fine
20:59 < cmwslw> ok because i haven't seen any multitasking things in my source
21:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection]
21:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #linux4nano-dev
21:03 < cmwslw> i think i got it
21:03 < cmwslw> your i2c wait is overwriting r0, the device id
21:05 < cmwslw> actually i don't think it matters since when the device id is used again, it is reloaded from the stack
21:06 < cmwslw> i changed it to r5 and i still get the same pattern
21:17 < cmwslw> ok i found a difference and no i don't get the pattern anymore
21:18 < cmwslw> after "orr r0, r0, #1", it said "str	r1, [r12,#0x0c]"
21:18 < cmwslw> it should be writing r0 to the i2c core
21:22 < cmwslw> i think that fixed it
21:27 < cmwslw> yep it works now
21:41 -!- Jiss_ [Jiss@ip-196.net-89-2-209.rev.numericable.fr] has quit [Ping timeout: 245 seconds]
21:42 < cmwslw> now i just need to work on writing an accelerometer driver, which should be a piece of cake now
21:43 -!- Jiss [Jiss@ip-68.net-89-2-219.rev.numericable.fr] has joined #linux4nano-dev
21:43 -!- Kebianizao [~kvirc@95.214.62.192] has quit [Ping timeout: 276 seconds]
22:00 < TheSeven> cmwslw: fyi, the i2c api changed some revisions later, it now has a bus id as a new first argument, followed by the old arguments
22:16 < cmwslw> TheSeven: yea i noticed that, but i was going to wait until  i got it working before I added that
22:18 < cmwslw> but do you think I should bother changing it? we'll be moving this to C with interrupts eventually won't we?
22:19 -!- TheOneRing [~quassel@e179205213.adsl.alicedsl.de] has joined #linux4nano-dev
23:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has quit [Remote host closed the connection]
23:00 -!- clustur [~logger@c-76-127-58-39.hsd1.ga.comcast.net] has joined #linux4nano-dev
23:01 < cmwslw> I finished with the accel driver. I want to add some drawing commands like clear and draw line.
23:01 < cmwslw> i figured i would put them in drawing.h but that uses drawing.S. Is there a way I could also have drawing.c?
23:29 < TheSeven> nope
23:29 < TheSeven> that must be named differently
23:30 < TheSeven> and clear is just a memset call :)
23:30 < TheSeven> drawing lines between arbitrary coordinates is not quite so simple
23:32 < cmwslw> yea i figured id have to do some research for that one
23:33 < cmwslw> but is drawing lines something you'd like to have in embios? i'm not quite sure where the limits should be
23:35 * TheSeven isn't quite sure about that either
23:36 < TheSeven> what we need is an abstraction for as much hardware as possible, and everything the core needs to do that, for example multitasking and a simple console
23:37 < TheSeven> things like the line drawer might fit better into a userspace library
23:37 < cmwslw> yea i think i'll just leave those out
23:37 < TheSeven> that way they don't have to be in memory for applications that don't need it, and those that need it will have it linked in statically
23:37 < TheSeven> see lcdconsole.c for how to clear the screen :)
23:38 < cmwslw> offtopic: in your lcdconsole.c you just ignore \r
23:38 < TheSeven> yep
23:38 < cmwslw> shouldn't it set the current column to 0?
23:38 < TheSeven> that would be an option
23:38 < cmwslw> well i think it would be better than just being ignored
23:39 < TheSeven> yeah, it can't hurt
23:39 < TheSeven> \r\n will do the same as before
23:40 < TheSeven> that should probably be added/changed
23:40 < cmwslw> and also the console scrolling is badly broken if you dont know already
23:40 < TheSeven> this has probably been fixed in a later revision
23:40 < TheSeven> however, this might break nano4g compatibility again
23:41 < TheSeven> (the lcd code is now using dma and interrupts to operate as much in the background as possible)
23:41 < cmwslw> i think i looked at the file and there were some later changes, but nothing i thought that might fix it
23:41 < TheSeven> it's working fine for me at least with the latest revisions
23:42 < TheSeven> updateing lcdconsole.c to r14 should fix it
23:43 < cmwslw> ok i'll try that
23:43 < cmwslw> first i have to commit the changes i made
23:43 < cmwslw> it will fix the i2c on the 2g also
23:43 < TheSeven> uh oh
23:44 < TheSeven> i2c.S doesn't even exist any more in the latest revisions
23:44 < cmwslw> oh yea I forgot
23:47 < cmwslw> i'll just add it on the 4g side but i'll leave the 2g side alone
23:47 < TheSeven> you might actually want to branch it to keep a nano4g-compatible version until it catches up on the reversing side
23:47 < TheSeven> i'm about to break even more things soon
23:48 < cmwslw> are you planning on catching things up soon?
23:48 < TheSeven> hm, currently it isn't that much
23:49 < TheSeven> the interrupt stuff can be taken from ibugger, it's just the timer that's holding it back
23:49 < TheSeven> usb is also very similar to the 2g and can be taken from ibugger
23:49 < cmwslw> i tried to work on the latest version but i noticed it needed an s5l8720.h
23:50 < TheSeven> yeah that probably has to be written
23:50 < TheSeven> (or copied from s5l8701.h and adapted)
23:50 < TheSeven> the problem is that we don't have a reasonably accurate datasheet for the 8720
23:52 * TheSeven wonders how to implement the synchronisation of the usb console code
23:52 < TheSeven> this is getting a wakeup hell
23:53 < cmwslw> is that like something you can print to that goes to the computer?
23:53 < TheSeven> yep
23:53 < TheSeven> like the old ibugger console
23:55 -!- TheOneRing [~quassel@e179205213.adsl.alicedsl.de] has quit [Read error: Connection reset by peer]
23:57 * TheSeven will go to sleep now
23:57 < cmwslw> ok goodnight
--- Log closed Thu Aug 05 00:08:18 2010