fx2lib-devel — Mailing list for fx2lib development

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

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

Gerry Rozema wrote:
>> 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.
>>   
>>     
> I've been doing more reading, and, I think this is the issue I had, I 
> was _assuming_ rather incorrectly that the eeprom would be address 0 on 
> the i2c bus.  Just working up a test program to try walking thru all i2c 
> addresses and read the first couple of bytes from each address.
>
> I'm expecting to find a C0 eeprom, and, the device id of the cmos sensor 
> hiding somewhere on that bus.
>   
8 bit prom address=0x50
16 bit prom address = 0x51

There is a register that will tell you which type of prom it detected at 
boot too.

use the eeprom_read function.  you can send the bytes straight to a 
print function if you  have a serial port (probably not). 
I usually pipe the data across an endpoint for devices with no serial 
console.

-Dennis

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

[Gerry R. <ge...@ro...>]

> 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.
>   
I've been doing more reading, and, I think this is the issue I had, I 
was _assuming_ rather incorrectly that the eeprom would be address 0 on 
the i2c bus.  Just working up a test program to try walking thru all i2c 
addresses and read the first couple of bytes from each address.

I'm expecting to find a C0 eeprom, and, the device id of the cmos sensor 
hiding somewhere on that bus.

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

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

[Gerry R. <ge...@ro...>]

> 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.

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

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

Gerry Rozema wrote:
> Just found this list, doesn't look busy.
>   
Not too busy yet, but I just started the library within the last couple 
months.  I plan on releasing a file download as well as some generated 
documentation sooner or later.  I think that will help people get 
started easier.
> I've downloaded and started playing with the library, it's been a great 
> kick-start for me, actually allowed me to get something to compile and 
> run on one of my fx2 based devices.  I think there's a relatively steep 
> learning curve ahead, but, that's the fun of it all I guess.
>   
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.
> I've got a few commercial devices that came with very broken 
> windows-only software.  My goal is to unravel the hardware connections 
> between the fx2 and the Mt9M001 cmos sensor, then get my own firmware 
> written that'll allow me to use this device on a linux system.
>   
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.
> The devices in question are 'souped up' webcams, using the above sensor, 
> intended for use in astronomy applications.  I'm guessing that they are 
> all likely based on a similar reference design, and once I've unravelled 
> one, I'll have the keys to all of them.
>   
Once you get the exact part and the correct data sheet, you're well on 
your way.

-Dennis

[Fx2lib-devel] new, just found this list

[Gerry R. <ge...@ro...>]

Just found this list, doesn't look busy.

I've downloaded and started playing with the library, it's been a great 
kick-start for me, actually allowed me to get something to compile and 
run on one of my fx2 based devices.  I think there's a relatively steep 
learning curve ahead, but, that's the fun of it all I guess.

I've got a few commercial devices that came with very broken 
windows-only software.  My goal is to unravel the hardware connections 
between the fx2 and the Mt9M001 cmos sensor, then get my own firmware 
written that'll allow me to use this device on a linux system.

The devices in question are 'souped up' webcams, using the above sensor, 
intended for use in astronomy applications.  I'm guessing that they are 
all likely based on a similar reference design, and once I've unravelled 
one, I'll have the keys to all of them.


Gerry.

Re: [Fx2lib-devel] Allmybrain.com Question/Comment: fx2 sdio-1

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

This would be a great discussion for the mailing list.

It is very possible.  I'd like to have routines that let you setup
whichever serial port you'd like.  There are a couple issues with using
port 1 that don't apply to port 0.  There are separate timers you can
use etc.  I haven't looked at that code for a bit and it isn't fresh in
my head but I don't think it would be hard at all to implement.

I didn't implement it yet because I only needed on serial port.

apache wrote:
> Bob Livingston <liv...@sc...> wrote:
> I use many fx2s with ssdc in our atmospheric research instruments.  I appreciate
> your recent contributions via fx2.lib.
> 
> Your sdio_0 is port 0, accessed as stdin, which I use regularly.  Setup of
> sdio_1 should be straightforward, but the stdin routines will not apply.  Is
> port 1 use (by a non-expert like me) possible? For example, input on 0, output
> on 1.
> 
> Thanks for any comments.
> 
> Website: 
> IP: 65.117.226.75
> 

[Fx2lib-devel] Welcome

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

Initial Mailing List Message