Mindboards

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

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

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

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

Ok, thanks for letting me know.

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

Matt

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