Go Down

Topic: Is this too big for ISR ? (Read 6189 times) previous topic - next topic


Are you using String? I wouldn't. And in any case you are still sending the same stuff.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


Code: [Select]
temp = getTemperature(tmp);
  Fldtemp = getTemperature(Fluidtmp);

What device are you getting the temperature of, that changes 1000 times a second?

You can read the analog ports asynchronously.


Scroll down to: "Read the Analog-to-Digital converter asynchronously"
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


I would separate the reading of sensors from communicating their values.
i.e. use the ISR just to communicate the most recent sensor readings.
Then do the reading of sensors somewhere else.
Store the sensor values in some volatile globals and then use the ISR to slam
out the most recent readings.

Either that or depending on how fast the data readings really change, only communicate
the changes to the data vs the actual data.
This could dramatically reduce the amount of data transfered.

But since you have not described the overall system and its real needs or what
else might be going on in the foreground it is pretty difficult to make suggestions.

The big concern I have over using a serial port interface like this particularly at
a high data rate is that there does not appear to be any sync sequence or checksum on the data.
So if there is ever dropped character because of noise on the line, the two
ends would be hopelessly out of sync with each other and the receiver would
be "seeing" totally garbage information.

--- bill


@ Nick Gammon:
Thank you for the info on your website.
The temperature change of my system is like this: room temp to 100 deg C and back down to room temp in under 500 ms... as you can see I really need to capture and send this data.

@ bperrybap:
I did what you suggested in other way around: readings in ISR and sending in the loop. I will definitely experiment with your suggestion.

Thank you


I think you are asking a bit much out of an Arduino. Something like this from NI might work better, and give you some margin:


Thanks for the suggestion Keith, BUT please tell me you have looked at the price...
By the way, I was kind of considering to get this: http://sine.ni.com/nips/cds/view/p/lang/en/nid/209277



"Pete, it's a fool (who) looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.
I speak for myself, not Arduino.


@ bperrybap:
I did what you suggested in other way around: readings in ISR and sending in the loop. I will definitely experiment with your suggestion.

It depends on how you want to "clock" the sending of the sampled data.
If you send the sampled data readings from the ISR then it will be sent at specific
time intervals regardless of how often the actual real samples are done.
If you send the data in the foreground, then more than likely the messages sending the sampled
data will not be on specific time intervals, while the ISR is updating the contents of
what is being sent at the specific time interval.

Worst case, is that the foreground is hammering out messages much more often than the
data is being sampled. (Although you could add extra code to ensure that messages only
were sent out at specific intervals)

But if the messages don't have to be on any specific timing then why bother
with an ISR? Just sample the data and send it as fast as you can.

I tend to think the other way around. Sample the data as needed or as fast as you can
and essentially maintain a "cache" of the sampled readings.
The ISR then pushes this "cache" to a receiver on periodic intervals
or sets some flag to tell the foreground to send all the accumulated samples.

Another option would be to sample each sensor and send its value immediately
after sampling slowly building up the full message as you go.

There are many ways to skin the cat.

BTW, if your receiver is a HOST with USB support, you could switch something like
a Teensy board which would allow you push serial messages over native USB at USB speed
instead of at TTL serial BAUD rate speeds.
(baud rate is ignored when using serial over native USB).

Again, it would be useful to have more information about your overall system goals/needs
to be able to make suggestions of how to attack the problems, as perhaps some
of them might go away by considering alternate approaches.

--- bill


Oct 11, 2012, 09:47 pm Last Edit: Oct 12, 2012, 05:54 pm by FardinB Reason: 1
@ bperrybap:

Thank you very much for your response.
Here is a description of overall system:
first I switch a hydraulic valve, then I drive a "motor" for 300 to 500 ms. This motor is not a conventional motor and its temperature changes from room to 100 deg C during power on and then back down to room temp. This is why I need a fast DAQ. During the time when the motor is being driven, I have to monitor 5 sensor: PressureSensor, LinearSensor, PressureSwitch, MotorTemp, and FluidTemp. I have to monitor these sensor on a millisecond period. There are also some control structure here which makes the system complicated a bit.
- The system gets activated by a pushbotton.
- before driving the system I have to checkLimits. this means check that pressure, linear and motor temperature are below their max value. These sensors all have analogRead functions.
- Once everything is normal (no max detected), I drive the motor. datalogging starts here for all sensors on a ms period.
- during a timed system drive of 300 to 500 ms, I have to checkLimits continuously, to make sure the sensor values do not go over their max values.
- at some point either the timed driving is going to end or the sensor will cause the system drive to stop.
- after this I have to datalog for 3 more seconds

Code snipets:
This is checkLimits:
Code: [Select]

int checkLimits() {
if( getTemperature(tmp) >= MAXtmp )
    return 0;
 } else if( analogRead(Psensor) >= MAXpressure )
   return 0;
 else if( analogRead(Lsensor) >= MAXdistance )
   return 0;
 } else { return 1; }

This is for timed while loop:
Code: [Select]

unsigned long i = millis() + MAXtime;
while( i >= millis() )
  // timed code here
  // Ckeck Limits
  if(checkLimits() == 0) { break; }

Please give ideas on how to do all this.


Go Up