Welcome to the Rockbox Technical Forums!
Have you tried writing to the PIC over i2c? Instead of figuring out what the OF does to the PIC, can you try sending something (a single zero perhaps?) to the PIC in hopes of reseting the numbers it returns for a button press? I would try it myself, but I won't be able to install rockbox on my zen till after christmas, when I will buy a CF card and adapter.
The rockbox bootloader is now on my zen. Before I start editing the bootloader, is there a way to recover from me messing up the bootloader?
And can you point to a source file that is a good example for reading/writing with I2C.
no, not yet.only the boot loader can be changed right now. which then loads the creative firmware@mcuelenaereother ideas to get around the cfs problem i had thought of:instead of finding a method to read it-getting the usb driver to work then format the drive on a computer
-or write a formatter system into a bootloader for installation purposes.
i think i will lean to try and get the the first one done, if a method of communicating is found.every attempt i had last night i couldnt get a consistant response from components, at one stage i had scroll up recognised as the hold switch...keep up the good work,hopefully i can find something of use!
Quote from: fejfighter on December 14, 2008, 07:24:05 AMno, not yet.only the boot loader can be changed right now. which then loads the creative firmware@mcuelenaereother ideas to get around the cfs problem i had thought of:instead of finding a method to read it-getting the usb driver to work then format the drive on a computerI tried that approach for quite some time, but got stuck. I think the USB driver gets as far as sending some control messages on endpoint 0 and that's it (see this site for more info about USB)Quote-or write a formatter system into a bootloader for installation purposes.What's the point about having FAT filesystem if you don't have USB working to put files on it (either through Rockbox or through the OF)?The OF will get erased by this, and even if you would put the FAT partition at some unused space inside the CFS partition; the OF still wouldn't 1) expose it over MTP because 2) it can't read it and doesn't know about its existence.
You can find the driver here and the datasheet here (ISP1583).
Using send_command_to_pic, I've tried writing everything between 0x0000 and 0xFFFF to the PIC. I then tried just changing the third byte (aka between 0x00 << 16 and 0xFF << 16) and then tried just changing the fourth byte (aka between 0x00 << 24 and 0xFF << 24). It didn't appear to do anything. The keycodes never changed. Most of the time the function gave me back 0xFF0F0000, but every once in a while (once in every 30ish calls to send_command...), with absolutely no pattern that I can find, it will return a different code. Well, actually, if you move your finger over the touchpad very fast it will start returning 0xFFFFFFFF. All I can think about is, what is the point of the PIC? It has to have a point, it has to serve a purpose otherwise why even bother with it in the first place? Why change the keycodes at random?
Well, is there a way for me to extract and disassemble the OF? I'm not great with assembly, but I still want to try
I've been looking at the disassembled code for the PIC the last couple of days. The function that handles the i2c communication is conveniently labeled "i2c_handler" and I've been tracing through the 550ish lines of assembler that make it up. Unfortunately, "i2c_handler" is the only actual name in the entire 55k line file, all the other function and variable names are just numbers based on where it is in the file. Even so, the actual code is fairly easy to understand since PIC 18 has very few instructions. I still haven't found anything useful yet, though
Page created in 0.108 seconds with 21 queries.