Rockbox

This patch removes necessary GPIO settings from lcd_init_device in lcd-e200v2.c

If a bootloader is made with this patch, the display is not initialized properly.

That's probably because he thought it's not needed, he didn't update the bootloader :) Just a wild guess though.

But I wonder what the gains of removing it are. I'm pretty sure domonoky didn't comment those out because the code looks nicer or so.

@ kugel:
yes, you are right, i didnt test the bootloader, so i missed that they are needed.

The intention was to get rid of all unneeded and unknown inits (i wondered why the lcd would need some pins on GPIOA when the data transfer is on GPIOB and C). And also some GPIO commands are strange in this init (setting the pin before switching the pin to output ?). It really needs cleanup, and investigation what these GPIO pins really do.

But the real focus in this patch was th Buttons :-)

I think this order is here because when the pin direction is set to output, the value written has already been set.

This button-e200v2 patch has all buttons(including rec I believe) and scrollwheel working in unicatcher theme. In cabbiev 2 it doesn't really work at all. If you comment out the get_rec function you can use the left and right buttons to clumsily navigate the menus in cabbiev2. I had to add the wait code in get_rec or rockbox saw the rec button as pushed during boot up and cleared my settings, putting me back into cabbiev2...

Hm, I'm puzzled, that the theme makes any difference. This doesn't make sense to me, and it's far from what I notice from my Fuze.

Maybe you try some other things, for altering example the <nop> loop. I'll let you experiment a bit, but I think I'll commit it anyway tomorrow or so.

This one is cleaned up a bit and I corrected a double backlight call before the queue post. I think something else is pulling DBOP 15 down to 0 in addition to the rec button that needs to be filtered out somehow.

If delay helped with the REC button, you could always try some more delay.

Maybe you could also change the delay loop in the dbob function (this one with asm volatile("nop") in it). This delay is what I got by disassembling the Fuze OF, it might very well be, that this delay is off or totally wrong for the e200v2.

The nop loop made no difference that I could find so I got rid of it and put a while delay in just before the dbop read. I also changed some function names and comments to reflect more of what it seems is actually happening.

I consider committing, so you can work on SVN, which is always a bit easier.
Did I get this right? You do not allow REC to be read during startup, but after the 57 ticks? What are the problems with the REC button apart from that?

BTW, your delay loop is effectivly the same as the <nop> loop.

cabbiev2 still doesn't work but this works much better in unicatcher. I've made a hybrid with the fuze button code and the e200v1 clickwheel code. I've left the get_rec code in but commented out the function itself as something else is still setting dbop15 to 0 intermittantly. LCD driver??

What means works much better? You said working well in unicatcher.
You also said cabbiev2 works without the REC button :/

My early versions of the Fuze scrollwheel code where copied from the e200 clickwheel too. But once I noticed all the wheel acceleration stuff is unneeded, because you cannot get acceleration right without reading the wheel in an interrupt, I stripped all that out and got what's in SVN. Basically, acceleration was actually bad, since the cursor jumped around randomly.

Going by the datasheet, the output cannot alter DBOP_DIN, at least not when the STATUS register says read data valid. I don't think the lcd driver does anything to dbop_din directoy, but you may of course try to block it out and make sure.

Subjectively what I mean by works much better is just the feel of it while scrolling. It feels much tighter and under control. With the fuze scrollwheel code it worked pretty well but sometimes skipped and jittered around All this in unicatcher theme of course, in cabbiev2 the scrollwheel does not work with either code. In cabbiev2 with the fuze scrollcode you I can use the >>| and |<< buttons to make the menus scroll somewhat randomly but not the scrollwheel.

Objectively I can tell you several things about the e200v1 scroll code that makes me call it better, at least for my e280v2. The scrolling stops at top and bottom of menus giving it a more finished look. The scrollwheel actually controls the volume on the wps screen. In the debug menu the fuze code was always boosting cpu frequency and the e200 code never does.

I have a e200v1 myself, I know how it's supposed to work. And it almost works like that on my fuze with my code (except for the acceleration, and sometimes missed wheel events, which isn't doable better with polling).

"In the debug menu the fuze code was always boosting cpu frequency and the e200 code never does." I don't quite understand.

RE: "In the debug menu the fuze code was always boosting cpu frequency and the e200 code never does." I don't quite understand.

In the debug menu there's a CPU frequency menu. With the e200 scrollwheel code the frequency is solid at 31000000 and boost_counter is 0. With the fuze scrollwheel code it's continually jumping up to 248000000 and boost_counter increments as you scroll the wheel.

Well, boosting is correct in this menu. It's meant to make one able to force a boost level.

Also "The scrolling stops at top and bottom of menus giving it a more finished look. The scrollwheel actually controls the volume on the wps screen." - This both works on my Fuze.

RE: This both works on my Fuze.

That's great for you but doesn't help me out with my e280. Neither work on my e280 with the fuze scroll code.

This certainly isn't a my code is better than your code debate because I'm going to lose that one quite quickly.

I think the e200v1 scrollwheel code works better on my e280v2 so that's what I'm going to use for now.

But cabbiev2 still doesn't work, yes?

Nope, cabbie and the rec button still do not work with either code.