I2C counter OR counter + parallel/serial I2C

verobel

Fellow SXers;

Do you know if there is an I2C counter OR counter + parallel/serial I2C combination that would do the trick. For arguements sake, lets say it would be 8 bit (0-256), running off 5V. I would like to count the number of pulses from a sensor but I don't want to tie down the Stamp or SX processor.. rather just read the counts in every so often and then reset the counter. Any ideas would be appreciated. John

Doug Hale

Just use another SX chip - that is what they are for. I keep seeing request for I/O extenders - Just Use another SX for it.
Isn't that the convept of Virtual Periferals. The (maybe) small cost difference is easily offset in stocking only a few part types - not having to go look for another part type -
and in tayloring it to just exactly what you want instead of "making something work"

Mike Green

There don't seem to be any I2C based counters other than real time clocks, but those won't count external events.
Your best bet would be to use a binary counter chip and an I2C I/O Expander to read it and reset it.

On the other hand, adding a second SX might be simpler as Doug suggests.

Bean

If you're not use RTCC for anything else, just setup RTCC to count from the RTCC pin. It won't slow down the SX at all, plus you can use the prescaler too.

Just ask if you would like to see some example code and I'll whip some up.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

verobel

The MCP23016 I2C 16 bit expander is about $2 and the SN74LS90D is about $1.65.. SX/28 is $2.79 so it is cheaper. Now I would have to communicate from 1 sx to another.. Is that easy to do?

verobel

Hi Bean.. I'm currently using INTERRUPT 1000 and the Clock/Timer example code with some small mods to multiplex 6 LEDs. Can I count on the RTCC port while I'm doing that? What about SX to SX communication? Are there any examples on that?

Unfortunately, I can't read my LED display when I go outside in bright sunshine.. so I will have to switch tot LCD displaysfor this project.

Bean

verobel,
Nah the INTERRUPT will use RTCC. But depending on how fast the input pulse is that are counting you could code a counter as part of the interrupt routine.

SX to SX communications can be anything from "just connecting 8 pins from each device" to "serial (SERIN/SEROUT)".
If you use the SX48 you get two 16-bit hardware counters. That's what I would use.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com



Post Edited (Bean (Hitt Consulting)) : 11/13/2007 7:45:16 PM GMT

JonnyMac

If the pulse stream from your sensor is at less than 500 Hz you could just scan the sensor pin during the interrupt. I attached a modified version of the program that will do that on the rising edge of the sensor input pin. This is what is meant by "virtual peripheral" -- the program now has two: an RTC/timer and a counter.

Sparks-R-Fun

The SX can also be configured to immediately jump into the ISR when a Port B pin changes to the desired state. You can then have the ISR check the pin status and the value of RTCC to decide when to update the signal counter and when to process the other interrupt code.

In general, the more specific people are in describing their requirements the more specific the resulting answers seem to be. In this case, several people have offered different approaches that all seem likely to accomplish your goal. If any of them are not clear enough, just keep asking questions.

- Sparks

verobel

Thanks for all the input guys.

verobel

After reviewing Jon's code and considering that I expect pulses in the 0 tot 80 hz range, I think the slower the pulses, the more chance I will have of missing them, unless I set the DELAY_MS value large (say 800), in which case any other code in the MAIN routine might not get executed. Perhaps the external 7490 counter fed back through mcp23016 i/o expander chip would be more fool proof.

I had also thought of just interupting on every pulse and then calculating the time between pulses...but I needed the timer code for that and apparently RTCC is already in use.

The extra (independant?) counters on the SX48 sound promising but I don't have any of those chips and they don't seem to come in DIP form so how would I test stuff out on my PDB/breadboard?

Is there an 7 seg LED that is bright enough to be seen in daylight?

JonnyMac

I'm confused as to why you think you'd miss pulses. At 80 Hz -- assuming a square wave from your sensor -- you'd get 6.25 interrupts per input pulse. The VP as designed is simply a counter that will increment on pulses; you clear it when you want to restart and then read it after some specified period. Remember, you're also running at RTC VP so you could use that for timing. And if you need more counts, make the value for the sensor a word.

Post Edited (JonnyMac) : 11/14/2007 12:43:30 PM GMT

Bean

John,
It really hard to suggest things when we don't know what the sensor signal looks like.

What is the sensor ? What does it's signal look like.

Like Jon, I don't understand why you are so intent on adding extra hardware. I'd bet you a doughnut that the SX28 can do it, but we need to know exactly what the signal looks like to help you.

The whole idea of the SX is that it can most things without adding extra hardware.

If you think you will miss the pulse because it is very quick, you can use the edge latches on the portB pins. The port B pins can be setup to capture rising or falling edges. So if you get a quick rise and fall while the program is doing other things, the latch will still be set so you KNOW a pulse happened and it won't be missed.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

verobel

Hi Bean & Jon; (thanks Sparks..for ideas)

The sensor is Melexis 90217 from Parallax (magnet detection). It is mounted on a 27"
bicycle wheel near the central bearing. There are 2 magnets 180degrees apart provide
2 pulses per revolution. I don't know what the signal looks like but I speculate that
it is like a square wave with a 20% duty cyle. (as long as the magnet is in range the
pulse stays high?).

I wouldn't say that the pulses are quick, just that if they come at
the wrong time ( when interupt is running, and it runs alot ) the SX28 could miss them.

