20x2 setfreq Best Practices?
- Thread starter beb101
- Start date
I am pretty much a beginner and learning from from other's posts on the Forum. I rarely see this statement in code and when I try to use it the program will not execute correctly. The code below runs just fine at the default 8MHz, but produces garbage with setfreq m64. I think this is because of the sertxd statments. My next step is to move to hardware serial.
It seems to me that if you have a processor that will run at 64MHz why not do so. Perhaps I should rephrase my question: when do you use setfreq m64 with the 20X2 and why?
baxter
Code:
'PICAXE 20X2 defaultspeed 8MHz
'Test I2C bus with DS1307 RTC and 24Lc256 EEPROM
#terminal 9600
symbol sec = b0
symbol mins = b1
symbol hour = b2
symbol day = b3
symbol day_mo = b4
symbol month = b5
symbol year = b6
symbol control = b7
symbol pm_am = b8
symbol out1 = b9
symbol out2 = b10
symbol out3 = b11
symbol out4 = b12
symbol out5 = b13
symbol out6 = b14
symbol DS1307 = b15
symbol _24LC256 = b16
let DS1307 = %11010000 'hex D0, dec 208
let _24LC256 = %10100000 'hex A0, dec 160
let control = %00010000 'Enable output at 1Hz
'Set 1Hz SQW
hi2csetup i2cmaster, DS1307, i2cslow, i2cbyte
hi2cout 7, (control)
pause 10
hi2cin $7,(control)
pause 300 'control won't print without this pause
SerTxd("Control ",#control)
pause 1000
main:
hi2csetup i2cmaster, DS1307, i2cslow, i2cbyte
hi2cin $0,(sec,mins,hour,day,day_mo,month,year)
gosub Time
gosub Date
pause 2000 'to see time
hi2csetup i2cmaster, _24LC256, i2cslow, i2cword '24lc256
gosub read_24lc256
goto main
'********
'* Time *
'********
Time:
pm_am ="P" : if hour < $12 then :pm_am = "A" : endif 'indicate pm or am
if hour = $20 or hour = $21 then : let hour = hour - $6 : endif
if hour > $12 then : let hour = hour - $12 : endif '24 to 12 hour format
if hour = $0 then : hour = $12 : endif
bcdtoascii hour,out1,out2
bcdtoascii mins ,out3,out4
bcdtoascii sec ,out5,out6
SerTxd(CR, LF,out1,out2,":",out3,out4,":",out5,out6," ",pm_am,"M -- ")
return
'********
'* Date *
'********
Date:
bcdtoascii month,out1,out2
bcdtoascii day_mo ,out3,out4
bcdtoascii year ,out5,out6
SerTxd(out1,out2,"/",out3,out4,"/",out5,out6, CR, LF, CR, LF)
return
'****************
'* Read 24LC256 *
'****************
Read_24lc256:
'read the first page (0-63) plus one
'first page data:
' "abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz 1234567891"
'All other bytes = 0
for w1=0 to 64 'w1 = 64 should give null byte = blank print
hi2cin w1, (b0)
SerTxd( b0) 'print all on 1 line
pause 20
next w1
SerTxd(CR, LF )
SerTxd( "Done ", CR, LF )
returnbaxter
mrburnette
Senior Member
@beb101: the 20x2 performs as expected at 64 MHz:
Morse-Code-Decoder-using-a-20X2
But, one has to be oh so careful with any internal constants, delays, serial output, etc. But, it works in a in-chip scenario. Going off the PICAXE to I/o devices could be problematic even when coded correctly due to noise, capacitance, inductance, etc. Think of it this way... 64MHz is 2X the upper limit of shortwave radio so care has to be exercised in the design.
- Ray
Morse-Code-Decoder-using-a-20X2
But, one has to be oh so careful with any internal constants, delays, serial output, etc. But, it works in a in-chip scenario. Going off the PICAXE to I/o devices could be problematic even when coded correctly due to noise, capacitance, inductance, etc. Think of it this way... 64MHz is 2X the upper limit of shortwave radio so care has to be exercised in the design.
- Ray
Last edited:
Thanks for your replies. I added this to the code I posted above,
setfreq mXX
hsersetup B9600_XX, %0
hserout in place of sertxd
and hooked up a Pc terminal. It works ok for XX = 8, 16, 32 and fails at 64. Except for 8MHz, all of the pauses for other frequencies are wrong. hi2cin initially works at frequencies higher than 8MHz, but then fails after awhile. I did not exhaustively test 16MHz, but there is a parameter, i2cslow_16.
I am not trying to push the envelope here; just trying to understand the limitations of going to 64MHz. From your comments and this limited experiment
I have learned that for I2C, it is best to forget other frequencies and stick to the default 8MHz. And, as as you point out Ray; stick to internal operations for 64MHz.
Baxter
setfreq mXX
hsersetup B9600_XX, %0
hserout in place of sertxd
and hooked up a Pc terminal. It works ok for XX = 8, 16, 32 and fails at 64. Except for 8MHz, all of the pauses for other frequencies are wrong. hi2cin initially works at frequencies higher than 8MHz, but then fails after awhile. I did not exhaustively test 16MHz, but there is a parameter, i2cslow_16.
I am not trying to push the envelope here; just trying to understand the limitations of going to 64MHz. From your comments and this limited experiment
I have learned that for I2C, it is best to forget other frequencies and stick to the default 8MHz. And, as as you point out Ray; stick to internal operations for 64MHz.
Baxter
Hey there BEB101,
You may be jumping to conclusions.
Setfreq m64 can be useful at times , as can any frequency setup.
Garbage output with sertfreq m64 and Sertxd could be that the terminal baud rate was incorrect. It needs to be set to 76800. If that is an unsupported rate then before using sertxd use setfreq m32 and set the terminal to 38400 then when the sertxd is done use setfreq 64 again.
There is no reason that I2C should fail at processor speeds above 8 MHz. Simply issue < hi2csetup .... i2cslow_64 if operating at 64mhz or <hi2csetup ... hi2cslow_32> if at 32 MHz. The manual is vague here, but is says ... "Note that these keywords must change to i2cfast_8, i2cslow_8 at 8MHz, etc.." Apparently, we are to take the "etc" to mean that _16, _32, and _64 also work, even though not clearly stated.
Untested, but I used ... hi2csetup i2cmaster, %10100000, i2cslow_64, i2cbyte ..... and the compiler accepted the i2cslow_64 keyword, so it should work.
The manual is clear about the effect of timings when the frequency is increased from the default. With an X2 at 64MHz you multiply a pause by 8 to get the same delay as when running at 8MHz. Each timing sensitive command will include a note in the manual under that command about the effect of increased processor speeds.
The question is why operate at 64 Mhz unless you need the speed? With the vast majority of applications you won't need it and won't even be able to tell the difference. The faster you operate the clock, the more power is consumed by the Picaxe (consider battery life ).
You may be jumping to conclusions.
Setfreq m64 can be useful at times , as can any frequency setup.
Garbage output with sertfreq m64 and Sertxd could be that the terminal baud rate was incorrect. It needs to be set to 76800. If that is an unsupported rate then before using sertxd use setfreq m32 and set the terminal to 38400 then when the sertxd is done use setfreq 64 again.
There is no reason that I2C should fail at processor speeds above 8 MHz. Simply issue < hi2csetup .... i2cslow_64 if operating at 64mhz or <hi2csetup ... hi2cslow_32> if at 32 MHz. The manual is vague here, but is says ... "Note that these keywords must change to i2cfast_8, i2cslow_8 at 8MHz, etc.." Apparently, we are to take the "etc" to mean that _16, _32, and _64 also work, even though not clearly stated.
Untested, but I used ... hi2csetup i2cmaster, %10100000, i2cslow_64, i2cbyte ..... and the compiler accepted the i2cslow_64 keyword, so it should work.
The manual is clear about the effect of timings when the frequency is increased from the default. With an X2 at 64MHz you multiply a pause by 8 to get the same delay as when running at 8MHz. Each timing sensitive command will include a note in the manual under that command about the effect of increased processor speeds.
The question is why operate at 64 Mhz unless you need the speed? With the vast majority of applications you won't need it and won't even be able to tell the difference. The faster you operate the clock, the more power is consumed by the Picaxe (consider battery life ).
I have only needed it once and that was to get a DHT-11 humidity sensor to work. Another reason could be to get superfine resolution/accuracy when using pulsin to read a pulse width or when good accuracy is needed generating a pulse with pulsout.
Last edited:
You would set the frequency at higher than the default, if your application needs the extra speed, most do not.
Buzby
Senior Member
Just to make it clear, I2C does work, fast or slow, at 64MHz.
The 'fast' and 'slow' relate to the capabilities of the devices on the I2C bus.
Also SERTXD works fine at 64MHz, but the resulting baud rate of 76800 is not accepted by most serial ports.
I used the following code snippets to allow me to run at 16MHz when debugging, and 64MHz when running normally.
Hope this helps,
cheers,
Buzby.
The 'fast' and 'slow' relate to the capabilities of the devices on the I2C bus.
Also SERTXD works fine at 64MHz, but the resulting baud rate of 76800 is not accepted by most serial ports.
I used the following code snippets to allow me to run at 16MHz when debugging, and 64MHz when running normally.
Code:
' Set PICaxe clock frequency
#IFDEF DEBUG_ON
setfreq m16 ' Running at 16MHz for debug
#ELSE
Setfreq em64 ' Running at 64MHz for normal operation
#ENDIF
' Setup the I2C communication to the 24LC256 EEPROM
#IFDEF DEBUG_ON
hi2csetup i2cmaster, %10100000, i2cfast_16, i2cword ' Running at 16MHz
#ELSE
hi2csetup i2cmaster, %10100000, i2cfast_64, i2cword ' Running at 64MHz
#ENDIF
.
.
.
#IFDEF DEBUG_ON
sertxd ( #IRval, cr, lf ) ' DEBUG
#ENDIFcheers,
Buzby.
hippy
Ex-Staff (retired)
I think it's as others have said, the rule of thumbs is, for an easy life, stick with the default operating speeds. Where necessary or desirable ( mainly to increase performance or meet timing needs ) increase the frequency ( in parts of the program or for the whole ), but pay close attention to what else needs to alter as the frequency increases and what may be affected by speed increases.
With external hardware their capabilities and limitations have to be taken into account; much like you shouldn't drive at 100mph if you have 60mph rated tyres fitted.
A good principle, which you have followed, is to start at the default speed, increase it as required, check it works and keep doing that until you reach the desired speed. If it stops working as expected then analyse that and determine where and why there is a problem.
With external hardware their capabilities and limitations have to be taken into account; much like you shouldn't drive at 100mph if you have 60mph rated tyres fitted.
A good principle, which you have followed, is to start at the default speed, increase it as required, check it works and keep doing that until you reach the desired speed. If it stops working as expected then analyse that and determine where and why there is a problem.