Sculpture code optimization

chipwich

Member
Like most of my 08M projects, I end up writing and rewriting code to fit within the memory. Ongoing desire to add new features means rewriting the code to free up a few more bytes and perhaps a variable (or two if I'm lucky).

Inevitably, OOP (object oriented) programming style gets cut back severely and subroutines are usually the first casualties.

A new project at <A href='http://www.medcosm.com/picaxe_robot_sculpture.htm' Target=_Blank>External Web Link</a> which might be of interest here since it is solar powered and uses the LEDs to sense light.

Anyway, in an ongoing effort to do more with less, can I solicit some suggestions for optimizing the code? Thanks much for any suggestions.
 

manuka

Senior Member
What a nice project! Converting colour to temperature is not only artistic but functional (hot water taps etc).

I've only just glanced at the code <A href='http://www.medcosm.com/hardware/picaxe/relative_thermometer_6.bas ' Target=_Blank>External Web Link</a>but sense all the effects you've managed can be squeezed into an 08M OK. Mmm- surely those 3 SETXD lines could be squeezed into just 1?
<code><pre><font size=2 face='Courier'>
serTxD(#tmpB2, &quot; &quot;)'
serTxD(#modeCycles, &quot; &quot;)'
serTxD(13, 10)
</font></pre></code>


Once the setup is tamed of course you may not even need SERTXD at all. Are you up with the use of %000010 etc to set the I/O pins? Stan



Edited by - manuka on 02/04/2007 00:18:18
 

mynet43

Member
Here's an attempt that didn't work :)

If you look at the glowBlend subroutine, it looks like there's some repeated code that could be done in a subroutine.

Here's the original routine:

glowBlend:
tmpW1=LEDvalue * 255/maxLEDvalue 'scale LEDvalue to full byterange
tmpB1=tmpW1 'save intermediate

tmpW1=tmpW1 * intensity/MaxIntensity 'RED value adjusted for intensity
pwm LEDred, tmpW1, numPWMcycles

tmpW1=255-tmpB1 'GREEN LEDvalue
tmpW1=tmpW1 * intensity/MaxIntensity
pwm LEDgreen, tmpW1, numPWMcycles
return

Here's the 'optimized' code:

glowBlend:
tmpW1=LEDvalue * 255/maxLEDvalue 'scale LEDvalue to full byterange
tmpB1=tmpW1 'save intermediate

LEDvalue = LEDred: gosub glowpwm

tmpW1=255-tmpB1 'GREEN LEDvalue
LEDvalue = LEDgreen: gosub glowpwm
return

glowpwm:
tmpW1=tmpW1 * intensity/MaxIntensity ' value adjusted for intensity
pwm LEDvalue, tmpW1, numPWMcycles
return

The original code takes 36 bytes, the 'optimized' code takes 40 bytes.

Oh well, at least it sounded like a good idea.

Keep up the good work!


 
 

chipwich

Member
Stan,
Those serTxD lines are commented out. They were used for debugging, but are not used in the stand-alone sculpture.

BTW, I've read Hippy's great tips on optimization ( <A href='http://www.hippy.freeserve.co.uk/picaxeop.htm' Target=_Blank>External Web Link</a>) . Lots to keep in mind, but they've definitely helped me free up a few bytes here and there.

 

manuka

Senior Member
Glad you've used Hippy's brain power on this. Are you continually tweaking this code- I'd just visited the page again &amp; it seems different from a few hours back!? Suggest a date/time added with the Version (v6) if so. Stan
 

chipwich

Member
Good catch! No, I'm not tweaking it as I post these messages! I work fast but not *that* fast! :cool:

I was just correcting the website postings to reflect the most recent versions of everything... For example, the original schematic didn't include the solar cell. Everything on the website should be current.
 

hippy

Technical Support
Staff member
It looks quite optimised to me and I cannot see much scope for improvement. You could swap to RESTING=1 / HANDLED=0 and save the initial 'mode=HANDLED' initialisation.

My other thought was as mynet43 suggested above. It's often hard to tell if GOSUBising code saves or adds. In mynet43's code, there's a 'GOSUB glowpwm' immediately followed by a RETURN. You could lose both and let the code simply fall into glowpwm. That would save a few bytes.
 

inglewoodpete

Senior Member
The only point I would make is around using the fake reads of the ADC inputs.

Was the double ReadADC only required on earlier versions of the 08M firmware? My 08Ms only have F/W V9.2 and I've never noticed any problems.

As an aside, you may want to have a look at the new commands Inc and Dec. That won't save you any program space though.

-Peter
 

chipwich

Member
The fake read was not required by the 08M. I haven't noticed any problems with the ADC routines on my 08M chips.

The read was required because in using the LEDs to sense light, I noticed that approximately 1 out of 10 times, the light value read was just wrong.

After playing with this problem for a while, I tracked it back to the combination of driving the LED for light generation and then switching the output to input. This occasionally gave somewhat unreliable results. I never saw this problem in small programs written to test light sensing with the LED, so perhaps this is due to other operations performed by the firmware in the background of the 08M during the course of this somewhat complicated program.

The problem seemed somewhat related to timing between the ouput and input calls, so I tried a fake ADC read, and that seemed to fix the problem. Perhaps just switching the pin to input would be as effective and also save a few bytes...
 

Mycroft2152

Senior Member
I had the same problem with inconsistant readings when using a LED as light sensor. It is not the 08M. It takes time for the LED to stabilize and its internal capacitance to charge.

I ran a fast loop program to check the ADC value multiple times, which when plotted showed the typical capacitor charging curve.

 
Top