View unanswered posts | View active topics It is currently Mon Jun 26, 2017 10:06 am

Reply to topic  [ 2 posts ] 
Interrupts Anyone? 
Author Message

Joined: Tue Apr 03, 2007 12:43 am
Posts: 1
Post Interrupts Anyone?
I picked RobotC largely because a review I saw said it allowed interrupt driven programming. I haven't been able to find any examples of , or doumentation on interrupt handlers. At the moment I would just like to have a interrupt service routine that would set a flag anytime the sonar sensor value goes below a certain level. I'm trying to avoid polling the sensor if posible. any suggestions?

Tue Apr 03, 2007 1:00 am

Joined: Fri Feb 09, 2007 9:21 am
Posts: 616
I'm not sure what review stated it allowed user written interrupt driven processing. It doesn't and you probably wouldn't want to write them unless you're a embedded systems GURU.

In general, hardware interrupts are usually triggered when a digital value (i.e. a binary 1 or 0) changes state or a hardware timer has reached a certain value. You will not find any hardware system that will perform the request that you described; namely, “cause an interrupt when a specific threshold is achieved in the data field in a message received on a I2C communications channel”. And, somehow the firmware will still have to be running to actually perform the background I2C message polling.

But I think your request is probably a request for how to use “events”. Within RobotC you can define events on sensor values based on threshold. For example: (1) signal event when value is over (or under) a threshold, (2) signal event when value is between two thresholds. You can then write code for each of your user defined events that will only be started when an event is signaled.

RobotC runs on many platforms including the NXT and RCX. The RCX is a relatively slow 8-bit CPU and it simply didn’t have enough CPU real time tocheck for many events in a tight loop using the interpretative VM language defined by LEGO. RobotC on the NXT has a superset VM [Virtual Machine] that executes over 500 times faster the LEGO’s standard RCX firmware. There’s ample real-time to check in RobotC code for the event threshold rather than setting up the definitions and having RobotC’s VM do it in background.

So, on the NXT, I would not recommend using events. They are more complicated to use than” regular” RobotC code to check for thresholds.

You did make the right decision in going with RobotC. It has numerous enhancements that you won’t find in any of the competing environments. A few of the items related to your “problem” include.
• Best in class execution performance. Anywhere from 2 to 80 times faster than the various alternative environments.
• Very easy to use multi-tasking. By definition your “problem” has a requirement for multi-tasking. Tasks (or threads) can be individually started and stopped at any time.
• wait” statements do not consume CPU time during wait. This is important for multi-tasking environment. In the NXT-G firmware, waiting tasks consume just as much CPU time as executing tasks – although NXT-G calls them “clumps” instead of tasks and does not have the same start/stop flexibility.
• Automatic polling, in background, of the ultrasonic/Sonar sensor. In NXT-G derived languages the user program needs to perform the background polling of the sonar sensor.

Tue Apr 03, 2007 8:46 am
Display posts from previous:  Sort by  
Reply to topic   [ 2 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.