Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Handling Multiple sensors at same time

Status
Not open for further replies.

radnusmar

Member level 1
Member level 1
Joined
Apr 19, 2010
Messages
32
Helped
5
Reputation
10
Reaction score
5
Trophy points
1,288
Location
Chennai
Activity points
1,466
Hello Everyone..

I have a situation to get time period digital signals from a I/O line. I am fetching time period of the signals using Timer module and Capture module and having acquisition time of 100ms . I am able to successfully get the time period of signal one sensor exactly. I need to interface 8-15 such sensors and acquire time period of each sensor.

I need some suggestion to acquire all sensors data in parallel or virtually parallel.I cant multiplex digital lines and fetch(time constraints), as I need the sensors data in parallel. I am using PIC MCU's. Should I go for FPGA's for this situation?

I am confused. Help me out...:-:)-:)-(
 

A pic (or any micro) can only do one thing at a time; an FPGA can do many things simultaneously. However, you still might be able to measure 15 sensors 'accurately enough' with a micro.

Question: How accurate is accurate? Can you tolerate a 1-second error? How about 1 ms? I'm not sure about the exact details of the PIC you are using, but I believe you can set inputs to act as interrupts. Maybe you can force an interrupt when an input changes state, and capture the time that way. Or poll the inputs. "100mS sounds like a long time for doing your acquisition. "

If you need, say, 1mS resolution, you could have your main software loop running at a 1mS rate, and each time through the loop sample your inputs and determine if any have timed out.
 

Barry is idea is really good ....but there is one more way to do it using RTOS also where you can have task getting executed after every 100ms ....

Refer - https://www.freertos.org/a00090.html#MICROCHIP

but this is bit more resource oriented so you mostly needing the higher micro-controller family...

Good Luck
 

I am developing a safety critical application. The time taken should be most minimum. Am using pic18f series. I read about PSOC's having programmable digital blocks.
 

I haven't used the PSOCs, and the software looks pretty cool, but when you get right down to it, they are still just microprocessors. I'd like to use one, but I guess I haven't found the right application yet. I would think the PIC could do the job, depending on what else it has to do.
 

I am developing a safety critical application. The time taken should be most minimum. Am using pic18f series. I read about PSOC's having programmable digital blocks.

some PIC24 devices have 9 input capture peripherals, e.g. PIC24FJ256GA110
more than that is a problem
 

Maybe you can use external counters to do this. Something like, you can have 14 external counters were all are enabled at once and then after 100ms disable all the counters later retrieve the counter values of all the 14 counters. But I'm not sure of that, just a guess.
 

I haven't used the PSOCs, and the software looks pretty cool, but when you get right down to it, they are still just microprocessors.

Well, I have to respectfully disagree. Have you ever seen a microprocessor that can control several fans with real-time response to temperature changes while the CPU is sleeping? - I have :)
It was a PSoC FAN Controller and it can be programmed as a complete hardware implementation. If you check out the so called components, pre-programmed peripherals that can often interact with each other without using any CPU, you will eventually find that a PSoC can do things that standard micros can't do.

To get an easy start just watching a couple more or less amusing videos you can try PSoC Today, a TV-like show broadcasted by Cypress.
 

Well, I have to respectfully disagree. Have you ever seen a microprocessor that can control several fans with real-time response to temperature changes while the CPU is sleeping? - I have :)
It was a PSoC FAN Controller and it can be programmed as a complete hardware implementation. If you check out the so called components, pre-programmed peripherals that can often interact with each other without using any CPU, you will eventually find that a PSoC can do things that standard micros can't do.

To get an easy start just watching a couple more or less amusing videos you can try PSoC Today, a TV-like show broadcasted by Cypress.

If the device is controlling fans, or whatever, it's not sleeping, is it? You wouldn't work for Cypress, would you? If you want to quibble over semantics, ok, the PSOC is not just a microprocessor, but neither is the PIC or the Atmel AVR; they all have counters, ADCs, DACs, PWM etc.
Still, I AM intrigued by the PSOC.
 

If the device is controlling fans, or whatever, it's not sleeping, is it? You wouldn't work for Cypress, would you? If you want to quibble over semantics, ok, the PSOC is not just a microprocessor, but neither is the PIC or the Atmel AVR; they all have counters, ADCs, DACs, PWM etc.
Still, I AM intrigued by the PSOC.

Hi Barry,
not just semantics. The CPU! = the core is in sleep mode while the fan controller still works. It is not just about timers, counters... not just about being an MCU, it is about having programmable logic and programmable analog that can execute control algorithms without the CPU running any code.
My background is very much about MCUs and there is little doubt that MCUs can do most things as long as the programmer is smart enough :) Nevertheless, using a core to perform control functions will always get you into the priority assignment and if you do not assign the highest priority into jitter issues. If you can control by hardware, no jitter, "things just happen as they are supposed to" and do not care if an interrupt doesn't have enough priority and kill your power transistor.
btw. I used the wrong wording comparing PSoC to a "microprocessor", I should have compared it to a "microcontroller" because there is a huge difference between MCU and MPU as we both know.
 

Another option is IO Extender
I2C/SPI MCP23S17 /MCP23017

MCP23017-FunctionalBlockdiagram.jpg

**broken link removed**
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top