I was thinking I would miss pulses because the SX/28 could not detect pulses while it
was busy on the interupt routine. But looking at your code again, it looks like the SX
can latch a pulse, while other code is running. Then, as long as some code 'counts' the
pulse and resets the latch before the next pulse arrives, it should work ok. That code
is DELAY_MS.

If I understand Jon's extra code, it looks like the MAIN program should loop, updating
display LEDs values while the interupt routine multiplexes the display cathodes.
The MAIN calls DELAY_MS at some unknown interval ( when interupt is not running and other
code in MAIN is not running). During that time 'JNB isrFlag'
would check if say RB.0 is high and then branch somewhere where a counter could be
incremented. That counter could be inspected every so often in the main program, used
in a calculation and then reset. This seems to require input RB.0 be set to act like
a latch? I think I just need some help mixing some assembler code in SX/B to get the
job done.

respectfully, John

ps. Bean, I like the idea of doing as much as possible on one SX/28 chip (for this project)
to keep the parts count and cost as low as possible. Just show me how..

ps. Jon, If the pulse stayed high long enough wouldn't it retrigger the latch and give more than
1 count per pulse?

Sparks-R-Fun

Since I do not see JonnyMac online at the moment, I will attempt to answer this. I hope no one minds.

verobel said...
ps. Jon, If the pulse stayed high long enough wouldn't it retrigger the latch and give more than 1 count per pulse?

Actually, the Port B pins conditionally trigger and latch on pulse EDGES where the signal RISES or FALLS. Once the signal is high, resetting the latch will not cause it to trigger again until the signal falls and then begins to rise again.

- Sparks

JonnyMac

John,

You won't get more than one count per pulse with the code I gave you. Note that there is a bit variable called "lastScan" that is updated each time through. The only time the counter gets incremented is when the last scan was zero and the new scan is one; the code is looking for a low-to-high change on the sensor input line. And they can't come at the "wrong" time if you use a polled interrupt versus using edge triggered. The only thing you need to do is make sure your periodic interrupt is running fast enough to catch the pulses. Running it faster tha 1 ms won't hurt the display code at all.

How fast does your bike go?
What is the distance from the axle to the magnet placement?
What is the diameter of the magnets?

With these numbers and a calculator you should be able to estimate -- pretty reasonably -- your pulse rate and pulse width.

Sparks-R-Fun

Hey, JonnyMac…

Somehow I did not see you there. I was anxious to post! Sorry about that.

- Sparks

JonnyMac

No worries! We're all here to help each other.

verobel

Fellow Sxers;
I have added some code to the timer program to count melexis pulses on RB.7 but it doesn't seem to work. Could anyone review the code and tell me what is wrong?
Thanks, John

Bean

Try changing this code at the start of your interrupt routine from this:

  ' chk if RB.7 is latched, if so increment mCount and reset it for next pulse
  ' ** interupt routine must be running more frequently than fastest pulse **
 WKPND_B = latchB  
  latchA = latchB AND %10000000                            
 IF latchA = %10000000 THEN
   ' WKPND_B.7 = 1 THEN
   sensorCount = sensorCount + 1
   WKEN_B = %11111111                            ' reset latch
 ENDIF

·To This:

  ' chk if RB.7 is latched, if so increment mCount and reset it for next pulse
  ' ** interupt routine must be running more frequently than fastest pulse **
 latchB = 0
 WKPND_B = latchB  
 sensorCount = sensorCount + latchB.7

Bean

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com

·

verobel

Hi Bean... I tried your code. Not working properly yet but closer. I was wondering about the reset WKEN_B=%11111111 ... I still seem to need that.. or does latchB = 0 reset the latches?

I was seeing numbers flying by... or constant... but not 1 digit increment with each pass of magnet... so I hooked same signal to external counter circuit with its own display (74LS90) and then both the external counter circuit and the sx seemed to respond to the inputs better.
The external count increment exactly by one count for each magnet pass.

However, the SX rb.7 tends to give multiple counts for each magnet 'pass'. I figure sx interupt is so fast that during the time that I pass the magnet it must be resetting and setting several times till the magnet is out of the sphere of influence. Any ideas on how to fix that?

Thanks, John

verobel

.. also the SX rb.7 doesn't work properly unless signal also goes to external counter ciruit... it is like it is conditioning it somehow.. might I need a pullup resistor?

verobel

I put the pull up resistor from Vdd to output... it seems to help.. but The SX rb.7 will not detected unless the external ciruit is attached. Why is that?

Sparks-R-Fun

It sounds like you may have a signal detection problem in hardware and/or a software operation problem. I recommend connecting a simple switch in place of the sensor to see if that triggers your software in the expected way. (NOTE: You will probably need a pull up resistor on the switch. Enabling the internal pull-up for that pin on the SX should suffice. Since mechanical switches can generate a lot of “noise” when they open or close you will probably also need to debounce the input. I do not want to make this sound complicated. You can find many debounce circuits online. For the sake of experimenting, though, a simple PAUSE command to wait half a second or so once a switch event has been processed should suffice for this purpose.) Then press and release the button to see if you get one and only one count for every button press.

Basically, I think it would help to first establish that your software code works as it should. Then tackle the possibility that the hardware is not detecting the signal accurately.

- Sparks