ArduPilot
Correct MCP9600 temperature sensor simulation
What's with the 24bit shifting, is it a big endian thing? Wouldn't this effect all other SIM drivers too? Do all the drivers need to be checked?
What's with the 24bit shifting, is it a big endian thing? Wouldn't this effect all other SIM drivers too? Do all the drivers need to be checked?
The MCP9600 was the first device I'd come across with these weird variable-sized registers, so I wrote this little object to be able to add registers of different sizes at different offsets. It's the only user of SITL::I2CRegisters_ConfigurableLength - so we're not going to break anything else. The other simulated i2c drivers use SITL::I2CRegisters_8Bit and SITL::I2CRegisters_16Bit as its a simpler interface.
And yes, I believe the shifting was a big-endian/little-endian thing. I'm 99% sure it's just garbage and could be removed.
alright. Lemme poke at it and we'll get this moving along. Meanwhile, what's with the gdb delay? Seems like it deserves it's own PR
alright. Lemme poke at it and we'll get this moving along. Meanwhile, what's with the gdb delay? Seems like it deserves it's own PR
I was hoping to sneak that one through - I can merge it in a separate PR, but it allows you to debug things more easily in sim_vehicle.py. If you don't accept a connection from MAVProxy then it gives up and goes away, killing your debugging session. The patch stops it doing that. If someone is in the habit of using the command within MAVProxy that causes it to exit (and* uses the debugger it will cause problems for them, but for most people they would like to get the debugger when they've screwed up eg. their logging structures and are getting a very early panic.
I've removed the sim_vehicle.py patch from here (separate PR), and creates another PR for compiling all temperature sensors on the >2048kB boards.