how can i make a program react faster?

[Digisapien]

ive been working on my first real project ever THANKS TO ALL THE HELP FROM EVERYONE IVE LEARNED A LOT!!!
however...I have tweaked and tweaked, even used parallel processing to help search for inputs faster and respond and it worked.
still.... I want my temperature measurement to react much faster then what it is....now it reads temp at about once per three seconds. Now i have tweaked the pauses in this code for the last three hours... if i drop anything down the way its written the lcd bugs out cuz it doesnt have time to load information. but im guessing theres a way cuz there has to be. perhaps im using the wrong chip? 08m2 is what i got now..

start0:	
	readtemp c.1,b0 'store temp
	b0 = b0*9/5+32  'convert to farenheit
			
	serout c.0,n2400,(2)'Ambient
	pause 50	
	serout c.0,n2400,(254,201,#b0,"    ")
	pause 50

	serout c.0,n2400,(1)'temp1
	pause 50	
	serout c.0,n2400,(254,135,#b1,"    ")	
	pause 1500
	
	serout c.0,n2400,(3)'temp2
      pause 50	
	serout c.0,n2400,(254,135,#b2,"    ")
	pause 1000		
	goto start0		
start1:	
	if pinc.3 = 1 then 
	goto Flash	
	end if
	if pinc.2 = 1 then
	goto Flash2
	end if
	goto start1
Flash:
	high b.4
	let b1 = b0
	pause 200
	low b.4
	goto start1
Flash2:
	high b.4
	let b2 = b0
	pause 200
	low b.4
	goto start1
	
	#rem
init: pause 500
main:
	serout c.0,n2400,(253,1,"Temp1=           ")
	pause 1000
	serout c.0,n2400,(253,2,"AmbTemp=         ")
	pause 1000
	serout c.0,n2400,(253,3,"Temp2=            ")
	pause 1000
	end
	#endrem

 

[Digisapien]

BTW cant wait to finish this project ive decided to try something different for my project boxes....ive purchased thick plexiglass and am hoping it is going to save me some money on all purchased cased over the years...mainly I never actually get one to what i want size wise. And I think its going to look cool. so cant wait to post that when im done

 

[BeanieBots]

That's about as fast as you will ever get it if you are using DS18B20 temperature sensors and the ReadTemp command.
They take about 750mS to take a reading.
If you use a chip that supports one-wire commands you could start all the sensors at the same time. Do all the serial stuff while it converts (using the previous reading) and then wait for the end of conversion before looping again.
Such an approach should get the update time down to about 750mS.

Alternatively, use a different type of sensor.

 

[oracacle]

it will be more helpful for us if we had a full schematic, and a full program - i personally cant see where the value in b1 and b2 are coming from

 

[neiltechspec]

A side issue, shouldn't you be using a word variable for the deg F conversion.

The way I understand picaxe maths is it does it sequentially - b0 multiply by 9 then divide by 5 then add 32

Bytes are 8 bits which means b0 max value is 255, so when you multiply by 9, the max value can only be 28 deg c before it busts the 255.

Someone correct me if I'm wrong.

Neil.

 

[oracacle]

yeh that would seem correct, however run this in the simultor and see if the result match.

[color=Black]init:
      [/color][color=Blue]let [/color][color=Purple]b0 [/color][color=DarkCyan]= [/color][color=Navy]28[/color]
[color=Black]main:
      [/color][color=Blue]let [/color][color=Purple]w1 [/color][color=DarkCyan]= [/color][color=Purple]b0[/color][color=DarkCyan]*[/color][color=Navy]9[/color][color=DarkCyan]/[/color][color=Navy]5[/color][color=DarkCyan]+[/color][color=Navy]32  [/color][color=Green]'convert to farenheit
      [/color][color=Blue]let [/color][color=Purple]b1 [/color][color=DarkCyan]= [/color][color=Purple]b0[/color][color=DarkCyan]*[/color][color=Navy]9[/color][color=DarkCyan]/[/color][color=Navy]5[/color][color=DarkCyan]+[/color][color=Navy]32  [/color][color=Green]'convert to farenheit
      [/color][color=Blue]debug
      pause [/color][color=Navy]500
      [/color][color=Blue]inc [/color][color=Purple]b0
      [/color][color=Blue]goto [/color][color=Black]main[/color]

this will simulate an increasing temputature that is read into b0, than does the maths into b1 and w1 to checck if the results correlate and are correct.

 

[westaust55]

As an extension of the post by Beaniebots above, if you use an X1 or X2 part then you have access to the core 1-Wire commands to directly access a 1-Wire network
With a DS18B20 set for 9-bit mode then the temp conversion time is down to 93 ms.

As BB suggests, if there are multiple DS18B20 chips they can all be directed to commence a temp conversion at the same time and then after the requisite time (or by polling) read back the temperature data. This can keep the overall time down and it would be possible for the PICAXE to perform other functions/commands between issue of the DS18B20 Tconvert command and reading back the temperature data.

That 95 ms is sufficient time to execute somewherw in the order of 350 PICAXE BASIC commands in the intervening time.

There is some such code in the 1-Wire network thread I posted in the past should the OP be interested in following that path.

 

[hippy]

Now i have tweaked the pauses in this code for the last three hours... if i drop anything down the way its written the lcd bugs out cuz it doesnt have time to load information.

There should not be a need to add one or one-and-a-half second delays after writing data to the LCD to prevent corruption and it would be worth investigating and resolving that first.

 

[techElder]

Does your temperature really change that fast?

 

[Digisapien]

it will be more helpful for us if we had a full schematic, and a full program - i personally cant see where the value in b1 and b2 are coming from

"schematic is kinda funny........ cuz i been winging this like a bat in a round box. heck theres been 20 different variations so far..lol

 

[lbenson]

A side issue, shouldn't you be using a word variable for the deg F conversion.

The way I understand picaxe maths is it does it sequentially - b0 multiply by 9 then divide by 5 then add 32

Bytes are 8 bits which means b0 max value is 255, so when you multiply by 9, the max value can only be 28 deg c before it busts the 255.

Someone correct me if I'm wrong.

Neil.

While you are right that multiplying the temperature by 9 could result in an answer greater than the 255 which a byte can hold, picaxe calculations are done with 16-bit math internally, so you only have a problem if the final result which you want to put into b0 exceeds 255 (or an internal intermediate result exceeds 65,535, giving an overflow, or would be less than 0, giving an underflow).

 

[Digisapien]

"just did a coffee test. Its fine. just hit 99 celsius. no prob store up to 255 in the final b0 var'

 

[Digisapien]

Well what sucks is i did some research an found that the ds18b0 is more accurate then any of the others? and I bought three. lol when using short code i dont get the lag so bad and quite happy but its the code thats killing me. its adds to the return time reading the sensor.....but i know from experience i dont like typical thermistors any transistor based sensor im not thinking about be glad to switch i guess?

 

[Digisapien]

The temperature is changing ( in the code as it stands at 3 second intervals )
However ..... happy to say the button input is instantaneous .

 

[Digisapien]

There should not be a need to add one or one-and-a-half second delays after writing data to the LCD to prevent corruption and it would be worth investigating and resolving that first.

"you my man are hitting the nail on the head......... i dont know why im having to have such delays but I have played with it with much less and in between....without that delay it bugs out"

 

[westaust55]

A side issue, shouldn't you be using a word variable for the deg F conversion.

The way I understand picaxe maths is it does it sequentially - b0 multiply by 9 then divide by 5 then add 32

Bytes are 8 bits which means b0 max value is 255, so when you multiply by 9, the max value can only be 28 deg c before it busts the 255.

Someone correct me if I'm wrong.

Neil.

Internally the PICAXE works with 16 bit maths irrespective of whether byte or word variables are involved.
So a value of up to 255 multiplied by up to 255 (=65535) does not result in overflow internally as long as the final value is < 256 for a byte variable result.

 

[Digisapien]

As an extension of the post by Beaniebots above, if you use an X1 or X2 part then you have access to the core 1-Wire commands to directly access a 1-Wire network
With a DS18B20 set for 9-bit mode then the temp conversion time is down to 93 ms.

As BB suggests, if there are multiple DS18B20 chips they can all be directed to commence a temp conversion at the same time and then after the requisite time (or by polling) read back the temperature data. This can keep the overall time down and it would be possible for the PICAXE to perform other functions/commands between issue of the DS18B20 Tconvert command and reading back the temperature data.

That 95 ms is sufficient time to execute somewherw in the order of 350 PICAXE BASIC commands in the intervening time.

There is some such code in the 1-Wire network thread I posted in the past should the OP be interested in following that path.

Okay,hopefully you can help me with this. Right now the Temp1 and Temp2 displays use the same line on the top, flip flopping every second
to display the outcome. I've tried using placement such as serout c.0,(254,133,#b0,141,#b0) etc if I could use the top line to display both the Tmp1=XXXTmp2XXX this would be great but ive played with it and i cant figure it out

 

[hippy]

I've tried using placement such as serout c.0,(254,133,#b0,141,#b0) etc

Perhaps you are just missing a 254 ...

serout c.0,(254,133,#b0,254,141,#b0)

 

[Digisapien]

Okay..... did some reading....and for those that read my code. I used parallel processing to increase the speed of the pushbutton being read.
This may have been a failure.... PASTE FROM MANUAL:
Commands that require total core processing to maintain critical timing integrity
(e.g. readtemp, sertxd, debug, serin, irin etc.) will ‘block’ the parallel tasking until
that command has finished/timed out. Therefore the other tasks will appear to
momentarily ‘hang’ during the processing of that command.
Due to the task cycling the timing between each command in a particular task
cannot be guaranteed, because different length commands within the other tasks
will be processed in the interval. This also means that the accuracy of pause
commands will be slightly decreased.

 

[Digisapien]

Well I hate this but seems I had to kick the parallel processing. so I'm stuck with this right back to the slow reacting button press...the parallel processing worked but when using analog sensors it does not work properly.....too much time lag on temp read

'Stupid slow way of doing this but necessary
'Using one Temp probe, one led , one Lcd , and two buttons
'predefined message stored in lcd (1)&(2)&(3)

init: pause 500
main:
	readtemp c.1,w0 'store temp from probe into var' w0
	w0 = w0*9/5+32  'convert to farenheit
	pause 100
	
	if pinc.3 = 1 then flash1 'hold button for abnormal time	
	if pinc.2 = 1 then flash2 
	
	serout c.0,n2400,(1)    'output to lcd		  
	pause 10	
	serout c.0,n2400,(254,135,#w2,"  ")
	wait 1
	serout c.0,n2400,(3)
      pause 10	
	serout c.0,n2400,(254,135,#w4,"  ")
	pause 500	
	serout c.0,n2400,(2)
	pause 10
	serout c.0,n2400,(254,201,#w0,"  ")
	goto main
Flash1:
	w2 = w0 
	high b.4 'flash led
	pause 200
	low b.4	
	goto main
Flash2:
	w4 = w0
	high b.4 'flash led
	pause 200
	low b.4
	goto main

 

[Digisapien]

Well I hate this but seems I had to kick the parallel processing. so I'm stuck with this right back to the slow reacting button press...the parallel processing worked but when using analog sensors it does not work properly.....too much time lag on temp read

'Stupid slow way of doing this but necessary
'Using one Temp probe, one led , one Lcd , and two buttons
'predefined message stored in lcd (1)&(2)&(3)

init: pause 500
main:
	readtemp c.1,w0 'store temp from probe into var' w0
	w0 = w0*9/5+32  'convert to farenheit
	pause 100
	
	if pinc.3 = 1 then flash1 'hold button for abnormal time	
	if pinc.2 = 1 then flash2 
	
	serout c.0,n2400,(1)    'output to lcd		  
	pause 10	
	serout c.0,n2400,(254,135,#w2,"  ")
	wait 1
	serout c.0,n2400,(3)
      pause 10	
	serout c.0,n2400,(254,135,#w4,"  ")
	pause 500	
	serout c.0,n2400,(2)
	pause 10
	serout c.0,n2400,(254,201,#w0,"  ")
	goto main
Flash1:
	w2 = w0 
	high b.4 'flash led
	pause 200
	low b.4	
	goto main
Flash2:
	w4 = w0
	high b.4 'flash led
	pause 200
	low b.4
	goto main

"if i cant master a simple project like this..... im losing hope to advance it to its next level

 

[techElder]

You have a lot of the elements you'll need for a more complex program. Don't give up when you've so close. Here's some inspiration for you:

​

 

[westaust55]

Multi-tasking with the PICAXE will not help you with improving the speed since the PICAXE executes one command in the first task, then a command in the second task, a commend in each other task (if extra tasks are defined) then returns to the first task to execute the next command.
When executing a command such as READTEMP and SEROUT no other command in any task will be performed until the current command has been completed which may take some 100&#8217;s of ms to achieve.

The M2 and X2 parts may take less time than 750 ms because they send a command to the DS18B20 to start the conversion, then poll the device to see when it is ready, and finally read the result rather than wait a defined 750 ms as is done with the earlier M and X1 parts.

Even using the software polled interrupts may not help greatly as the inputs being monitored are only scanned at the end of each BASIC command so while there are advantages and some speed improvement in general the READTEMP command must complete before the inputs being polled for interrupts are next scanned.

There are hardware interrupts = hintx) pins on the PICAXE X2 parts but then the X2 parts also have the 1-Wire commands OWIN and OWOUT which allow you to directly control and access the DS18B20 registers, set the resolution (9 to 12 bits) etc. As already mentioned, you can then start the DS18B20 performing a temp conversion and while that is happening perform other tasks or just poll for when the DS18B20 has the temperature reading ready. After each poll (check if ready) a command is finished and the polled interrupt function checks your inputs thus you can check the switches on the inputs many times while waiting for the temperature ready to be returned form the DS18B20.

However, this would require a change from the 08M2 part to a 20X2 part.

The other part is still to ascertain why you must wait for around 1 second after sending data to the AXE033 as this is not normal.

The statement at post 1: "if i drop anything down the way its written the lcd bugs"
is not very clear as to what is happening. Maybe I missed it but it is not clear what is the specific problem you are experiencing when sending data to the AXE033 if you do not have a delay after the SEROUT command.

A sumamry of where you are currently at with your latest program code, schematic and even a clear photo may help.

 

[Digisapien]

Multi-tasking with the PICAXE will not help you with improving the speed since the PICAXE executes one command in the first task, then a command in the second task, a commend in each other task (if extra tasks are defined) then returns to the first task to execute the next command.
When executing a command such as READTEMP and SEROUT no other command in any task will be performed until the current command has been completed which may take some 100

 

[oracacle]

there has been something bugging the crap out of me fromthe first post - i have finally put my finger on it.

you must have set the pre-defined mesagese, when calling they chould be preceeded by 253, and instruction as to what the thing should be doing, seem to only need a pause 10 after that too
also it maybe worth looking at taking the temps instead of pausing, you are pausing for 50ms, and the read temp is around 750ms

I am up to my ears in stuff for my project at the minuite so cant test any thing, but send some very long string of data, data read from the I2C strait to the display in loops, in one case 4 loops of 32 without any issue.

 

[hippy]

Well I hate this but seems I had to kick the parallel processing. so I'm stuck with this right back to the slow reacting button press...the parallel processing worked but when using analog sensors it does not work properly.....too much time lag on temp read

It's not just the time it takes to do the READTEMP but that you are displaying multiple screens of information for long periods, only ever checking for button pushes once around that loop ...

Do
First screen, show for one second
Second screen, show for half a second
Third screen, show for 750ms (ish) while READTEMP executes
Jump if button push
Loop

So your button push check is only performed once every two and a quarter seconds.

You can improve that responsiveness using interrupts or multi-tasking, however, you will not be able to improve responsiveness during the time period when READTEMP command is executing.

If you want near instant response to button pushes that can be achieved but not without changing the hardware and software design. Some non-responsiveness is a limitation of using the READTEMP command.

 

[geoff07]

If the readtemp delay is critical, you could do the readtemps in another chip dedicated to that task, and send the values by serial, interrupting with them every now and again. Then the main chip can be dedicated to other stuff, and the button can itself interrupt, giving almost instant response

 

[hippy]

@ geoff07 : That's what I was thinking of.

And it's probably even easier than the READTEMP PICAXE having to interrupt. Because the main program loop time displaying screens will be longer than the 750ms of READTEMP, that main loop simply has to set a 'give me data' signal, and read the data in. At which point the READTEMP PICAXE goes on to perform another READTEMP and will have the next data to return before the main PICAXE next asks for it.

The 'give me data' and the reading data back signals can be combined as a single I/O signal line so no higher I/O usage than the DS18B20 directly connected if short on I/O.

As then said; the main PICAXE is free to handle interrupts from buttons at almost any time and will have near instant responses to button pushes. The only change needed will be to turn longer delays for displaying data on screen to calls to subroutines containing a loop of shorter pauses so an interrupt doesn't too prematurely move the display onto the next. In fact, button push handling can be in those subroutines, polled rather than interrupt driven, which makes the code even simpler.

Some demo code showing how an 08M2 can be dedicated to being a 'zero delay DS18B20' with just one I/O. The DS18B20 PICAXE uses an internal pull-up so it can tell when the master has started SERIN which causes that pin to become input and the signal line to float high. Use an inline 1K between the pins on each for safety.

; Master 08M2

#Picaxe 08M2
#Terminal 4800

Symbol LINK = C.2    ; Pin to DS18B20 PICAXE

Symbol BAUD = T2400  ; Must be Txxxx

Do
  Gosub ReadTemperatureIntoB0
  SerTxd( "Temp=", #b0, "C", CR, LF )
  Pause 2000
Loop

ReadTemperatureIntoB0:
  SerIn LINK, BAUD, b0
  Pause 1
  Low LINK
  Return

; DS18B20 08M2

#Picaxe 08M2

Symbol DS18B20  =    C.1 ; Pin to DS18B20

Symbol LINK     =    C.2 ; Pin to Master PICAXE
Symbol LINK_PIN = pinC.2 ; Pin to Master PICAXE

Symbol BAUD     = T2400  ; Must be Txxxx

;       543210
PullUp %000100           ; Pull-Up on Pin to Master PICAXE

Do
  ReadTemp DS18B20, b0
  Do : Loop Until LINK_PIN = 1
  High   LINK
  SerOut LINK, BAUD, ( b0 )
  Input  LINK
Loop

 

[westaust55]

If there must be extended pauses such as those following the SEROUT commands (see post 1) then another way to improve the reaction time for interrupts is to break the extended pause into a series for short pauses.

So instead of:
PAUSE 1000

use:
For b5 = 0 to 9
PAUSE 100
NEXT b5

that way the inputs can be scanned for a state change 10 times in the 1 second delay.

When using interrupts to monitor for activity on one of several pins use the NOT parameter.
so in pseudo code assuming there are pull-up resistors so the inpits are normally high then
the SETINT command would be establist to look for NOT both_pins high

 

[inglewoodpete]

The art of programming a microcontroller is in writing code that suits the job that the processor must do. If you want responsive code, don't use Pause or Wait commands.

I rarely use Pause commands apart from in initialisation (startup) code. Use the timers or a main-loop counter. That way, the main loop can attend to everything required, including decrement (or increment) a loop counter used as a crude timer which can trigger the occasional events like LCD writes etc. An example of open loop coding as a timer can be found here. Yes, I did resort to short (10mS) delays.

The X2 chips have the most flexible and useful timers.

In your case, if you need a 1-second time to display a message on the LCD then use the ReadTemp command for all or part of the waiting period.

 

[AllyCat]

Hi,

... another way to improve the reaction time for interrupts is to break the extended pause into a series for short pauses. ...

Yes, that's correct for any (user-coded) polled inputs, but surely Manual 2 for setint says: "The inputs port is checked between execution of each command line in the program, between each note of a tune command, and continuously during any pause command."? However, I doubt if the OP is actually planning to use an interrupt.

The art of programming a microcontroller is in writing code that suits the job that the processor must do. If you want responsive code, don't use Pause or Wait commands.

In your case, if you need a 1-second time to display a message on the LCD then use the ReadTemp command for all or part of the waiting period.

Yes, I absolutely agree. It seems to me that the whole issue of this thread is caused by poor program structure and/or a hardware or software "bug" causing the LCD not to behave "as expected".

Cheers, Alan.

 

[hippy]

It seems to me that the whole issue of this thread is caused by poor program structure and/or a hardware or software "bug" causing the LCD not to behave "as expected".

Having re-read the thread I don't think there was a problem with the LCD behaviour itself, just that reducing the pauses led to functional behaviour other than desired. I think it was just the way the issue was worded.