Multitasking confusion

[Andrew Cowan]

My A level electronics project is a radio controlled search and rescue robot, equipped with lots of sensors. I have 458MHz 100mW (radiometrix) radio link sending data from the robot, with a packet being sent every second. This has about 20 variables.

I am currently designing the PCBs for the other end of the radio link. I have a GLCD with a touchscreen, which sends a serial announcement when pressed. I need to continuously monitor for these, and then change the touchscreen or send the appropriate data across the radio.

However, I also need to monitor the radio. I haven't ordered the PICAXE/s yet, but my current design has the radio connected to the hserin pin. The touch screen is then connected to a pin which is scanned for an interrupt. With no touches, the code keeps the screen updated with the values coming in through hserin. However, when the screen is pressed, the interrupt is triggered, and the PICAXE does the appropriate action. It then goes back to updating the screen.

Is this the best way to do this? I considered connecting the touchscreen input to another PICAXE, which then puts an output high to tell the main PICAXE there is a command. The main PICAXE would then ask what the input was, and the other PICAXE would send across the data. Is this a better way of doing it?

Thanks for any input!

Andrew


Many thanks to Radiometrix and Matrix Orbital for their support with this project!

 

[inglewoodpete]

Andrew, Just reading your description of the project suggest to me that you are on top of things already. Judging by the things you expect the PICAXE to do, you will need an X1 or X2 but I suspect you are already on that path.

The choice of PICAXE will come down to the base load of the work to be done and the impact of inputs (Eg How often and how much extra processing is required for each event). The size of the PICAXE (20, 28 or 40 Pins) will depend on the number and combination of inputs and outputs you expect to have. Its always handy in a development environment to have an extra couple of outputs for status LEDs.

Depending on the criteria of the project, even if your submitted solution falls short of its objectives, most examiners are also looking for a discussion on where and how improvements can be made: a demonstration of your understanding of it. Even to the point where, for instance, you use a 40x2 but in your conclusions recommend a 28x1, determined by your results.

Good luck with your project/assignment. I wish there were microcontrollers around when I was in secondary school!

 

[Dippy]

I would have thought you need to plan priorities.

The 'other end' I assume is your Remote Control unit.

Does the RC give priority to radio data received?
Does it matter if a t/s generated interrupt causes a brief loss of one lot/packet of RF Data?
I don't know which RF module you are using, does it have a buffer and 'Data Ready' output?
Interrupts should be used with care.

If any data loss is important I'd be tempted to go for your second idea.
Setting a pin high and then the Main PICAXE polling it (when ready) would ensure no data is lost anywhere. If it's possible to do nice tight/fast loops then interrupts wouldn't be needed.
The 'buffer' touchscreen PICAXE could also store all the code for fancy GLCD driving - leaving the main PICAXE to do the main/fast stuff.

If it isn't important then I'd go for the single PICAXE approach.

And the last thought; will all your code and any future development fit into a single PICAXE?

 

[Andrew Cowan]

Thanks for the replies.

I'm using a seperate system to control the robot - this is just to receive data. Thanking about it more, I am also swaying towards a two PICAXE approach.

I think I'll use a 20X2 to receive the data, and an 08M to buffer the touchscreen info.

Missing a set of data isn't too important, although I'd rather it didn't miss any. The data updated once per second is:
Voltage, Current, CO2 levels, LPG levels, PIR detection (analogue), Motor A temperature, Motor B temperature, ambient temperature, light levels, Motor A speed, Motor B speed, 'Ultrasonic radar' data (angle & distance), possibly audio levels, gradient (accelarometer), RSSI, GPS position.

This will all be displayed on the gLCD, along with the receiver's battery voltage, charge status etc.

The main PICAXE (20X2) will have to handle the battery charging as well, so the les it has to do, the better!

Thanks for the contributions.

Andrew

 

[boriz]

I rarely use interrupts. It’s just a polled interrupt anyway (If there is such a thing). Usually I’m satisfied with something like:

Do
	Check for this and maybe gosub here
	Check for that and maybe gosub there
	Check for other and maybe gosub somewhere
Loop

Which can be expanded to a kind of time-share system:

Do
	Inc timer
	If timer=this then gosub here
	If timer=that then gosub there
	Etc..
Loop

Or better:

Do
	Inc timer
	Select timer
	Case this:gosub here
	Case that:gosub there
	Etc..
	endselect
loop

Which can be extended for different polling speeds:

Do
	Inc timer
	Temp=timer%2:If temp=0 then gosub here
	Temp=timer%10:If temp=0 then gosub there
	Temp=timer%100:If temp=0 then gosub somewhere
Loop
End

Here:
‘executed once every two loops
Return

There:
‘executed once every 10 loops, 5 times less often than Here
Return

Somewhere:
‘executed once every 100 loops, 50 times less often than Here
return