--- In [email protected], "kaffbeemer" <[EMAIL PROTECTED]> wrote: > > Hi Geert, > > thanks for the info. I followed the progress of your work. I've also > modified the driver as it was not working as I expected it to. But I > just worked out the specifics which I had and not as general as you > did. I also have no scope to check the real signal behaviour. I > think your driver will remove all the caveats which the old driver > had. >
Let's hope... ;-) > So as soon as your driver is finished I will try to use it. What I'm > not sure of is, that you change the magic number to be generated > dynamically although it will be the future solution in linux. But > I'd expect all devices being in /dev not somewhere else. > Well, if you look into the I2C driver file, you'll see a #define named DYNAMIC_MAJOR_I2CDEV_NUMBER_ALLOC. If you take the #undef part of this one (also already in the code, simply remove the comment slashes and put them in front of the #define part), you should have again the static MAJOR number allocation. But with my improvements in, of course. Then you simply have to recompile and recreate the flash image and you're done. Introducing the dynamic MAJOR number was just a nice exercise from my side to know a bit more about the whole FoxBoard SDK set-up (but I definitely don't know all of it yet...) and was also to "obey" to the Linux Device Driver bible... ;-) > Anyway my current solution is able to read values from four PCF8591 > (16 analogue values) and 8 digital input lines in about 20 ms which > is much faster than I require. > That is indeed a nice timing. If I measure the speed of my I2C driver, then I see the following when communicating with the PCF8591: - When writing to the DAC-section of the PCF (so, STA-SLAVE-CTRLBYTE-DATA-STO), it takes about 285us (measured from start to stop) to send those 3 bytes. - When reading an ADC conversion from the PCF8591 (so, STA-SLAVE-DATA-STO), it takes about 200us (also measured from start to stop) to send those 2 bytes. So, in your case that would take (in theory) 20 times 200us, meaning 4ms + some overhead of 1ms, total of about 5ms in stead of 20ms. A little bit faster... ;-) ;-) ;-) > I stored the values in an sqlite database in memory which was no > problem. But when I tried to move the database on to an usb pen for > storage reasons I had to recognize that the usb implementation on > the foxboard also lacks a lot performance and stability. The same > can be seen when operating a Wifi USB stick. The performance and > stability is very poor. > > I think John Crispin had to change a lot in his patch regarding the > usb implementation, as the original unpatched version was not > running at all. This might also be related to a hardware problem > with the etrax chip. > > So when you finished the i2c driver This is the case now, I think. I found a few small problems recently, but the archive I've uploaded yesterday evening should contain the solutions for that. In any case, it's working perfect now for me, using the devices PCF8574, PCF8591 and 24C32. > there might be more things you > could have an eye on as long as you can spend time on it. > This I don't know yet... USB is much more complicated then I2C, but that just might be a challenge for me. I will anyhow need USB devices too for my home automation project, so if there are indeed problems, I'll face them too. That might be the appropriate moment for me to jump into this... But first, I would like to finalise drivers for the different I2C devices I need. As there are: PCF8574 driver, PCF8591 driver, 24C32 driver, LCD driver (making use of the PCF8574 driver) etc, etc, etc... The I2C driver I optimised recently is on itself "just" the lowest level driver for me. The one that does the I/O pin manipulation (bit banging). On top of that, I would like to build the "real" drivers for the different I2C devices, using the I2C driver itself of course. > Great work Thanks! Best rgds, --Geert
