Use Hall Effect sensors and no de-bounce routine is required. There don't have a mechanical switch, so they never bounce.... very precise. They were used in the best of computer keyboards in the early days to speed typing.
Just becareful to shop for the right variety. I think you want Unipower, non-latching.
Or use an absolute resolver .... a few external components and a dual channel ADC.
on a side note for I2C ... in some cases you can flip the Data and Clock lines and double the number I2C devices you can communicate with on a single SDA/SCL pair.... i.e. if you have two I2C devices that have the same fixed address, try flipping the SCL/SDA on just one of them.
Reed switches are notoriously bouncy. That may create problems with getting good readings of wind direction.
So because the switches go to the MCP 1st, a debounce routine in the prop software won't work (or will it). If I use a routine in the Prop code that looks for a stable output from the MCP before reading it as data it is effectively debounced. And since this particular data will change relatively slow, even a time delay after an initial change before acceptance as true data might work. I may be thinking and writing over my head but sounds good to me.
Or is there a different way to debounce the inputs to the MCP? An RC network???
Reading the data in a loop until it is stable works for me. If it does not change for 5 - 10 times through the loop then it is considered valid.
Reed switches are notoriously bouncy. That may create problems with getting good readings of wind direction.
So because the switches go to the MCP 1st, a debounce routine in the prop software won't work (or will it). If I use a routine in the Prop code that looks for a stable output from the MCP before reading it as data it is effectively debounced. And since this particular data will change relatively slow, even a time delay after an initial change before acceptance as true data might work. I may be thinking and writing over my head but sounds good to me.
Or is there a different way to debounce the inputs to the MCP? An RC network???
Reading the data in a loop until it is stable works for me. If it does not change for 5 - 10 times through the loop then it is considered valid.
I suspect there are days when the wind will change direction with every reading. When it comes to wind, flow is either smooth or turbulent. Much depends on the weather.
Reed switches are notoriously bouncy. That may create problems with getting good readings of wind direction.
So because the switches go to the MCP 1st, a debounce routine in the prop software won't work (or will it). If I use a routine in the Prop code that looks for a stable output from the MCP before reading it as data it is effectively debounced. And since this particular data will change relatively slow, even a time delay after an initial change before acceptance as true data might work. I may be thinking and writing over my head but sounds good to me.
Or is there a different way to debounce the inputs to the MCP? An RC network???
Reading the data in a loop until it is stable works for me. If it does not change for 5 - 10 times through the loop then it is considered valid.
I suspect there are days when the wind will change direction with every reading. When it comes to wind, flow is either smooth or turbulent. Much depends on the weather.
That may happen in extreme conditions, but wind vanes usually have enough inertia to allow the switch contacts to stop bouncing long enough to get a reading. Not that that getting such wildly varying readings would be all that much use except possibly for reporting a range of wind directions.
Debounce is easy, just accept the first transition, apply a timeout and then continue. If the scan period is fairly slow then this will normally suffice for debounce, no need for a timeout. If the signal is still active it won't be accepted because it is not a transition. The software for transition detection simply maintains a copy of the last sample read which is compared with the latest sample, if there is a difference then you can process those make and break changes as you like.
It is also not a bad idea to use a small cap up to 0.1uf across the cap switch to give it some "wetting current" and this also helps to debounce it quite nicely in conjunction with pull-up resistors.
For mechanical type switches, debounce is easy in most cases. Just read several times in a row to be sure.
If ina[pin1] == 1
waitcnt(1_000_000)
If ina[pin1] == 1
' there is an input to act on
Same idea applies to I2C reads if you think you need it. If there cannot be allowed more then one switch at a time, you can use case statements on the I2C read and that will ignore any dual triggered switches.
CASE InputStatus
%00000001 : 'switch 1 active, do something
%00000010 : 'switch 2 active, do something
" " " "
%10000000 : 'switch 8 active, do something
I2C I/O expander such as the MCP23017 using P28,P29 which is already connected to the EEPROM = zero I/O = absolute "least pins"
Indeed. There's a lot of interesting suggestions in this thread, but -- in my opinion -- an I2C device connected to the EEPROM buss as Peter suggests is the most practical. May be the easiest, too.
I just got my own bare bones MCP23017 object working this morning using bits and pieces of your's and other code. I haven't received the reed switches yet so substituted a 8 pole DIP switch to experiment with. Next I'll try to write a CASE method to display the proper wind direction according to the switch inputs.
Comments
Just becareful to shop for the right variety. I think you want Unipower, non-latching.
https://www.jameco.com/Jameco/electronic-products/hall-effect-sensor.html
The shaft of the wind direction finder would just have a tiny magnet attached to the one position (where it points).
on a side note for I2C ... in some cases you can flip the Data and Clock lines and double the number I2C devices you can communicate with on a single SDA/SCL pair.... i.e. if you have two I2C devices that have the same fixed address, try flipping the SCL/SDA on just one of them.
Resolver Video:
Reading the data in a loop until it is stable works for me. If it does not change for 5 - 10 times through the loop then it is considered valid.
I suspect there are days when the wind will change direction with every reading. When it comes to wind, flow is either smooth or turbulent. Much depends on the weather.
That may happen in extreme conditions, but wind vanes usually have enough inertia to allow the switch contacts to stop bouncing long enough to get a reading. Not that that getting such wildly varying readings would be all that much use except possibly for reporting a range of wind directions.
It is also not a bad idea to use a small cap up to 0.1uf across the cap switch to give it some "wetting current" and this also helps to debounce it quite nicely in conjunction with pull-up resistors.
If ina[pin1] == 1 waitcnt(1_000_000) If ina[pin1] == 1 ' there is an input to act onSame idea applies to I2C reads if you think you need it. If there cannot be allowed more then one switch at a time, you can use case statements on the I2C read and that will ignore any dual triggered switches.CASE InputStatus %00000001 : 'switch 1 active, do something %00000010 : 'switch 2 active, do something " " " " %10000000 : 'switch 8 active, do somethingIndeed. There's a lot of interesting suggestions in this thread, but -- in my opinion -- an I2C device connected to the EEPROM buss as Peter suggests is the most practical. May be the easiest, too.
I really like the MCP23017. I've attached my latest objects (MCP23017 plus child I2C object) for your convenience.
Tip: My I2C object requires pull-ups on SDA and SCL.
I just got my own bare bones MCP23017 object working this morning using bits and pieces of your's and other code. I haven't received the reed switches yet so substituted a 8 pole DIP switch to experiment with. Next I'll try to write a CASE method to display the proper wind direction according to the switch inputs.
Aaron