Hi

We're using a driver that we wrote that comes from a modified version of Xander's code for our HiTechnic Sensor Multiplexer. The purpose of the driver is to make it more similar to the standard RobotC sensorValue array functionality. We're really close to getting it to work completely, but have a few more questions. We will be more than happy to post it once we get the final bugs out of it...

The first question relates to the way the multiplexer reports it's status. The driver code says that the following bits are used to indicate the following status within this word:

Bit 00 = Battery Fault
Bit 01 = Busy (Auto Detect in progress)
Bit 02 = SMUX is Halted
Bit 03 = SMUX has Error.

What we're seeing is that the Busy status is on most of the time. Does anyone know for sure that the Busy state indicates "AutoDetect" or could it just mean "Scanning In Progress"? The way we read the documentation indicates that the SMUX scans the four ports once it's put into run mode... could that run mode scanning be considered "Busy" too? Or is there a problem with the code?

The second question relates to the Compass Sensor with the SMUX. Whenever we activate a light sensor (on a different port on the same mux) the compass sensor reads incorrectly for a period of time (like 180 degrees off). Since we have to halt the SMUX in order to activate the sensor, when we restart it, is there something that we should do to keep the compass sensor reporting correctly?

Thanks in advance!

Since I have absolutely no idea what changes you've made to the driver, I can't really tell what is wrong with it. The busy status means that the sensor is scanning the sensors.

The status should read 0 when there are no issues and the SMUX is reading data from the sensors attached to it.

- Xander

Hi Xander,

Sorry, actually, I wasn't asking about the code that I wrote. I was more wondering about the status that is returned from the I2C communication. In your driver the .status in the structure is written during the sending of commands. I'm wondering about the status that comes from word 21 on the SMUX.

<Snipped out a bunch of stuff written in error>
Alan

PS. Using your code (which is excellent by the way) is a bit more involved than what we're aiming for. Since we're only using simple sensors that return only simple single values, we wanted a simpler method of handling it from within the regular code. The routine I'm writing is just a scanner that reads the current values of the sensors attached to the MUX. It uses the functions from your common.h file to do that. (And yep, you get full credit in the new section and everywhere it makes sense to do so.

I keep track of the current state of the command sequence in the struct, this is not based on the status byte from register 0x21 It just allows me to make sure that specific commands have been issued before other ones. For example, in order for me to be able to read from the sensor, it needs to be in running mode, not busy or halted. Rather than issuing time consuming I2C commands all the time to request this info, I keep track of this info in a struct, one for each possible SMUX.



In the readStatus() function I don't update the struct at all. The only reason I have this function in here is for future enhancements I have some plans for the SMUX driver to handle additional error conditions.



You could just use the HTSMUXreadAnalogue() and HTSMUXreadPort() calls, without all the other drivers. You should be careful when using asynchronous calls, btw, these functions are not thread safe.

Regards,
Xander

Yep... I screwed up in writing that you overwrote... I did that when re-doing your code... (I thought I cleared it out of the forum fast enough that you wouldn't see my mess-up... dang-it you're just too quick!

I'm sending you the code so you can take a look at it if you want (it's OK to just toss it into the garbage too).

There won't be any duplicate calls - I realized they weren't thread safe and build in some handlers to deal with that... All the 'external to the driver' calls should go through a different type of function that just sets flags and moves values from a buffered area.

Alan

PS - by the way... even though the MUX reports the battery is OK, when it gets low, the compass stops working... (That's the issue I noted as my second problem - Just needed a new battery.) I noted that the touch sensor reports different zero (non-pressed) values depending on the battery voltage as well - Maybe I'll use that as an indicator!

I've attached the current version of my driver for the Sensor Multiplexer.

It is NOT intended to replace Xander's excellent driver, but is designed if you want something simple. In fact it only works with LEGO sensors and the Compass sensor. A lot of the code is based on Xander's driver functions and he gets the credit for doing all the research and work to make it possible.

The file "SMUX_Driver.c" file should be included at the top of your program (similar to the Tetrix Joystick.c file) and any sensors defined after that - the MUX is scanned automatically on a repeating basis, based on the sensors that are actually used.

The zip file has a readme and a sample program.