Answer found here, but in summary, it can't be helped. Smux lags when it's changing a sensor's type, in this case "Active" and "Inactive". See link for more details.

Hello everyone, I'm having some problems with the Sensor Multiplexer.

To jump to the chase, when I add a function using LSsetActive & LSsetInactive, my tick-time(time it takes to go through the while loop, in tele-op) jumps from around 3-5ms to 75-85ms, and adding two touch sensors in that functions, jumps it to ~100ms, sometimes going as far as ~300ms for a second or so. Is this normal?

Do you have code that writes to the flash? That is a very time consuming operation. I wouldn't worry about consuming too much memory, the compiler doesn't allow for dynamically allocated memory, so everything has been declared at compile time. If it fits at compile time, it will fit just fine at run time

Who knows what it was caused by, if you have multiple tasks, you might be causing deadlocks without even knowing it. My advice: avoid tasks like the bubonic plague.

Hahah, yes, I remember one FTC team telling me to put every individual motor into it's own function. While it's not a bad idea (in theory), making each check if the motor goes out of bounds, the way RobotC does functions...I'm not sure if it's worth it. :S

Anyways, I have three tasks, and none of them write to flash.

The first one is Main, and it goes through a while loop controlling the driving, other motors, servos, and an "extra" function that does the extra things(that can fit in the main task)(that was the one hogging it, and using the light/touch smux sensors).

Second is a Debug function, doing nothing but assigning values to global variables, so I can see them in the "Global Variables" section.

Third is an "excess_extra" task, that does things(like more while-loops) while the main task is still running.

Also, there's the Joystick tasks from the JoystickDriver.c, and there's a Gyro task from a gyro driver I found deep within the RobotC example files(works gloriously, by the way).

I'll try messing around with some stuff and pin-point it, but I have a bad feeling it's not what it seems to be...

EDIT: In your SMUX drivers...what happens if you try to read two values at the same time, in different tasks? Would it time-out?

Ok, I have figured out why this is happening. It had been a while since I wrote this driver but here it goes:When you modify the configuration of a mux sensor, the mux needs to be put into HTSMUX_STAT_HALT. This is something that takes 50ms + the time it takes to do the I2C operations. After it is done modifying the channel settings, it will put the channel back into HTSMUX_STAT_NORMAL and the new configuration becomes active. The HTSMUX_STAT_NORMAL is when the MUX can poll things again. So basically your constant reconfiguration of the port is causing these long delays. I cannot change how this behaves, as the MUX simply requires the 50ms between changing modes and was never designed with such a rapid mode change in mind.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum