Electronics in repo, I2C register talk

Posted on August 28, 2014

0


Njay: I’m registered at GitHub as nunojay. I’ve cleaned up my files and I’m ready to push, just need permissions on the repo. I renamed the NJAY folder to Electronics, I think it makes more sense. 🙂

Vnevoa: Done! Go ahead.

GitHub - electronics by njay

Project DiffTrike file repository on GitHub.Com, showing the first official contribution from someone other than Vnevoa. 🙂

Vnevoa: Cool, I see you’ve uploaded your files! Can you put some README files in each folder, explaining what is in there and what software is used to open the files? That would be very nice. Thanks!

And now I know why the Temperature register in your photo is blurred…. 😉 You’re using it as a heart-beat check for the microcontrollers. Listen, nothing forces us to keep the I²C registers as they are, we can change them at will. We’ll have to change them anyway to include the new temperatures from the motors. The “acceleration” register for example makes no sense to us.  So you can create a new list of registers… probably best after you’ve got the current limitation running. 🙂

Njay: It’s all Work In Progress!

My bridges never had temperature sensors until now anyway! 🙂 Meanwhile I’ve noticed that your I²C registers (on the RasPi)

# Bridge controller registers:
REG_COMMAND = 0 #RW, 0:stop, 1:fwd, 2:rev.
REG_STATUS = 1 #RO, b0:accelerating, b1:over-current, b2:over-temperature, b7:busy.
REG_PWM = 2 #RW, PWM, 0..243
REG_ACCELERATION = 3 #RW, 0:fastest
REG_TEMPERATURE = 4 #RO, NTC, 1/1.42 C
REG_CURRENT = 5 #RO, 186=20A
REG_EMPTY1 = 6 #unused
REG_FW_VERSION = 7 #RO

…don’t exactly match mine (on the power bridge):

// The registers we support. Can be read, some written, through I2C:
 enum {
     eI2cReg_Command = 0,      // R/W command
     eI2cReg_Status = 1,       // R status
     eI2cReg_Speed = 2,        // R/W speed
     eI2cReg_Acceleration = 3, // R/W acceleration
     eI2cReg_Temperature = 4,  // R temperature
     eI2cReg_MotorCurrent = 5, // R motor current
     eI2cReg_MotorVcc = 6,     // R motor Vcc
     eI2cReg_SwRevision = 7,   // R sw revision
 };

Regarding list changes, they’re not expressly necessary. We need an extra Temp register, true. But I’d like to keep the Acceleration register. There is this Command mechanism to access other functionalities.  It’s possible to write a value there and get a reading of the desired value in the next Read operation. I can read the extra Temp by reading the Command register without writing anything there. Or we can put the Command register in the place of the SwVersion register. There’s lots of possibilities, but I’d like to keep the Accel reg, it may be implemented some day. We could also expand the number of registers to 16, although that may complicate your life a little bit if you’re reading continuously and expecting the address to wrap-around.

We can put the SW version in the Command reg, the new Temp in the SW reg, and reduce the Speed reg to 7 bits for PWM and 1 bit for direction. 7 bits (0 – 127) should be enough resolution, my motor without load won’t budge before Speed = 30/255 (12%). And switch some positions to organize this better. Like this:

// The registers we support. Can be read, some written, through I2C:
enum {
 eI2cReg_Command_SwRev = 0, // R/W command / read software revision
 eI2cReg_Status = 1, // R status
 eI2cReg_Speed = 2, // R/W speed/direction
 eI2cReg_Acceleration = 3, // R/W acceleration
 eI2cReg_HBridgeTemp = 4, // R hbridge temperature
 eI2cReg_HBridgeVcc = 5, // R hbridge power supply voltage
 eI2cReg_MotorCurrent = 6, // R motor current
 eI2cReg_MotorTemp = 7, // R motor temperature
};

Actually, the Accel reg is being used:

0 - forward motoring
1 - reverse motoring

(to be continued…)Lisbon_MMF_logos_Banner_big

Advertisements
Tagged: