We just bought a copy of the softools compiler and now I am testing it
out for the company that I work for. As such I am trying to relearn
very basic things that I learned in Dynamic C such as blinking an LED
on the RCM4300 dev kit we have (we are using an RCM4200 on a 4300
development kit) and how to write to serial ports. I would really
appreciate it if someone would please point me towards a good tutorial
or a resource or a book or something that could show me how to do
these things on Softools. Dynamic C made things very easy by hiding a
lot of the details, which was both good and bad at the same time since
it increased ease of use, but has now left me in the situation I'm in
now.
-MDiaz-Tello
How to get started on softools?
Started by ●October 28, 2008
Reply by ●October 28, 20082008-10-28
mdiaz.tello wrote:
> We just bought a copy of the softools compiler and now I am testing it
> out for the company that I work for. As such I am trying to relearn
> very basic things that I learned in Dynamic C such as blinking an LED
> on the RCM4300 dev kit we have (we are using an RCM4200 on a 4300
> development kit) and how to write to serial ports. I would really
> appreciate it if someone would please point me towards a good tutorial
> or a resource or a book or something that could show me how to do
> these things on Softools. Dynamic C made things very easy by hiding a
> lot of the details, which was both good and bad at the same time since
> it increased ease of use, but has now left me in the situation I'm in now.
>
Check out my tips pages: http://shdesigns.org/tips/
There are notes on porting from DC.
The serial code is different but much better. DC's code is slow and has
had timing issues.
The Softools serial routines are similar but there not as many support
functions (no write string.) It does support ANSI stdio. That means you
can associate a FILE * to a serial port and use fread(), fwrite() and
fprintf(). It also means you can redirect stdin/out to a serial port.
The 4k is not completely supported in Softools. You will have to
manually assign the port function regsisters for the pins if not using
port C.
The softools yahoo group is another resource. The winide group is
available if you give the serial number when goining the group.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Nothing will dispel enthusiasm like a small admission fee.
-- Kim Hubbard
> We just bought a copy of the softools compiler and now I am testing it
> out for the company that I work for. As such I am trying to relearn
> very basic things that I learned in Dynamic C such as blinking an LED
> on the RCM4300 dev kit we have (we are using an RCM4200 on a 4300
> development kit) and how to write to serial ports. I would really
> appreciate it if someone would please point me towards a good tutorial
> or a resource or a book or something that could show me how to do
> these things on Softools. Dynamic C made things very easy by hiding a
> lot of the details, which was both good and bad at the same time since
> it increased ease of use, but has now left me in the situation I'm in now.
>
Check out my tips pages: http://shdesigns.org/tips/
There are notes on porting from DC.
The serial code is different but much better. DC's code is slow and has
had timing issues.
The Softools serial routines are similar but there not as many support
functions (no write string.) It does support ANSI stdio. That means you
can associate a FILE * to a serial port and use fread(), fwrite() and
fprintf(). It also means you can redirect stdin/out to a serial port.
The 4k is not completely supported in Softools. You will have to
manually assign the port function regsisters for the pins if not using
port C.
The softools yahoo group is another resource. The winide group is
available if you give the serial number when goining the group.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Nothing will dispel enthusiasm like a small admission fee.
-- Kim Hubbard
Reply by ●October 28, 20082008-10-28
Go to the Softools group for support on softools.
http://tech.groups.yahoo.com/group/softools/
________________________________
From: mdiaz.tello
To: r...
Sent: Tuesday, October 28, 2008 8:02:14 AM
Subject: [rabbit-semi] How to get started on softools?
We just bought a copy of the softools compiler and now I am testing it
out for the company that I work for. As such I am trying to relearn
very basic things that I learned in Dynamic C such as blinking an LED
on the RCM4300 dev kit we have (we are using an RCM4200 on a 4300
development kit) and how to write to serial ports. I would really
appreciate it if someone would please point me towards a good tutorial
or a resource or a book or something that could show me how to do
these things on Softools. Dynamic C made things very easy by hiding a
lot of the details, which was both good and bad at the same time since
it increased ease of use, but has now left me in the situation I'm in now.
-MDiaz-Tello
http://tech.groups.yahoo.com/group/softools/
________________________________
From: mdiaz.tello
To: r...
Sent: Tuesday, October 28, 2008 8:02:14 AM
Subject: [rabbit-semi] How to get started on softools?
We just bought a copy of the softools compiler and now I am testing it
out for the company that I work for. As such I am trying to relearn
very basic things that I learned in Dynamic C such as blinking an LED
on the RCM4300 dev kit we have (we are using an RCM4200 on a 4300
development kit) and how to write to serial ports. I would really
appreciate it if someone would please point me towards a good tutorial
or a resource or a book or something that could show me how to do
these things on Softools. Dynamic C made things very easy by hiding a
lot of the details, which was both good and bad at the same time since
it increased ease of use, but has now left me in the situation I'm in now.
-MDiaz-Tello
Reply by ●October 28, 20082008-10-28
First of all, thanks for the quick response, and I must say that your
tips are helpful as that DCDEFS.h is allowing me to reuse some of the
code from before (i.e. BitWrPortI(...); ) I did notice, however, when
I first tried to write a little program to blink the LED on the board
in DC, it wouldn't work unless I had a brdInit() call. There is no
corresponding macro for this in DCdefs.h and I assume it would depend
very much on the board you are using, yes? Is there some other
function that Softools has that I can use to initialize the board so I
can toggle the pin that controls our LEDs on and off? On our
development kit protoboard the LEDs are controlled by bits 2 and 3 of
(parallel?) port B and on our actual project board we have 2 activity
LEDs that are on (once again parallel?) port A bits 6 and 7 so I am
trying to figure out how to make them blink for debugging purposes.
Also, we are using the DC functions serXwrite and serXputs (which
really is just a wrapper for serXwrite), so are you saying we ought to
redirect stdout to the serial ports we need to write and read from (in
our case it is serC and serD)? Or is there a better way to do an
equivalent operation in Softools?
Also, I am not sure I understand what you meant when you said:
"The 4k is not completely supported in Softools. You will have to
manually assign the port function regsisters for the pins if not using
port C."
could you please elaborate?
Thanks for all your help!
-MDiaz-Tello
> Check out my tips pages: http://shdesigns.org/tips/
>
> There are notes on porting from DC.
>
> The serial code is different but much better. DC's code is slow and has
> had timing issues.
>
> The Softools serial routines are similar but there not as many support
> functions (no write string.) It does support ANSI stdio. That means you
> can associate a FILE * to a serial port and use fread(), fwrite() and
> fprintf(). It also means you can redirect stdin/out to a serial port.
>
> The 4k is not completely supported in Softools. You will have to
> manually assign the port function regsisters for the pins if not using
> port C.
>
> The softools yahoo group is another resource. The winide group is
> available if you give the serial number when goining the group.
>
> --
> ------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------
> Rabbit libs: http://www.shdesigns.org/rabbit/
> today's fortune
> Nothing will dispel enthusiasm like a small admission fee.
> -- Kim Hubbard
>
tips are helpful as that DCDEFS.h is allowing me to reuse some of the
code from before (i.e. BitWrPortI(...); ) I did notice, however, when
I first tried to write a little program to blink the LED on the board
in DC, it wouldn't work unless I had a brdInit() call. There is no
corresponding macro for this in DCdefs.h and I assume it would depend
very much on the board you are using, yes? Is there some other
function that Softools has that I can use to initialize the board so I
can toggle the pin that controls our LEDs on and off? On our
development kit protoboard the LEDs are controlled by bits 2 and 3 of
(parallel?) port B and on our actual project board we have 2 activity
LEDs that are on (once again parallel?) port A bits 6 and 7 so I am
trying to figure out how to make them blink for debugging purposes.
Also, we are using the DC functions serXwrite and serXputs (which
really is just a wrapper for serXwrite), so are you saying we ought to
redirect stdout to the serial ports we need to write and read from (in
our case it is serC and serD)? Or is there a better way to do an
equivalent operation in Softools?
Also, I am not sure I understand what you meant when you said:
"The 4k is not completely supported in Softools. You will have to
manually assign the port function regsisters for the pins if not using
port C."
could you please elaborate?
Thanks for all your help!
-MDiaz-Tello
> Check out my tips pages: http://shdesigns.org/tips/
>
> There are notes on porting from DC.
>
> The serial code is different but much better. DC's code is slow and has
> had timing issues.
>
> The Softools serial routines are similar but there not as many support
> functions (no write string.) It does support ANSI stdio. That means you
> can associate a FILE * to a serial port and use fread(), fwrite() and
> fprintf(). It also means you can redirect stdin/out to a serial port.
>
> The 4k is not completely supported in Softools. You will have to
> manually assign the port function regsisters for the pins if not using
> port C.
>
> The softools yahoo group is another resource. The winide group is
> available if you give the serial number when goining the group.
>
> --
> ------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------
> Rabbit libs: http://www.shdesigns.org/rabbit/
> today's fortune
> Nothing will dispel enthusiasm like a small admission fee.
> -- Kim Hubbard
>
Reply by ●October 28, 20082008-10-28
mdiaz.tello wrote:
> First of all, thanks for the quick response, and I must say that your
> tips are helpful as that DCDEFS.h is allowing me to reuse some of the
> code from before (i.e. BitWrPortI(...); ) I did notice, however, when
> I first tried to write a little program to blink the LED on the board
> in DC, it wouldn't work unless I had a brdInit() call. There is no
> corresponding macro for this in DCdefs.h and I assume it would depend
> very much on the board you are using, yes? Is there some other
> function that Softools has that I can use to initialize the board so I
> can toggle the pin that controls our LEDs on and off? On our
> development kit protoboard the LEDs are controlled by bits 2 and 3 of
> (parallel?) port B and on our actual project board we have 2 activity
> LEDs that are on (once again parallel?) port A bits 6 and 7 so I am
> trying to figure out how to make them blink for debugging purposes.
>
I never used brdInit() in DC as it puts all the initialization of ports
in DC's library. They pre-decided what is input, output or special
functions. You need to edit their library to change things. Update DC
and all your changes get lost.
In Softools, you will have to set ports A or B as outputs. For port A
look at SPCR, for pORTB use PBDDR.
> Also, we are using the DC functions serXwrite and serXputs (which
> really is just a wrapper for serXwrite), so are you saying we ought to
> redirect stdout to the serial ports we need to write and read from (in
> our case it is serC and serD)? Or is there a better way to do an
> equivalent operation in Softools?
>
No, but you can associate a FILE * to a serial port;
extern FILE * SerialC;
fprintf(SerialC,"Inputs 0 is %f volts, Input 1 is %f
amps\n",ana0,anal1);
Works but has no buffer control. Usually it it best to write your own
FILE handler to control buffer full conditions.
> Also, I am not sure I understand what you meant when you said:
>
> "The 4k is not completely supported in Softools. You will have to
> manually assign the port function regsisters for the pins if not using
> port C."
>
Softools support the Rabbit 3000 CPU. That allows serial ports to be
used on parallel port pins C or D. The lib has code to allow switching
to port D.
The 4K adds another layer as many pins have been lost over the 3k, now
many fins have 3 functions. There are new registers to remap the serial
pins from parallel port C to other pins. These have not been implemeted.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
One would like to stroke and caress human beings, but one dares not do so,
because they bite.
-- Vladimir Il'ich Lenin
> First of all, thanks for the quick response, and I must say that your
> tips are helpful as that DCDEFS.h is allowing me to reuse some of the
> code from before (i.e. BitWrPortI(...); ) I did notice, however, when
> I first tried to write a little program to blink the LED on the board
> in DC, it wouldn't work unless I had a brdInit() call. There is no
> corresponding macro for this in DCdefs.h and I assume it would depend
> very much on the board you are using, yes? Is there some other
> function that Softools has that I can use to initialize the board so I
> can toggle the pin that controls our LEDs on and off? On our
> development kit protoboard the LEDs are controlled by bits 2 and 3 of
> (parallel?) port B and on our actual project board we have 2 activity
> LEDs that are on (once again parallel?) port A bits 6 and 7 so I am
> trying to figure out how to make them blink for debugging purposes.
>
I never used brdInit() in DC as it puts all the initialization of ports
in DC's library. They pre-decided what is input, output or special
functions. You need to edit their library to change things. Update DC
and all your changes get lost.
In Softools, you will have to set ports A or B as outputs. For port A
look at SPCR, for pORTB use PBDDR.
> Also, we are using the DC functions serXwrite and serXputs (which
> really is just a wrapper for serXwrite), so are you saying we ought to
> redirect stdout to the serial ports we need to write and read from (in
> our case it is serC and serD)? Or is there a better way to do an
> equivalent operation in Softools?
>
No, but you can associate a FILE * to a serial port;
extern FILE * SerialC;
fprintf(SerialC,"Inputs 0 is %f volts, Input 1 is %f
amps\n",ana0,anal1);
Works but has no buffer control. Usually it it best to write your own
FILE handler to control buffer full conditions.
> Also, I am not sure I understand what you meant when you said:
>
> "The 4k is not completely supported in Softools. You will have to
> manually assign the port function regsisters for the pins if not using
> port C."
>
Softools support the Rabbit 3000 CPU. That allows serial ports to be
used on parallel port pins C or D. The lib has code to allow switching
to port D.
The 4K adds another layer as many pins have been lost over the 3k, now
many fins have 3 functions. There are new registers to remap the serial
pins from parallel port C to other pins. These have not been implemeted.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
One would like to stroke and caress human beings, but one dares not do so,
because they bite.
-- Vladimir Il'ich Lenin
Reply by ●October 31, 20082008-10-31
I tried to find in the Rabbit Manual how to initialize these ports
explicitly, but I was unable to find anything. Ultimately I went into
the RCM42xx.LIB file where brdInit() was located and extracted their
portion where they initialize port B and I copied that code into a
little program meant to toggle the DS3 LED on my RCM4300 breadboard.
The code is as follows:
#include
#include "rabbit.h"
#include "dcdefs.h"
#define DS2 0
#define DS3 1
#define DS2_BIT 2
#define DS3_BIT 3
/*delayMS written here*/
int main(void)
{
// Configure Port B
WrPortI(PBDR, &PBDRShadow, 0xCF);
WrPortI(PBDDR, &PBDDRShadow, 0xCF);
WDT_DISABLE();
ipset0();
while(1){
delayMS(200);
BitWrPortI(PBDR, &PBDRShadow, 0, DS3_BIT);
delayMS(200);
BitWrPortI(PBDR, &PBDRShadow, 1, DS3_BIT);
}
}
This code seems to work, but the really strange (or sick part
depending on how you look at it) is that the program runs normally
when I have the board connected via the programming header to the PC
and softools, but if I run the program in stand alone mode, THE WRONG
LED STARTS BLINKING! I am a bit stumped here. Can anyone tell me why
this code would work fine while connected and then do something
different (but still related)? Is there something I am missing here?
This is pretty disruptive behavior and it will make programming
impossible if the program acts one way while connected to a PC and
then totally differently while running stand alone.
Thanks in advance!
-MDiaz-Tello
explicitly, but I was unable to find anything. Ultimately I went into
the RCM42xx.LIB file where brdInit() was located and extracted their
portion where they initialize port B and I copied that code into a
little program meant to toggle the DS3 LED on my RCM4300 breadboard.
The code is as follows:
#include
#include "rabbit.h"
#include "dcdefs.h"
#define DS2 0
#define DS3 1
#define DS2_BIT 2
#define DS3_BIT 3
/*delayMS written here*/
int main(void)
{
// Configure Port B
WrPortI(PBDR, &PBDRShadow, 0xCF);
WrPortI(PBDDR, &PBDDRShadow, 0xCF);
WDT_DISABLE();
ipset0();
while(1){
delayMS(200);
BitWrPortI(PBDR, &PBDRShadow, 0, DS3_BIT);
delayMS(200);
BitWrPortI(PBDR, &PBDRShadow, 1, DS3_BIT);
}
}
This code seems to work, but the really strange (or sick part
depending on how you look at it) is that the program runs normally
when I have the board connected via the programming header to the PC
and softools, but if I run the program in stand alone mode, THE WRONG
LED STARTS BLINKING! I am a bit stumped here. Can anyone tell me why
this code would work fine while connected and then do something
different (but still related)? Is there something I am missing here?
This is pretty disruptive behavior and it will make programming
impossible if the program acts one way while connected to a PC and
then totally differently while running stand alone.
Thanks in advance!
-MDiaz-Tello
Reply by ●November 3, 20082008-11-03
Well, I did quite a bit of testing to see what was going on and I can
now predict what ought to happen when I run my RCM4200 in stand alone
mode, although I have no idea WHY this his happening.
Basically I started stripping out lines of code one by one from this
sample program, slowly breaking it until I had nothing left but the
following:
int main(void){
while(1){}
}
This is an apparently empty program that will just loop forever.
However, when I would run the board in stand alone mode, I would still
get the wrong light blinking. So, I thought that maybe this was
something that was being inserted by the CStart.asm file as some sort
of heartbeat or a panic message or something. At this point, I am not
sure why, but I decided to try out Dynamic C again. Here, I made the
same original sample program (to blink DS3 LED) and ran it and slowly
stripped out everything until i had the same
do-nothing-while-looping-forever program. I did not observe the same
behavior as before. So, I figured maybe my hypothesis was correct and
CStart.asm was doing something to the program. So, I went back into
softools and recompiled the empty program and ran in stand alone mode,
and now, instead of DS2 (the wrong LED) blinking as before, DS3 (the
proper LED) was blinking! This made me think that perhaps the Dynamic
C program was running in stand alone mode instead of my softools
program. So, I went back into DC and made a program that blinks both
DS2 AND DS3 and compiled / ran it. Then I went back into softools and
compiled and loaded the empty program. When I tried to run it in stand
alone mode, instead of nothing happening (as it should) BOTH DS2 AND
DS3 started blinking!
So, I understand now that for some reason, in stand alone mode the
RCM4200 is running DC programs. Why this is happening, I have no idea.
Could someone please help me out here?
-MDiaz-Tello
now predict what ought to happen when I run my RCM4200 in stand alone
mode, although I have no idea WHY this his happening.
Basically I started stripping out lines of code one by one from this
sample program, slowly breaking it until I had nothing left but the
following:
int main(void){
while(1){}
}
This is an apparently empty program that will just loop forever.
However, when I would run the board in stand alone mode, I would still
get the wrong light blinking. So, I thought that maybe this was
something that was being inserted by the CStart.asm file as some sort
of heartbeat or a panic message or something. At this point, I am not
sure why, but I decided to try out Dynamic C again. Here, I made the
same original sample program (to blink DS3 LED) and ran it and slowly
stripped out everything until i had the same
do-nothing-while-looping-forever program. I did not observe the same
behavior as before. So, I figured maybe my hypothesis was correct and
CStart.asm was doing something to the program. So, I went back into
softools and recompiled the empty program and ran in stand alone mode,
and now, instead of DS2 (the wrong LED) blinking as before, DS3 (the
proper LED) was blinking! This made me think that perhaps the Dynamic
C program was running in stand alone mode instead of my softools
program. So, I went back into DC and made a program that blinks both
DS2 AND DS3 and compiled / ran it. Then I went back into softools and
compiled and loaded the empty program. When I tried to run it in stand
alone mode, instead of nothing happening (as it should) BOTH DS2 AND
DS3 started blinking!
So, I understand now that for some reason, in stand alone mode the
RCM4200 is running DC programs. Why this is happening, I have no idea.
Could someone please help me out here?
-MDiaz-Tello
Reply by ●November 3, 20082008-11-03
Why don't you go to the Softools or WinIDE group. You will get much
more help with softools there than here.
-Pete
-----Original Message-----
From: r... [mailto:r...]
On Behalf Of mdiaz.tello
Sent: Monday, November 03, 2008 12:38 PM
To: r...
Subject: [rabbit-semi] Re: How to get started on softools?
Well, I did quite a bit of testing to see what was going on and I can
now predict what ought to happen when I run my RCM4200 in stand alone
mode, although I have no idea WHY this his happening.
Basically I started stripping out lines of code one by one from this
sample program, slowly breaking it until I had nothing left but the
following:
int main(void){
while(1){}
}
This is an apparently empty program that will just loop forever.
However, when I would run the board in stand alone mode, I would still
get the wrong light blinking. So, I thought that maybe this was
something that was being inserted by the CStart.asm file as some sort of
heartbeat or a panic message or something. At this point, I am not sure
why, but I decided to try out Dynamic C again. Here, I made the same
original sample program (to blink DS3 LED) and ran it and slowly
stripped out everything until i had the same
do-nothing-while-looping-forever program. I did not observe the same
behavior as before. So, I figured maybe my hypothesis was correct and
CStart.asm was doing something to the program. So, I went back into
softools and recompiled the empty program and ran in stand alone mode,
and now, instead of DS2 (the wrong LED) blinking as before, DS3 (the
proper LED) was blinking! This made me think that perhaps the Dynamic C
program was running in stand alone mode instead of my softools program.
So, I went back into DC and made a program that blinks both
DS2 AND DS3 and compiled / ran it. Then I went back into softools and
compiled and loaded the empty program. When I tried to run it in stand
alone mode, instead of nothing happening (as it should) BOTH DS2 AND
DS3 started blinking!
So, I understand now that for some reason, in stand alone mode the
RCM4200 is running DC programs. Why this is happening, I have no idea.
Could someone please help me out here?
-MDiaz-Tello
more help with softools there than here.
-Pete
-----Original Message-----
From: r... [mailto:r...]
On Behalf Of mdiaz.tello
Sent: Monday, November 03, 2008 12:38 PM
To: r...
Subject: [rabbit-semi] Re: How to get started on softools?
Well, I did quite a bit of testing to see what was going on and I can
now predict what ought to happen when I run my RCM4200 in stand alone
mode, although I have no idea WHY this his happening.
Basically I started stripping out lines of code one by one from this
sample program, slowly breaking it until I had nothing left but the
following:
int main(void){
while(1){}
}
This is an apparently empty program that will just loop forever.
However, when I would run the board in stand alone mode, I would still
get the wrong light blinking. So, I thought that maybe this was
something that was being inserted by the CStart.asm file as some sort of
heartbeat or a panic message or something. At this point, I am not sure
why, but I decided to try out Dynamic C again. Here, I made the same
original sample program (to blink DS3 LED) and ran it and slowly
stripped out everything until i had the same
do-nothing-while-looping-forever program. I did not observe the same
behavior as before. So, I figured maybe my hypothesis was correct and
CStart.asm was doing something to the program. So, I went back into
softools and recompiled the empty program and ran in stand alone mode,
and now, instead of DS2 (the wrong LED) blinking as before, DS3 (the
proper LED) was blinking! This made me think that perhaps the Dynamic C
program was running in stand alone mode instead of my softools program.
So, I went back into DC and made a program that blinks both
DS2 AND DS3 and compiled / ran it. Then I went back into softools and
compiled and loaded the empty program. When I tried to run it in stand
alone mode, instead of nothing happening (as it should) BOTH DS2 AND
DS3 started blinking!
So, I understand now that for some reason, in stand alone mode the
RCM4200 is running DC programs. Why this is happening, I have no idea.
Could someone please help me out here?
-MDiaz-Tello
Reply by ●November 3, 20082008-11-03
mdiaz.tello wrote:
> Well, I did quite a bit of testing to see what was going on and I can
> now predict what ought to happen when I run my RCM4200 in stand alone
> mode, although I have no idea WHY this his happening.
>
> Basically I started stripping out lines of code one by one from this
> sample program, slowly breaking it until I had nothing left but the
> following:
>
> int main(void){
> while(1){}
> }
>
> This is an apparently empty program that will just loop forever.
> However, when I would run the board in stand alone mode, I would still
> get the wrong light blinking.
You need to disable the watchdog or the board will continuously reset.
You should move this to the softools group. I can give more help there.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Ego sum ens omnipotens.
> Well, I did quite a bit of testing to see what was going on and I can
> now predict what ought to happen when I run my RCM4200 in stand alone
> mode, although I have no idea WHY this his happening.
>
> Basically I started stripping out lines of code one by one from this
> sample program, slowly breaking it until I had nothing left but the
> following:
>
> int main(void){
> while(1){}
> }
>
> This is an apparently empty program that will just loop forever.
> However, when I would run the board in stand alone mode, I would still
> get the wrong light blinking.
You need to disable the watchdog or the board will continuously reset.
You should move this to the softools group. I can give more help there.
--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Ego sum ens omnipotens.
Reply by ●November 3, 20082008-11-03
I apologize for this last post here, but I wanted to let you guys know a couple
of things, just in case there is someone else on this forum who is having the
same difficulties I had. I have moved this question over to the softools yahoo
group as per the previous requests. Also, I have figured out what my problem
was.
It turns out that when you tell softools to compile and load the program onto your RCMxxxx, it will load that program into RAM only. I thought that - similar to other compilers - when I compiled the source, it would load my program into RAM and burn it into FLASH, but in softools you must tell it explicitly to burn the program into FLASH memory. There may be an option to do this automatically, but I will have to look into that.
So, my problem turned out to be more associated with learning the nuances of a new interface rather than a fundamental problem, and for that I am grateful.
Thank you to everyone who offered advice, and I will be sure to post further softools questions in the appropriate group in the future.
-MDiaz-Tello
It turns out that when you tell softools to compile and load the program onto your RCMxxxx, it will load that program into RAM only. I thought that - similar to other compilers - when I compiled the source, it would load my program into RAM and burn it into FLASH, but in softools you must tell it explicitly to burn the program into FLASH memory. There may be an option to do this automatically, but I will have to look into that.
So, my problem turned out to be more associated with learning the nuances of a new interface rather than a fundamental problem, and for that I am grateful.
Thank you to everyone who offered advice, and I will be sure to post further softools questions in the appropriate group in the future.
-MDiaz-Tello
