Re: [Fx2lib-devel] new, just found this list

[Dennis M. <de...@ub...>]

Gerry Rozema wrote:
>> I think the documentation will help here too, but realistically, there 
>> is a bit of a learning curve getting into embedded devices anyway I 
>> guess.  I hope the library can take away some of that learning without 
>> hiding it too much from you.
>>   
>>     
> this is not my first delve into embedded devices, I've done lots of work 
> with pics in the past.  This _is_ my first run into the fx2.  I'm quite 
> comfortable in the world of bit bashing, and measuring 'free ram' in 
> 'bits' .  But, the stuff out of the git repository was indeed a great 
> kick-start.
>
>   
>> That's exactly what we are doing actually.  Different parts, but having 
>> our own firmware has been invaluable in figuring out how our devices 
>> pins are hooked together.  Eventually, we'll probably build our own device.
>>   
>>     
> In my case, the device I want is already available from retail channels, 
> at what amounts to not a lot more than the cost of the parts.  Makes no 
> sense to fabricate custom hardware in this case, but, I do want to do 
> stuff with it that's vastly different than it's original intended 
> application
>   
>> Once you get the exact part and the correct data sheet, you're well on 
>> your way.
>>
>>   
>>     
> I've got all the data sheets, and been reading thru them today.  Turns 
> out, there's likely only one way to stitch the fx2 and Mt9M001 
> together.  All of the sensor registers are available thru i2c, and, 
> reading out pixel data comes to a 16 bit bus, of which 10 are used, with 
> the sensor providing a pixel clock.  So far I may be mistaken, but, it 
> seems to me, there's only one logical way to glue these parts together, 
> and, once I get past actually reading and writing the i2c bus on this 
> piece, it's going to fall together quite neatly.  Trigger the frame 
> readout from the sensor, and that data will start showing up in the fx2 
> fifo, to glue them together any other way makes no sense, so I'm pretty 
> sure that's how it was done.
>
> So far, my challenge is, altho the hello example runs fine on the 
> devices, and a few other little test thingies I wrote just to validate a 
> little more, I have not successfully read the i2c bus.  Just starting to 
> re-read docs in detail, and see what I am possibly missing in setup 
> stages to get that bus reading ok.
>
>   
I'd planned on adding two more example programs.  One reads/writes 
eeprom data.  The other resets the fx2 development board to it's default 
state if you bork the eeprom data.  You can't do the latter on a real 
board usually though!  The eeprom routines are already there in the 
library though.  The fx2 is hard coded to boot from a certain prom 
address so it's likely even if it's not on the development board, that 
any other board uses the same eeprom address on the i2c bus.  In other 
words, the lib routines should work correctly on your device.  I'll post 
those examples here in a bit.

-Dennis