NXTCam Generic I2C Firmware - where is it?

Discussion specific to the intelligent brick, sensors, motors, and more.
Post Reply
physics-matt
Posts: 76
Joined: 29 Sep 2010, 06:57

NXTCam Generic I2C Firmware - where is it?

Post by physics-matt » 02 Oct 2010, 21:45

Can anyone tell me where to find the "Generic firmware" for the PIC16F88 on the NXTCam v3? (as described in the Advanced Programming Guide http://www.mindsensors.com/index.php?mo ... ent_id=149 )

What I gather from the guide is that there is a .hex file that provides a "generic" IO model for the I2C bus, which I can upload using mindsensors' firmware upgrader. I've got the upgrader, but can't find the .hex file anywhere on their site. Google also hasn't helped so far.

Can anyone help? Or is there something I've missed or misunderstood? I've managed to start messing around with the ATmega8 firmware no problems, but I gather that's quite a separate entity.

Matt

mightor
Site Admin
Posts: 1079
Joined: 25 Sep 2010, 15:02
Location: Rotterdam, Netherlands
Contact:

Re: NXTCam Generic I2C Firmware - where is it?

Post by mightor » 03 Oct 2010, 05:01

Hey Matt,

In order to use the generic PIC firmware, you need an AVR firmware that is capable of working with it. Anyway, here's a zip file with the generic PIC firmware I was sent earlier this year. I will let Deepak know it's not on his website. Perhaps there's a reason for this :)

Use this at your own peril, cave canem, caveat emptor, etc.

Edit: removed the attachment. If you want to get the generic firmware for the NXTCam, please contact [email protected] and they'll send it to you.

- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)

physics-matt
Posts: 76
Joined: 29 Sep 2010, 06:57

Re: NXTCam Generic I2C Firmware - where is it?

Post by physics-matt » 03 Oct 2010, 09:24

Thanks!

Have you tried both versions of the firmware in the zip file? And did you use the mindsensors firmware upgrader?

It will probably be a while yet before I try changing the firmware myself as I'm still getting to grips with the AVR code and haven't really looked at the NXC side of things. I gather I will need to figure them out just to test that the firmware successfully uploaded!

Matt

mightor
Site Admin
Posts: 1079
Joined: 25 Sep 2010, 15:02
Location: Rotterdam, Netherlands
Contact:

Re: NXTCam Generic I2C Firmware - where is it?

Post by mightor » 03 Oct 2010, 09:36

I have not used the generic PIC firmware yet. I have reflashed the AVR many times, though. I've used the reprogramming tool many times on other sensors, such as the motor mux and lineleader.

- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)

physics-matt
Posts: 76
Joined: 29 Sep 2010, 06:57

Re: NXTCam Generic I2C Firmware - where is it?

Post by physics-matt » 03 Oct 2010, 09:52

Ok, thanks for letting me know.

When I feel brave enough to try flashing the PIC I'll post an update.

Matt

gloomyandy
Posts: 323
Joined: 29 Sep 2010, 05:03

Re: NXTCam Generic I2C Firmware - where is it?

Post by gloomyandy » 03 Oct 2010, 09:59

Hi,
I've used the generic firmware and it can be a little tricky. It is easy to use to issue standard commands to the AVR, and it works fine for commands that return simple replies (like reading registers etc.). However commands that enable a stream of responses (like the tracking command), are not so easy to use. The problem is that once the reply buffer is full then incoming data is discarded and so you tend to lose sync with the reply stream. It may be possible to sync on the gaps between replies but that is pretty tricky to do. I got around the problem by always making the commands I use be synchronous so that to obtain data you always issue a command and then read the single reply. This will slow things down but I think works better.

To be honest I'm not sure how well the standard interface works as I don't really see how you can be sure that all of the various registers are from the same response packet. The documentation warns that the values can be over-written. It seems to me that if your code reads the object count followed by reading the tracked object data, then you may get a count from one response but objects from the next. Without being able to see the pic firmware it is hard to see how the synchronization (if there is any) works... I've not actually used the standard tracking commands from the NXT so can't really be sure if this is really a problem or not...

Andy

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests