Need help with Flexis
HumanOzz
Posts: 13
Hey guys,
I need some good suggestions on how to solve the things i'm doing in my project.
Well basically, i want to use more than 8 Flexi sensors in 1 propeller chip and the problems with this is.
Flexi sensors use RCTIME object right, and when used in the background mode, its making use of a new cog with it.
What i mean is, 1 flexi sensor uses 1 cog. So i'm wasting a cog.
But if we use the RCTIME in the forground mode, the main program waits for the change in the pin state because of the waitpeq command and from what i read, the propeller goes into a low-powered mode.
So, from what i understand, if the main program waits for the change in the state of this one pin, then it wont be able to detect any changes in the other pins that i have connected with flexi sensors right.
Is there some ways to do this?
I have thought of using more than 1 more propeller chips, where the other chip handles the flexi sensors in the background mode and send the data to the main chip. But then, its kind of a waste of chips right.
I need a good idea on how to efficiently use the flexi sensors without using more than 1 propeller chip.
Can you help guys?
Thanks
I need some good suggestions on how to solve the things i'm doing in my project.
Well basically, i want to use more than 8 Flexi sensors in 1 propeller chip and the problems with this is.
Flexi sensors use RCTIME object right, and when used in the background mode, its making use of a new cog with it.
What i mean is, 1 flexi sensor uses 1 cog. So i'm wasting a cog.
But if we use the RCTIME in the forground mode, the main program waits for the change in the pin state because of the waitpeq command and from what i read, the propeller goes into a low-powered mode.
So, from what i understand, if the main program waits for the change in the state of this one pin, then it wont be able to detect any changes in the other pins that i have connected with flexi sensors right.
Is there some ways to do this?
I have thought of using more than 1 more propeller chips, where the other chip handles the flexi sensors in the background mode and send the data to the main chip. But then, its kind of a waste of chips right.
I need a good idea on how to efficiently use the flexi sensors without using more than 1 propeller chip.
Can you help guys?
Thanks
Comments
If you don't want that the main cog needs to wait until all the sensors are measured then do this in a separate cog.
The main cog can then read the values from the FlexValue array.
You can spare a lot of components with the attached circuit.
The code to measure all the sensors looks like that:
This writes the results in the FlexValue array.
Andy
Post Edited (Ariba) : 8/1/2010 11:43:52 AM GMT
hmm, this looks good, but dont you think the main program stops the assigned cog too fast for the readings to get to its real value?
i mean, if you can see from the program,
The gap between rctime.start and another rctime.start is kindof short.
If you use rctime in Foreground mode then it waits until one measurement is done.
The voltage at the Capacitor looks like that:
And here the variation to do all measuring in background with a second cog:
Andy
But then, if for example, we are at this point "rc.rctime(MsrPin,1,@FlexValue[noparse][[/noparse]0])",
and lets say, that flexi sensor involved doesnt detect any changes, the program will wait at this point until theres a change in state right? (which happen if we place some pressure at that flexi sensor). Because of the waitpeq.
What i mean is, if the program is at that point, waiting and waiting for the change of state, it wont be able to detect any changes that happens at the other flexis right?
What do you think?
So you need a rctime with timeout to not slow it down to much.
Here a possible code:
This is not tested! It's a bit dangerous to post such a code without testing, but I have not the time now.
Perhaps you need to adjust the offset adjustment. The timout is in ~10 microseconds steps (the repeat loop time).
BTW: I think there is a bug in the original rctime object at the watpeq. With state = 0 and Pin > 0 it will not work.
WAITPEQ((1-State)<<Pin, |<Pin, 0) would be better.
Andy