Didn't mean it personally, it's just hard to develop with it because it won't let me set any registers, just frustration from trying to get something done and feel like I'm not moving anywhere. Just wanted some more info too, felt like this was not very open code to the rest of us hacking at it with you, and really need it to be able to allow others to do so, that is more important than a 'perfect' design. So sorry if I was a bit harsh, I'm not mad or wanting to hold any thing against you for it, just being open about my first thoughts and hoping to stir more interest and discussion from you and everyone by doing so (find it seems to get things done quickest when diving in and putting everything on the table like this, I was hoping to get as much help as I could at what seemed like a dead end when hacking at the cx25840 code, at least for me it was a dead end).
Thanks, Chris On Tue, Apr 05, 2005 at 12:06:06AM +0200, Ulf wrote: > Hey, don't pick on me. > > The cx25840-registers stuff was written to support my I2C parser, I then > used it as a fast way of converting the captures into working code. My code > has never been presented as production worthy. It did however work better > then one the original. > > Yes the register file is auto generated from a datasheet, the datasheet > contained a lot of inconsistencies. Some register had different addresses in > different lists. Binary numbers was mixed with hex numbers, which is very > hard for a parser to detect... > > The code is written so that all debug stuff can be compile time removed be > changing the macro definitions. So the debug info size should not be an > issue. > > Setting all registers to a default value was the only way I could think of > to put the card into a known state, since the datasheets didn't present a > reset-mechanism that guarantied a known state. This is critical when > different generations of the code are run on non-rebooted machines. > > The shadow copy of all registers is kept to speed up the configuration > process, i.e. don't set the same value several times. We need to address > bits in bytes. I don't like to waist CPU time on bit banging unnecessary I2C > codes. > > My intention was to tag all volatile/auto-updating registers as such and > handle them specially, I didn't have time for that though. > > Yes you could go for an all anonymous "set address to byte" based driver, > but I don't think that is a good idea if you want maintainability. Then > again I don't claim that my code is ready or even maintainable. > > /Ulf. > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > ivtv-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
