Frequency detection IC with Serial Interface?

[jwhitmore]

I'm trying to design an expansion board for a RaspberryPi which will include frequency detection. Because the RPi is busy running a full OS I decided that the best solution was have a dedicated chip detect the frequency and then have the RPi read it back. For that I needed a serial interface, of some sort. So I found the LS7366R [1] but I've not been able to source it from a supplier. So having found that one finding a similar alternative is proving quite difficult. Does anybody know of a suitable chip?

[1] https://lsicsi.com/datasheets/LS7366R.pdf

[Benta]

What exactly do you mean by "frequency detection"? I have problems visualizing how this applies to a quadrature counter.

[jwhitmore]

Oops sorry should have been clearer. There's a diagnostic port on a Vehicle I'm faffing about on, one of the pins is a square wave which comes from the alternator. That square wave is proportional to the current engine speed. I was thinking of using a counter to count the pulses over a period of time to calculate the engine speed. A microcontroller, (one of those 3 cent ones would do the trick) but though There might be something generic I could use.

[technix]

You can grab a cheap microcontroller like ATtiny44A, PIC16F72 or STM32F030F4P6 and implement a frequency counter in there.

[CJay]

There's a few projects out there which use microcontrollers, but as the speed of the engine will change quite a lot it's going to be difficult to measure a simple frequency as most will have gate times which are too long to be useful in the KHz (at best) range, it's better to measure the period between the pulses and average it over a set amount of time, you need to accept that it's not going to be accurate.

If the vehicle is OBD-2 equipped you may be better served by something like an ELM chip which can connect to the OBD bus and should be able to extract the RPM data from the ECU in real time.

https://en.wikipedia.org/wiki/ELM327

Frequency counters:

http://www.linuxfocus.org/English/September2002/article253.shtml
http://panteltje.com/panteltje/pic/freq_pic/

[jwhitmore]

I'm afraid there's no OBD on this vehicle and I guess there ain't an easy solution. Thanks so much for the links and the help. I'll go and have a look at the parts I have and see if I've a uC that'll do the job.

Thanks again.

[GeorgeOfTheJungle]

The signal surely is a few kHz at most, right? A separate chip is fine, but a gpio and interrupts is all you really need to do that. Most of the trouble is going to be proper signal conditioning.

[mikeselectricstuff]

Pretty much any microcontroller can do this. Interface to RasPi could be I2C, SPI or UART

[technix]

Pretty much any microcontroller can do this. Interface to RasPi could be I2C, SPI or UART

That is what I was talking about. It doesn’t even have to be those name brand products like ATtiny44, PIC16F72 or STM32F030F4, those cheapies like STC15W102 (8051-based,) GD32F130F6 (ARM Cortex-M3 based,) and that 3-cent OTP chip would all suffice really well too

[GeorgeOfTheJungle]

RPi max interrupt latency is going to be 500 µs only very rarely, most of the time below 50µs, could filter that out in software easily.

https://medium.com/@metebalci/latency-of-raspberry-pi-3-on-standard-and-real-time-linux-4-9-kernel-2d9c20704495#2b45

[jwhitmore]

I have a PIC16F sitting in a drawer so that's going to be my target device.

I'm glad somebody asked about signal conditioning. The signal is obviously a nominal 12V signal, and yes I'd image a few kHz at most. I was thinking for signal conditioning that the easy answer to that is an Opto coupler to isolate the 12V. I've never used an Opto coupler and not that I think they are difficult or anything but I wonder is there a jelly bean part that a number of manufacturers make and has a standard footprint? That could start a heated debate but thought I'd ask. I suppose if I look at digikey there'll be one that's stocked in huge numbers or something.

On the RPI interface side I'll do an SPI interface or I2C and have the RPi poll for updates. Every second should be more then enough of an update rate for the RPi.

[technix]

I have a PIC16F sitting in a drawer so that's going to be my target device.

I'm glad somebody asked about signal conditioning. The signal is obviously a nominal 12V signal, and yes I'd image a few kHz at most. I was thinking for signal conditioning that the easy answer to that is an Opto coupler to isolate the 12V. I've never used an Opto coupler and not that I think they are difficult or anything but I wonder is there a jelly bean part that a number of manufacturers make and has a standard footprint? That could start a heated debate but thought I'd ask. I suppose if I look at digikey there'll be one that's stocked in huge numbers or something.

On the RPI interface side I'll do an SPI interface or I2C and have the RPi poll for updates. Every second should be more then enough of an update rate for the RPi.

Depending on how busy the Pi is, you can even throw some more work on the MCU, especially if you also add in an interrupt line from the MCU to the Pi. For example the MCU can monitor the signal and interruptthe Pi if the signal value go out of a certain threshold from the last value the Pi read. Now the Pi can mind its business without polling the signal, and only read the data when the MCU alerts it through that interrupt line.

[texaspyro]

Google PICPET.  This is a family of dirt cheap time stamping interval counter chips.  Each pulse in is time stamped and sent out a serial port (sub microsecond resolution).  It can handle inputs up to 100 Hz, so you will probably need a divider on the input... maybe one of his PICDIV chips will be suitable.

[jwhitmore]

Whilst I like your idea, of using interrupts, I think I'll leave it for this iteration. I'm combining both my frequency counter and a CAN Bus module (MCP2515) onto the RPi SPI Interface. The MCP2515 will be connected to the RPi interrupt line so I think I'll make it simple and have the frequency polled. Perhaps you can have two devices on the one RPi interrupt line, I'd have to get into that and do some research. For the moment I'll just poll it.

[technix]

Whilst I like your idea, of using interrupts, I think I'll leave it for this iteration. I'm combining both my frequency counter and a CAN Bus module (MCP2515) onto the RPi SPI Interface. The MCP2515 will be connected to the RPi interrupt line so I think I'll make it simple and have the frequency polled. Perhaps you can have two devices on the one RPi interrupt line, I'd have to get into that and do some research. For the moment I'll just poll it.

You can have multiple interrupt lines - every GPIO pin on the Pi is individually interruptible. You have two separate GPIO pins for interrupt, and use two separate ISR's for those.