James, I just tried the debugger with my IrLED-Detector code.
1. I tried the debugger with the resonator installed, as soon as the debugger started, it showed that it was sleeping. I did a reset and allowed for one step that put it back into sleep mode. At this point my test LED was not on. So it looked like it would never get out of sleep mode.
2. Next, I tried the debugger without the resonator installed. After starting it allowed me to step through the program. It stepped until it got to the freqout loop. I placed my hand in front of the detector and stepped awhile, never got out of the loop. Then I did a run, within the debugger, immediately the test LED turned on, with a non-functioning detector. I placed my hand in front of the detector a few times, nothing. So, this quirk seems to occur within debug with the resonator not installed.
Now as to your point about running it with the resonator installed, I have run other programs with the resonator installed and everything works fine. It just seems, so far, that when I use the freqout command the problems start to show up.
Rsadeika said...
I took the code out of the Daubach book that pertains to the IrLED-Detector for his SX tech bot, midified the code a little bit so it would use just one IrLED-Detector combination, and ran the code. I was thrilled that when it was running, that when I placed my hand in front of the detector, my test LED would go on, and when I removed my hand, the LED would go off. Then I decided to start debugging, I put my finger over the IrLED, and moved my hand in, the test LED turned on. I blocked off both the IrLED and the detector, hand in LED on. At this point I started to remove all the pieces from the breadboard one at a time, HAND in LED on. I finally ended up with my test LED and resistor which was hooked to rc.7 and a wire stuck in rc.6, when I moved my hand toward the test LED the LED would turn on, and when I moved my hand out, the LED turned off.
I just hit in here to point out an important difference. The IrLED-Detector in my SXTech Bot samples is designed to run @ 4 MHz instead of 50, as robots often are powered from batteries, and an SX clocked @ 4 MHz consumes remarkably less power than @ 50 MHz.
Sometimes, I experienced that an SX showed "strange behavior" when I came close to it with my hand. I have learned that floating inputs can produce such nice effects. At least, there should be a pull-up between Vdd and the MCLR* pin (in case you are using the SXTech board, there is one on-board). Another candidate is the RTCC pin pulled up to Vdd, or down to Vss. I/O pins are less critical. Nevertheless, at least the internal weak-pullups should be active on free pins.
BTW, instead of launching the debugger, and "Run"ning the program from there, you might also try the "Run - Clock" menu option. This turns the SXKey into a clock generator allowing you to select a wide range of clock frequencies. Before using this option, don't forget to launch the "Program" option to make sure that your program is transferred to the SX without the debug support code.
Guenther, in my project I will be using a 6V 4.5 amp battery for the tech board, and four 6V 4.5 amp batteries to drive the wheels, and anything else. I have not calculated the battery usage at 50MHz yet. I am still trying to figure out how to modify your IrLED code so I can have the IrLED put out 42000 kHz. The concept eludes me, in assembly.
2. Next, I tried the debugger without the resonator installed. After starting it allowed me to step through the program. It stepped until it got to the freqout loop. I placed my hand in front of the detector and stepped awhile, never got out of the loop. Then I did a run, within the debugger, immediately the test LED turned on, with a non-functioning detector. I placed my hand in front of the detector a few times, nothing. So, this quirk seems to occur within debug with the resonator not installed.
Now as to your point about running it with the resonator installed, I have run other programs with the resonator installed and everything works fine. It just seems, so far, that when I use the freqout command the problems start to show up.
The program is never getting out of the freqout loop because it takes a few thousand cycles to do so. Place a "break" command after the freqout and when you run the program in the debugger it will automatically drop in the debug AFTER the freqout. This will allow you to step into the part where it reads the detector.
If there is any way to do it, we must convince you that you CAN NOT run an SX with two clock sources at the same time...
...can I get any back up from other members on this? If other programs have worked, it was a miracle.
I have run an SX from from the SX-Key WITH the 50MHz resonator installed. It seem that the SX-Key "overrides" the resonator when you do this. I can debug too with the resonator installed. Maybe it's just my setup, but it has always worked for me.
But I will say that the resonator is more stable that the sx-key, I am generating video output from the SX and with the SX-key clocking the screen is jittery (yes even with the resonator removed). When I pull the SX-Key off (with the resonator installed) the screen goes rock solid.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
Rsadeika said...
Guenther, in my project I will be using a 6V 4.5 amp battery for the tech board, and four 6V 4.5 amp batteries to drive the wheels, and anything else. I have not calculated the battery usage at 50MHz yet. I am still trying to figure out how to modify your IrLED code so I can have the IrLED put out 42000 kHz. The concept eludes me, in assembly.
I assume, you mean 42.000 kHz for the IrLED (and not 42 MHz ).
Well, let's fire up the calculator:
42 kHz means a period of 23.81 µs, so the LED needs to be toggled every 11.905 µs.
For an SX running @ 50 MHz, the clock cycle time is 20 ns.
When you call the ISR every 149 clock cycles, and toggle the LED every fourth ISR call, this ends up in
20 ns * 149 * 4 = 11.92 µs
11.92 µs * 2 gives a period of 23.84 µs, or a frequency of 41.946 which should be close enough to the optimum of 42 kHz.
This ISR code should generate the frequency you need, provided the SX is clocked @ 50 MHz.
Besides this, you would also let the ISR generate the PWM signals that are required for the servos. As the ISR is executing 12.5 times faster at 50 MHz, compared to 4 MHz, the timing loops for the PWMs must be adjusted accordingly.
BTW: "Boosting" up to 50 MHz has the big advantage that the resulution of the servo settings greatly increases. With the batteries you plan to use, the increased power consumption at 50 MHz should not be an issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Post Edited (Guenther Daubach) : 2/14/2005 6:38:58 PM GMT
Gunther, thank you for the code snippet. I know I have to be more carefull with tech descriptions, yes I meant 42kHz. From a personal standpoint, when you are using your sx tech board, do you have a resonator installed when you are using the sx key?
when posting the code snippet, I was in a hurry to leave home, picking up my wife. Now that I'm back, I noticed a bug in that code. In the meantime, I have edited the post, so please have a look at it again for a "better" version.
By several bad experiences I made in the past, I now always make sure that no external components are connected to the SX OSC1 while programming or debugging, as this pin is raised up to Vpp (about 12.3 Volts) while the SX is programmed via the SX-Key. So, I either have the external clock component (resonator, crystal, or clock generator) sitting in a socket to make it removeable, or provide a jumper on my boards, allowing to disconnect the OSC1 pin from all other components but the SX-Key OSC1 pin header. In order to debug/program systems that do not allow to isolate the OSC1 pin, I have built a simple adapter. See http://forums.parallax.com/forums/default.aspx?f=7&m=1587 for more details on this.
I guess anybody. The following snippet was assembled and run through the debugger. I get the following, warning - 37 ... Literal truncated to 8 bits. This warning pertains to the line, mov w, #-149
In the documentation, pertaining to this type of error, it states that values can not exceed 255. The value is less than 255. I played around with the values, and the value that does not elicit a warning is 128 or less. Is their something in the code that is missing or should this warning be ignored and assume that the correct value is being mov(ed) into the w register.
The most likely reason for jittery video with the SXKey is that the SXKey is able to synthesize a variable clock from whatever fixed speed clock source it has built into it. Depending on the technique used, synthesized clocks often result in a new clock that has some jitter in it. Even small amounts of jitter in an NTSC signal will create noticeable image artifacts.
Rsadeika said...
I guess anybody. The following snippet was assembled and run through the debugger. I get the following, warning - 37 ... Literal truncated to 8 bits. This warning pertains to the line, mov w, #-149
In the documentation, pertaining to this type of error, it states that values can not exceed 255. The value is less than 255. ...
Rsadeika,
from a "human" point of view, -149 is smaller than 255 but not for SASM, and for the SX itself. Both actually only handle integer values, i.e. without sign.
For example,
clr 8
dec 8
results in register 8 containing %11111111. Now it depends on you, how to interpret this result. You might say, this is a value of 255 but you could also say, this is -1, represented in 2's complement format.
I don't know, how many bytes SASM internally uses to represent numbers but I assume 3 bytes at least in order to deal with addresses. Now, when the Assembler "sees" -149, it interprets it as 1111 0110 1011. The warning is generated because this 12-bit value is going to be moved into an 8-bit register, telling you that the value was truncated to 8 bits, i.e. to 0110 1011 which is correct.
You can either ignore this warning, or add a LIST Q = 37 at the very beginning of your code to supress that warning.
Gunther,
Lets see if I got this straight, the assembler sees the -149, and truncates this 12 bit value to ??two?? 8 bit values. So, I am safe to assume that when the proccesor gets to that part of the code, it executes those two registers in a way that it would equal the oririnal function intended. Now, if this is the case, if I used an extremely large value, would the assembler throw up an error saying, I have exceeded the byte limit for number repesentation, or do you get the same truncation warning, but this time your value has changed, and so has the function. So, the moral of the story is, another level of control, and possibly frustration.
This is in the same topic area, so I did not know whether I should start a new thread, or keep it in this thread.
Listed below is my familiar example. The question is, why has the·timing aspect·of 'pause' been changed. As noted in the code when I use 'pause 1000' the timing is no loger one second but it is now almost four seconds in real time. So, from now on when I use an interrupt I will have to create my own 'pause' command.
'Turn LED on/off via freqout as an interrupt
DEVICE········· SX28, OSCXT2, TURBO, STACKX, OPTIONX
FREQ··········· 50_000_000
IrLED· var rb.6
Detect var rb.7
LED1·· var rc.7
IrMod con 42000· 'sensitivity is about 7-7 1/2 inches
Yes con 0
No· con 1
INTERRUPT · freqout IrLED, IrMod, 1
RETURNINT·· 'This cycles 1.3 ms
PROGRAM Start
Start: · option = $87· 'Set RTCC to 1:256-$87,
Main:
'freqout IrLED, IrMod, 1
if Detect = No then Main
'LEDOn:
low LED1
''pause 3000· 'This is now about 12 seconds in real time
pause 1000·· 'This is now about 4 seconds in real time
high LED1
'gosub @LEDOn· 'The @ symbol is needed to access different page of memory
goto Main
Do not use FREQOUT in the interrupt routine. It takes way too much time.
You are using 1ms every 1.3ms in the interrupt routine. So your main code is going to run at about %25 normal speed. VERY BAD.
Just make the interrupt routine toggle the IR pin like this
INTERRUPT
TOGGLE IrLED
RETURNINT
and set up the interrupt to be called 84000 times a second to get 42KHz.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
Rsadeika said...
Gunther,
Lets see if I got this straight, the assembler sees the -149, and truncates this 12 bit value to ??two?? 8 bit values. So, I am safe to assume that when the proccesor gets to that part of the code, it executes those two registers in a way that it would equal the oririnal function intended. Now, if this is the case, if I used an extremely large value, would the assembler throw up an error saying, I have exceeded the byte limit for number repesentation, or do you get the same truncation warning, but this time your value has changed, and so has the function. So, the moral of the story is, another level of control, and possibly frustration.
Well, the assembler sees the -149, and converts it into binary representation (I assume it is 12 bits long but the real length is not of importance at all, so let's assume 12 bits here), so -149 is represented as %1111 0110 1011 internally.
Next, the assembler generates the code for mov w, #const, where #const is %1111 0110 1011 here. As w can only hold 8 bits, the assembler discards the leading four buts, generates the code to mov %0110 1011 to w, and generates the warning that it has truncated the value to 8 bits.
Instead of mov w, #-149, you could also first calculate the difference 256-149 which is 107 and then write mov w, #107 which places exactly the same binary value in w without causing the warning message.
So, you are not correct, assuming that the Assembler splits values larger than 255 into two or more chunks, saving them in several registers. The SX has 8 bit wide data registers, i.e. it simply can't handle lager numbers per-se. If this becomes necessary, it is up to the programmer to implement multi-byte math routines, nested counters for counting numbers, etc. above the "magic limit".
What I usually do to elimate the truncation warning is this:
···mov·····w,·#-149 &·0xff·; ···retiw
Since I am forcing the truncation the assembler is happy.
This is very similar to Guenther's 256-149 method.
These techniques result in the same code: ···C6B············ mov···· w, #-149 & 0xff ···C6B············ mov···· w, #(256-149) ···00F············ retiw
BTW, it is sometimes annoying to see warnings during assembly, but I always
try to resolve the warning in my code instead of ignoring the warning or disabling it.
Very often the warning really is important...
It is not that the warnings are annoying, I have had an experience where I ignored a warning, and then a couple of hundred lines of code later, the warning comes into play. And then the real headache sets in, a debugging nightmare. But I think the usually remedy for that is, do work-around, the work-around scenario is only postponing the tragic end.
especially when compiling C or C++ programs, I only accept code when it copiles without any warnings. In C/C++ warnings are commonly generated when the compiler automatically castst some data type into some other type. I never trust those automatic conversions, and do my own type-casts until the compiler passes my code w/o warnings.
Comments
1. I tried the debugger with the resonator installed, as soon as the debugger started, it showed that it was sleeping. I did a reset and allowed for one step that put it back into sleep mode. At this point my test LED was not on. So it looked like it would never get out of sleep mode.
2. Next, I tried the debugger without the resonator installed. After starting it allowed me to step through the program. It stepped until it got to the freqout loop. I placed my hand in front of the detector and stepped awhile, never got out of the loop. Then I did a run, within the debugger, immediately the test LED turned on, with a non-functioning detector. I placed my hand in front of the detector a few times, nothing. So, this quirk seems to occur within debug with the resonator not installed.
Now as to your point about running it with the resonator installed, I have run other programs with the resonator installed and everything works fine. It just seems, so far, that when I use the freqout command the problems start to show up.
I just hit in here to point out an important difference. The IrLED-Detector in my SXTech Bot samples is designed to run @ 4 MHz instead of 50, as robots often are powered from batteries, and an SX clocked @ 4 MHz consumes remarkably less power than @ 50 MHz.
Sometimes, I experienced that an SX showed "strange behavior" when I came close to it with my hand. I have learned that floating inputs can produce such nice effects. At least, there should be a pull-up between Vdd and the MCLR* pin (in case you are using the SXTech board, there is one on-board). Another candidate is the RTCC pin pulled up to Vdd, or down to Vss. I/O pins are less critical. Nevertheless, at least the internal weak-pullups should be active on free pins.
BTW, instead of launching the debugger, and "Run"ning the program from there, you might also try the "Run - Clock" menu option. This turns the SXKey into a clock generator allowing you to select a wide range of clock frequencies. Before using this option, don't forget to launch the "Program" option to make sure that your program is transferred to the SX without the debug support code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
If there is any way to do it, we must convince you that you CAN NOT run an SX with two clock sources at the same time...
...can I get any back up from other members on this? If other programs have worked, it was a miracle.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
But I will say that the resonator is more stable that the sx-key, I am generating video output from the SX and with the SX-key clocking the screen is jittery (yes even with the resonator removed). When I pull the SX-Key off (with the resonator installed) the screen goes rock solid.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.TerryHittConsulting.com
·
I assume, you mean 42.000 kHz for the IrLED (and not 42 MHz
Well, let's fire up the calculator:
42 kHz means a period of 23.81 µs, so the LED needs to be toggled every 11.905 µs.
For an SX running @ 50 MHz, the clock cycle time is 20 ns.
When you call the ISR every 149 clock cycles, and toggle the LED every fourth ISR call, this ends up in
20 ns * 149 * 4 = 11.92 µs
11.92 µs * 2 gives a period of 23.84 µs, or a frequency of 41.946 which should be close enough to the optimum of 42 kHz.
ISR inc LEDTimer movb IrLED, LEDTimer.2 :ExitISR mov w, #-149 retiwThis ISR code should generate the frequency you need, provided the SX is clocked @ 50 MHz.
Besides this, you would also let the ISR generate the PWM signals that are required for the servos. As the ISR is executing 12.5 times faster at 50 MHz, compared to 4 MHz, the timing loops for the PWMs must be adjusted accordingly.
BTW: "Boosting" up to 50 MHz has the big advantage that the resulution of the servo settings greatly increases. With the batteries you plan to use, the increased power consumption at 50 MHz should not be an issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
Günther
Post Edited (Guenther Daubach) : 2/14/2005 6:38:58 PM GMT
when posting the code snippet, I was in a hurry to leave home, picking up my wife. Now that I'm back, I noticed a bug in that code. In the meantime, I have edited the post, so please have a look at it again for a "better" version.
By several bad experiences I made in the past, I now always make sure that no external components are connected to the SX OSC1 while programming or debugging, as this pin is raised up to Vpp (about 12.3 Volts) while the SX is programmed via the SX-Key. So, I either have the external clock component (resonator, crystal, or clock generator) sitting in a socket to make it removeable, or provide a jumper on my boards, allowing to disconnect the OSC1 pin from all other components but the SX-Key OSC1 pin header. In order to debug/program systems that do not allow to isolate the OSC1 pin, I have built a simple adapter. See http://forums.parallax.com/forums/default.aspx?f=7&m=1587 for more details on this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
In the documentation, pertaining to this type of error, it states that values can not exceed 255. The value is less than 255. I played around with the values, and the value that does not elicit a warning is 128 or less. Is their something in the code that is missing or should this warning be ignored and assume that the correct value is being mov(ed) into the w register.
device sx28l, oscxt2, turbo, stackx
freq 50_000_000
IRC_CAL IRC_FAST
reset Main
IrLed = RB.6
LEDTimer = 0
org 0
ISR
inc LEDTimer
movb IrLED, LEDTimer.2
:ExitISR
mov w, #-149
retiw
Main
mov !option,#%00001000 ;Starts the interrupt
;Test area
:LEDOn
mov !rc,#%01111111
clrb rc.7
;ret
:LEDOff
mov !rc,#%11111111
setb rc.7
;ret
end
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.TerryHittConsulting.com
·
The most likely reason for jittery video with the SXKey is that the SXKey is able to synthesize a variable clock from whatever fixed speed clock source it has built into it. Depending on the technique used, synthesized clocks often result in a new clock that has some jitter in it. Even small amounts of jitter in an NTSC signal will create noticeable image artifacts.
Thanks, PeterM
Rsadeika,
from a "human" point of view, -149 is smaller than 255 but not for SASM, and for the SX itself. Both actually only handle integer values, i.e. without sign.
For example,
clr 8
dec 8
results in register 8 containing %11111111. Now it depends on you, how to interpret this result. You might say, this is a value of 255 but you could also say, this is -1, represented in 2's complement format.
I don't know, how many bytes SASM internally uses to represent numbers but I assume 3 bytes at least in order to deal with addresses. Now, when the Assembler "sees" -149, it interprets it as 1111 0110 1011. The warning is generated because this 12-bit value is going to be moved into an 8-bit register, telling you that the value was truncated to 8 bits, i.e. to 0110 1011 which is correct.
You can either ignore this warning, or add a LIST Q = 37 at the very beginning of your code to supress that warning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Lets see if I got this straight, the assembler sees the -149, and truncates this 12 bit value to ??two?? 8 bit values. So, I am safe to assume that when the proccesor gets to that part of the code, it executes those two registers in a way that it would equal the oririnal function intended. Now, if this is the case, if I used an extremely large value, would the assembler throw up an error saying, I have exceeded the byte limit for number repesentation, or do you get the same truncation warning, but this time your value has changed, and so has the function. So, the moral of the story is, another level of control, and possibly frustration.
Listed below is my familiar example. The question is, why has the·timing aspect·of 'pause' been changed. As noted in the code when I use 'pause 1000' the timing is no loger one second but it is now almost four seconds in real time. So, from now on when I use an interrupt I will have to create my own 'pause' command.
'Turn LED on/off via freqout as an interrupt
DEVICE········· SX28, OSCXT2, TURBO, STACKX, OPTIONX
FREQ··········· 50_000_000
IrLED· var rb.6
Detect var rb.7
LED1·· var rc.7
IrMod con 42000· 'sensitivity is about 7-7 1/2 inches
Yes con 0
No· con 1
INTERRUPT
· freqout IrLED, IrMod, 1
RETURNINT·· 'This cycles 1.3 ms
PROGRAM Start
Start:
· option = $87· 'Set RTCC to 1:256-$87,
Main:
'freqout IrLED, IrMod, 1
if Detect = No then Main
'LEDOn:
low LED1
''pause 3000· 'This is now about 12 seconds in real time
pause 1000·· 'This is now about 4 seconds in real time
high LED1
'gosub @LEDOn· 'The @ symbol is needed to access different page of memory
goto Main
You are using 1ms every 1.3ms in the interrupt routine. So your main code is going to run at about %25 normal speed. VERY BAD.
Just make the interrupt routine toggle the IR pin like this
INTERRUPT
TOGGLE IrLED
RETURNINT
and set up the interrupt to be called 84000 times a second to get 42KHz.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out· the "SX-Video Display Module"
www.TerryHittConsulting.com
·
Next, the assembler generates the code for mov w, #const, where #const is %1111 0110 1011 here. As w can only hold 8 bits, the assembler discards the leading four buts, generates the code to mov %0110 1011 to w, and generates the warning that it has truncated the value to 8 bits.
Instead of mov w, #-149, you could also first calculate the difference 256-149 which is 107 and then write mov w, #107 which places exactly the same binary value in w without causing the warning message.
So, you are not correct, assuming that the Assembler splits values larger than 255 into two or more chunks, saving them in several registers. The SX has 8 bit wide data registers, i.e. it simply can't handle lager numbers per-se. If this becomes necessary, it is up to the programmer to implement multi-byte math routines, nested counters for counting numbers, etc. above the "magic limit".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
It sounds like you're not familiar with "twos complement" math. Here's an URL:
mathforum.org/library/drmath/sets/select/dm_twos_complement.html
Read the various pages on that page and see if this doesn't start to make more sense.
Thanks, PeterM
···mov·····w,·#-149 &·0xff·;
···retiw
Since I am forcing the truncation the assembler is happy.
This is very similar to Guenther's 256-149 method.
These techniques result in the same code:
···C6B············ mov···· w, #-149 & 0xff
···C6B············ mov···· w, #(256-149)
···00F············ retiw
BTW, it is sometimes annoying to see warnings during assembly, but I always
try to resolve the warning in my code instead of ignoring the warning or disabling it.
Very often the warning really is important...
Another $0.02
Jim G.
especially when compiling C or C++ programs, I only accept code when it copiles without any warnings. In C/C++ warnings are commonly generated when the compiler automatically castst some data type into some other type. I never trust those automatic conversions, and do my own type-casts until the compiler passes my code w/o warnings.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G