Sign in
Search rabbit-semi
Subscribe to rabbit-semi
Ads
Discussion Groups
See Also
Discussion Groups | Rabbit-Semi | More Assembly Woes
This is a group for folks designing and programming embedded systems using the Rabbit Semiconductor C-programmable microcontroller. Rabbit Semi is a spin-off from Z-World who makes a variety of embedded modules and tools. This group is not affiliated with either Rabbit or Z-World, but is a user forum for sharing ideas, asking questions, flaunting knowledge, and other typical user group stuff. The Rabbit is a powerful uC, supported by a full-featured C-compiler.
More Assembly Woes - Shawn - Jun 2 15:03:17 2009
Well, I figured it out, after half a day.
I had a function, with several local byte-sized variables. Inside the function, I pass some values to the char's, and then jump to assembly. The intent being, I pass say an int to my function, and then break it into 8 bit chunks, and then do stuff in assembly in response to those variables.
For whatever reason, this does not work. The 8 bit variables must be defined outside of the function! Once I pulled these out of my function, and made them global, stuff passed correctly. I guess local variables are defined on the stack, and stack locations cannot be called by "ld a,(data)"?
Basically, this does not work:
void func(void)
{
char i1;
i1=0x4;
#asm
push a
ld a,(i1)
etc
}
but this does:
/*** BeginHeader i1 */
char i1;
/*** EndHeader */
void func(void)
{
i1=0x4;
#asm
push a
ld a,(i1)
etc
}
In the first function, if I look at the assembly code, the i1=0x4 would load (say) memory location 0x0004 with 0x4. But the ld a,(i1) would load accumulator a with memory location 0xffff! In the second, i1 becomes memory location 0x6c7something, and everything works properly.
Shawn
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
I had a function, with several local byte-sized variables. Inside the function, I pass some values to the char's, and then jump to assembly. The intent being, I pass say an int to my function, and then break it into 8 bit chunks, and then do stuff in assembly in response to those variables.
For whatever reason, this does not work. The 8 bit variables must be defined outside of the function! Once I pulled these out of my function, and made them global, stuff passed correctly. I guess local variables are defined on the stack, and stack locations cannot be called by "ld a,(data)"?
Basically, this does not work:
void func(void)
{
char i1;
i1=0x4;
#asm
push a
ld a,(i1)
etc
}
but this does:
/*** BeginHeader i1 */
char i1;
/*** EndHeader */
void func(void)
{
i1=0x4;
#asm
push a
ld a,(i1)
etc
}
In the first function, if I look at the assembly code, the i1=0x4 would load (say) memory location 0x0004 with 0x4. But the ld a,(i1) would load accumulator a with memory location 0xffff! In the second, i1 becomes memory location 0x6c7something, and everything works properly.
Shawn
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Scott Henion - Jun 2 15:47:34 2009
Shawn wrote:
> Well, I figured it out, after half a day.
>
> I had a function, with several local byte-sized variables. Inside the function, I pass some values to the char's, and then jump to assembly. The intent being, I pass say an int to my function, and then break it into 8 bit chunks, and then do stuff in assembly in response to those variables.
>
> For whatever reason, this does not work. The 8 bit variables must be defined outside of the function! Once I pulled these out of my function, and made them global, stuff passed correctly. I guess local variables are defined on the stack, and stack locations cannot be called by "ld a,(data)"?
>
> Basically, this does not work:
>
> void func(void)
> {
> char i1;
> i1=0x4;
> #asm
> push a
> ld a,(i1)
>
> etc
> }
>
>
int i1;
within a function will store the variable in the stack. So you need to
use the offset from the stack pointer:
ld a,(SP+@SP+i1)
If you delcare the variable static, it will be stored outside the
function at a fixed address:
static int i1;
There is a section in the DC manual on mixing assembly language and C.
--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------
today's fortune
QOTD:
"He's on the same bus, but he's sure as hell got a different
ticket."
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> Well, I figured it out, after half a day.
>
> I had a function, with several local byte-sized variables. Inside the function, I pass some values to the char's, and then jump to assembly. The intent being, I pass say an int to my function, and then break it into 8 bit chunks, and then do stuff in assembly in response to those variables.
>
> For whatever reason, this does not work. The 8 bit variables must be defined outside of the function! Once I pulled these out of my function, and made them global, stuff passed correctly. I guess local variables are defined on the stack, and stack locations cannot be called by "ld a,(data)"?
>
> Basically, this does not work:
>
> void func(void)
> {
> char i1;
> i1=0x4;
> #asm
> push a
> ld a,(i1)
>
> etc
> }
>
>
int i1;
within a function will store the variable in the stack. So you need to
use the offset from the stack pointer:
ld a,(SP+@SP+i1)
If you delcare the variable static, it will be stored outside the
function at a fixed address:
static int i1;
There is a section in the DC manual on mixing assembly language and C.
--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------
today's fortune
QOTD:
"He's on the same bus, but he's sure as hell got a different
ticket."
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Robert Richter - Jun 2 15:48:17 2009
--- In r...@yahoogroups.com, "Shawn" wrote:
>
> Well, I figured it out, after half a day.
>
> I had a function, with several local byte-sized variables. Inside the function, I pass some values to the char's, and then jump to assembly. The intent being, I pass say an int to my function, and then break it into 8 bit chunks, and then do stuff in assembly in response to those variables.
>
> For whatever reason, this does not work. The 8 bit variables must be defined outside of the function! Once I pulled these out of my function, and made them global, stuff passed correctly. I guess local variables are defined on the stack, and stack locations cannot be called by "ld a,(data)"?
>
> Basically, this does not work:
>
> void func(void)
> {
> char i1;
> i1=0x4;
> #asm
> push a
> ld a,(i1)
>
> etc
> }
>
> but this does:
>
> /*** BeginHeader i1 */
> char i1;
> /*** EndHeader */
> void func(void)
> {
> i1=0x4;
> #asm
> push a
> ld a,(i1)
>
> etc
> }
>
> In the first function, if I look at the assembly code, the i1=0x4 would load (say) memory location 0x0004 with 0x4. But the ld a,(i1) would load accumulator a with memory location 0xffff! In the second, i1 becomes memory location 0x6c7something, and everything works properly.
>
> Shawn
>
Local variables are relative to the stack pointer plus @sp, so the 0xFFFF is the same as -1, which means the variable is one byte away from the current stack pointer.
#asm
push af ; push a is not legal
ld hl, i1+@SP+2 ; The extra 2 because of the push statement.
add hl, sp
ld a, (hl)
; If you are reading and not writing, there are some 16 bit commands that make life easier
This variable @SP is equal to the number of local variables. When declaring a function useix, you can also use the ix register for local variables, in which case you don't use @sp
useix void func(void)
{
char i1;
i1=0x4;
#asm
push a
ld a,(ix+i1)
etc
}
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>
> Well, I figured it out, after half a day.
>
> I had a function, with several local byte-sized variables. Inside the function, I pass some values to the char's, and then jump to assembly. The intent being, I pass say an int to my function, and then break it into 8 bit chunks, and then do stuff in assembly in response to those variables.
>
> For whatever reason, this does not work. The 8 bit variables must be defined outside of the function! Once I pulled these out of my function, and made them global, stuff passed correctly. I guess local variables are defined on the stack, and stack locations cannot be called by "ld a,(data)"?
>
> Basically, this does not work:
>
> void func(void)
> {
> char i1;
> i1=0x4;
> #asm
> push a
> ld a,(i1)
>
> etc
> }
>
> but this does:
>
> /*** BeginHeader i1 */
> char i1;
> /*** EndHeader */
> void func(void)
> {
> i1=0x4;
> #asm
> push a
> ld a,(i1)
>
> etc
> }
>
> In the first function, if I look at the assembly code, the i1=0x4 would load (say) memory location 0x0004 with 0x4. But the ld a,(i1) would load accumulator a with memory location 0xffff! In the second, i1 becomes memory location 0x6c7something, and everything works properly.
>
> Shawn
>
Local variables are relative to the stack pointer plus @sp, so the 0xFFFF is the same as -1, which means the variable is one byte away from the current stack pointer.
#asm
push af ; push a is not legal
ld hl, i1+@SP+2 ; The extra 2 because of the push statement.
add hl, sp
ld a, (hl)
; If you are reading and not writing, there are some 16 bit commands that make life easier
This variable @SP is equal to the number of local variables. When declaring a function useix, you can also use the ix register for local variables, in which case you don't use @sp
useix void func(void)
{
char i1;
i1=0x4;
#asm
push a
ld a,(ix+i1)
etc
}
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Shawn Upton - Jun 2 20:28:12 2009
Interesting stuff; will continue to read up on the local variables living on the stack. Thanks again for the help.
Shawn Upton, KB1CKT
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Robert Richter - Jun 3 13:34:49 2009
--- In r...@yahoogroups.com, Shawn Upton wrote:
> Interesting stuff; will continue to read up on the local variables living on the stack. Thanks again for the help.
>
> Shawn Upton, KB1CKT
>
A good way to learn assembly is just create list files and see the code created in response to various source code lines.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
> Interesting stuff; will continue to read up on the local variables living on the stack. Thanks again for the help.
>
> Shawn Upton, KB1CKT
>
A good way to learn assembly is just create list files and see the code created in response to various source code lines.
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - eilidhs_daddy - Jun 3 14:44:26 2009
--- In r...@yahoogroups.com, Shawn Upton wrote:
>
>=20
> Interesting stuff; will continue to read up on the local variables living=
on the stack. Thanks again for the help.
>=20
> Shawn Upton, KB1CKT
>
It sounds to me like you are having a 'baptism of fire' or to use another c=
lich=E9 have 'thrown yourself in at the deep end' by dealing with assembly =
to do primitive things.
Why not use C, either the DynamicC which comes free from Rabbit, or SoftToo=
ls.
Some will tell you that C is slow and clunky, but that is a common misconce=
ption. Write your function in C, and look at the assembly that is generated=
- it's pretty good, and perfectly acceptable for most embedded tasks.
I only drop out to assembly for things which have to be hand optimized and/=
or are timing critical.
It would be a lot easier to learn C than Rabbit Assembly!
Best reagrds,
-Kenny
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>
>=20
> Interesting stuff; will continue to read up on the local variables living=
on the stack. Thanks again for the help.
>=20
> Shawn Upton, KB1CKT
>
It sounds to me like you are having a 'baptism of fire' or to use another c=
lich=E9 have 'thrown yourself in at the deep end' by dealing with assembly =
to do primitive things.
Why not use C, either the DynamicC which comes free from Rabbit, or SoftToo=
ls.
Some will tell you that C is slow and clunky, but that is a common misconce=
ption. Write your function in C, and look at the assembly that is generated=
- it's pretty good, and perfectly acceptable for most embedded tasks.
I only drop out to assembly for things which have to be hand optimized and/=
or are timing critical.
It would be a lot easier to learn C than Rabbit Assembly!
Best reagrds,
-Kenny
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Shawn - Jun 3 16:40:26 2009
For some reason, my reply got lost in yahoo, go figure...
The short answer is, I'm writing in assembly as the code I'm putting togeth=
er is for sending and recieving manchester coding at 100kbps. Maybe I can =
get the C code to do that, but I'm not so sure. I certainly could not do a=
ny sort of for/while loops, as the timing is rather important; and I have m=
ore than 8 bits to send too. Maybe on sending I could; but I have some res=
ervations on recieve.
The worst part is, as I dig through the archive here, I last worked on Rabb=
it code 2 years ago. No wonder why it's like learning code all over again!=
Of course, once I figure this out, it'll be another 2 years before I hit =
it again...
Shawn
--- In r...@yahoogroups.com, "eilidhs_daddy" wrote:
>
> --- In r...@yahoogroups.com, Shawn Upton wrote:
> >
> >=20
> > Interesting stuff; will continue to read up on the local variables livi=
ng on the stack. Thanks again for the help.
> >=20
> > Shawn Upton, KB1CKT
> >
>=20
> It sounds to me like you are having a 'baptism of fire' or to use another=
clich=E9 have 'thrown yourself in at the deep end' by dealing with assembl=
y to do primitive things.
>=20
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftT=
ools.
>=20
> Some will tell you that C is slow and clunky, but that is a common miscon=
ception. Write your function in C, and look at the assembly that is generat=
ed - it's pretty good, and perfectly acceptable for most embedded tasks.
>=20
> I only drop out to assembly for things which have to be hand optimized an=
d/or are timing critical.
>=20
> It would be a lot easier to learn C than Rabbit Assembly!
>=20
> Best reagrds,
> -Kenny
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
The short answer is, I'm writing in assembly as the code I'm putting togeth=
er is for sending and recieving manchester coding at 100kbps. Maybe I can =
get the C code to do that, but I'm not so sure. I certainly could not do a=
ny sort of for/while loops, as the timing is rather important; and I have m=
ore than 8 bits to send too. Maybe on sending I could; but I have some res=
ervations on recieve.
The worst part is, as I dig through the archive here, I last worked on Rabb=
it code 2 years ago. No wonder why it's like learning code all over again!=
Of course, once I figure this out, it'll be another 2 years before I hit =
it again...
Shawn
--- In r...@yahoogroups.com, "eilidhs_daddy"
>
> --- In r...@yahoogroups.com, Shawn Upton
> >
> >=20
> > Interesting stuff; will continue to read up on the local variables livi=
ng on the stack. Thanks again for the help.
> >=20
> > Shawn Upton, KB1CKT
> >
>=20
> It sounds to me like you are having a 'baptism of fire' or to use another=
clich=E9 have 'thrown yourself in at the deep end' by dealing with assembl=
y to do primitive things.
>=20
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftT=
ools.
>=20
> Some will tell you that C is slow and clunky, but that is a common miscon=
ception. Write your function in C, and look at the assembly that is generat=
ed - it's pretty good, and perfectly acceptable for most embedded tasks.
>=20
> I only drop out to assembly for things which have to be hand optimized an=
d/or are timing critical.
>=20
> It would be a lot easier to learn C than Rabbit Assembly!
>=20
> Best reagrds,
> -Kenny
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Shawn - Jun 3 21:24:24 2009
C I can sorta understand. I keep running back to the book when it gets to =
pointers, and honestly, I'm not sure if I like the idea that Dynamic C isn'=
t ANSI C; but that's neither here nor there. All software requires a learn=
ing curve.
Anyhow, on this project I need to generate 100kbps manchester coding. Well=
, the exact bit rate isn't important, as much as not screwing up the clock.=
Next trick: reading back 100kbps manchester coding...
I'm a little dubious at the moment of using C to generate this sort of timi=
ng. Yeah, it's reasonably tight, and if I set the priorities right, it won=
't get interupted; but still: this seems like I'd best be in assembly, or t=
he C code would look a lot like assembly when I got done with it. Ie, no f=
or/while loops, but rather every line of code spelt out, so as to avoid an =
extra bit of lost time here when jumping from one variable to another. [I'=
m sending/recieving like 30plus bits of data--and no, not a multiple of 8 e=
ither.]
The worst part? I'll figure this all out (still have to figure out interru=
pts, TimerA and input capture), then I won't touch Rabbit code (or code in =
general) for a couple of years. Then I'll have to relearn it all over agai=
n...
Shawn
--- In r...@yahoogroups.com, "eilidhs_daddy" wrote:
> It sounds to me like you are having a 'baptism of fire' or to use another=
clich=E9 have 'thrown yourself in at the deep end' by dealing with assembl=
y to do primitive things.
>=20
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftT=
ools.
>=20
> Some will tell you that C is slow and clunky, but that is a common miscon=
ception. Write your function in C, and look at the assembly that is generat=
ed - it's pretty good, and perfectly acceptable for most embedded tasks.
>=20
> I only drop out to assembly for things which have to be hand optimized an=
d/or are timing critical.
>=20
> It would be a lot easier to learn C than Rabbit Assembly!
>=20
> Best reagrds,
> -Kenny
>
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
pointers, and honestly, I'm not sure if I like the idea that Dynamic C isn'=
t ANSI C; but that's neither here nor there. All software requires a learn=
ing curve.
Anyhow, on this project I need to generate 100kbps manchester coding. Well=
, the exact bit rate isn't important, as much as not screwing up the clock.=
Next trick: reading back 100kbps manchester coding...
I'm a little dubious at the moment of using C to generate this sort of timi=
ng. Yeah, it's reasonably tight, and if I set the priorities right, it won=
't get interupted; but still: this seems like I'd best be in assembly, or t=
he C code would look a lot like assembly when I got done with it. Ie, no f=
or/while loops, but rather every line of code spelt out, so as to avoid an =
extra bit of lost time here when jumping from one variable to another. [I'=
m sending/recieving like 30plus bits of data--and no, not a multiple of 8 e=
ither.]
The worst part? I'll figure this all out (still have to figure out interru=
pts, TimerA and input capture), then I won't touch Rabbit code (or code in =
general) for a couple of years. Then I'll have to relearn it all over agai=
n...
Shawn
--- In r...@yahoogroups.com, "eilidhs_daddy"
> It sounds to me like you are having a 'baptism of fire' or to use another=
clich=E9 have 'thrown yourself in at the deep end' by dealing with assembl=
y to do primitive things.
>=20
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftT=
ools.
>=20
> Some will tell you that C is slow and clunky, but that is a common miscon=
ception. Write your function in C, and look at the assembly that is generat=
ed - it's pretty good, and perfectly acceptable for most embedded tasks.
>=20
> I only drop out to assembly for things which have to be hand optimized an=
d/or are timing critical.
>=20
> It would be a lot easier to learn C than Rabbit Assembly!
>=20
> Best reagrds,
> -Kenny
>
------------------------------------
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
RE: Re: More Assembly Woes - "Moore, Robert" - Jun 3 21:33:36 2009
In DC under Project Options you can optimize the compiler for size or speed. Sort of like
the older Inline vs Threaded code option in languages like DECs Fortran IV . . . Although
Rabbit doesn't seem to give much real information about this. Anyone know much about this
option ??
bob moore
________________________________
From: r...@yahoogroups.com on behalf of Shawn
Sent: Wed 6/3/2009 3:17 PM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: More Assembly Woes
C I can sorta understand. I keep running back to the book when it gets to pointers, and honestly, I'm not sure if I like the idea that Dynamic C isn't ANSI C; but that's neither here nor there. All software requires a learning curve.
Anyhow, on this project I need to generate 100kbps manchester coding. Well, the exact bit rate isn't important, as much as not screwing up the clock. Next trick: reading back 100kbps manchester coding...
I'm a little dubious at the moment of using C to generate this sort of timing. Yeah, it's reasonably tight, and if I set the priorities right, it won't get interupted; but still: this seems like I'd best be in assembly, or the C code would look a lot like assembly when I got done with it. Ie, no for/while loops, but rather every line of code spelt out, so as to avoid an extra bit of lost time here when jumping from one variable to another. [I'm sending/recieving like 30plus bits of data--and no, not a multiple of 8 either.]
The worst part? I'll figure this all out (still have to figure out interrupts, TimerA and input capture), then I won't touch Rabbit code (or code in general) for a couple of years. Then I'll have to relearn it all over again...
Shawn
--- In r...@yahoogroups.com, "eilidhs_daddy" wrote:
> It sounds to me like you are having a 'baptism of fire' or to use another cliché have 'thrown yourself in at the deep end' by dealing with assembly to do primitive things.
>
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftTools.
>
> Some will tell you that C is slow and clunky, but that is a common misconception. Write your function in C, and look at the assembly that is generated - it's pretty good, and perfectly acceptable for most embedded tasks.
>
> I only drop out to assembly for things which have to be hand optimized and/or are timing critical.
>
> It would be a lot easier to learn C than Rabbit Assembly!
>
> Best reagrds,
> -Kenny
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
bob moore
________________________________
From: r...@yahoogroups.com on behalf of Shawn
Sent: Wed 6/3/2009 3:17 PM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: More Assembly Woes
C I can sorta understand. I keep running back to the book when it gets to pointers, and honestly, I'm not sure if I like the idea that Dynamic C isn't ANSI C; but that's neither here nor there. All software requires a learning curve.
Anyhow, on this project I need to generate 100kbps manchester coding. Well, the exact bit rate isn't important, as much as not screwing up the clock. Next trick: reading back 100kbps manchester coding...
I'm a little dubious at the moment of using C to generate this sort of timing. Yeah, it's reasonably tight, and if I set the priorities right, it won't get interupted; but still: this seems like I'd best be in assembly, or the C code would look a lot like assembly when I got done with it. Ie, no for/while loops, but rather every line of code spelt out, so as to avoid an extra bit of lost time here when jumping from one variable to another. [I'm sending/recieving like 30plus bits of data--and no, not a multiple of 8 either.]
The worst part? I'll figure this all out (still have to figure out interrupts, TimerA and input capture), then I won't touch Rabbit code (or code in general) for a couple of years. Then I'll have to relearn it all over again...
Shawn
--- In r...@yahoogroups.com, "eilidhs_daddy"
> It sounds to me like you are having a 'baptism of fire' or to use another cliché have 'thrown yourself in at the deep end' by dealing with assembly to do primitive things.
>
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftTools.
>
> Some will tell you that C is slow and clunky, but that is a common misconception. Write your function in C, and look at the assembly that is generated - it's pretty good, and perfectly acceptable for most embedded tasks.
>
> I only drop out to assembly for things which have to be hand optimized and/or are timing critical.
>
> It would be a lot easier to learn C than Rabbit Assembly!
>
> Best reagrds,
> -Kenny
>
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
RE: Re: More Assembly Woes - Nathan Johnston - Jun 3 23:42:37 2009
If you are doing Manchester then make sure you are no reinventing the wheel. The HDLC
ports (serial ports E and F) support Manchester in hardware. I have used the HDLC before
but not for Manchester so can't vouch for it.
Regards,
Nathan
-----Original Message-----
From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On Behalf Of Shawn
Sent: Thursday, 4 June 2009 6:40 AM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: More Assembly Woes
For some reason, my reply got lost in yahoo, go figure...
The short answer is, I'm writing in assembly as the code I'm putting together is for sending and recieving manchester coding at 100kbps. Maybe I can get the C code to do that, but I'm not so sure. I certainly could not do any sort of for/while loops, as the timing is rather important; and I have more than 8 bits to send too. Maybe on sending I could; but I have some reservations on recieve.
The worst part is, as I dig through the archive here, I last worked on Rabbit code 2 years ago. No wonder why it's like learning code all over again! Of course, once I figure this out, it'll be another 2 years before I hit it again...
Shawn
--- In r...@yahoogroups.com , "eilidhs_daddy"
wrote:
>
> --- In r...@yahoogroups.com , Shawn Upton
wrote:
> >
> >
> > Interesting stuff; will continue to read up on the local variables living on the stack. Thanks again for the help.
> >
> > Shawn Upton, KB1CKT
> > It sounds to me like you are having a 'baptism of fire' or to use another cliché have 'thrown yourself in at the deep end' by dealing with assembly to do primitive things.
>
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftTools.
>
> Some will tell you that C is slow and clunky, but that is a common misconception. Write your function in C, and look at the assembly that is generated - it's pretty good, and perfectly acceptable for most embedded tasks.
>
> I only drop out to assembly for things which have to be hand optimized and/or are timing critical.
>
> It would be a lot easier to learn C than Rabbit Assembly!
>
> Best reagrds,
> -Kenny
>
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Regards,
Nathan
-----Original Message-----
From: r...@yahoogroups.com [mailto:r...@yahoogroups.com] On Behalf Of Shawn
Sent: Thursday, 4 June 2009 6:40 AM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: More Assembly Woes
For some reason, my reply got lost in yahoo, go figure...
The short answer is, I'm writing in assembly as the code I'm putting together is for sending and recieving manchester coding at 100kbps. Maybe I can get the C code to do that, but I'm not so sure. I certainly could not do any sort of for/while loops, as the timing is rather important; and I have more than 8 bits to send too. Maybe on sending I could; but I have some reservations on recieve.
The worst part is, as I dig through the archive here, I last worked on Rabbit code 2 years ago. No wonder why it's like learning code all over again! Of course, once I figure this out, it'll be another 2 years before I hit it again...
Shawn
--- In r...@yahoogroups.com
>
> --- In r...@yahoogroups.com
> >
> >
> > Interesting stuff; will continue to read up on the local variables living on the stack. Thanks again for the help.
> >
> > Shawn Upton, KB1CKT
> > It sounds to me like you are having a 'baptism of fire' or to use another cliché have 'thrown yourself in at the deep end' by dealing with assembly to do primitive things.
>
> Why not use C, either the DynamicC which comes free from Rabbit, or SoftTools.
>
> Some will tell you that C is slow and clunky, but that is a common misconception. Write your function in C, and look at the assembly that is generated - it's pretty good, and perfectly acceptable for most embedded tasks.
>
> I only drop out to assembly for things which have to be hand optimized and/or are timing critical.
>
> It would be a lot easier to learn C than Rabbit Assembly!
>
> Best reagrds,
> -Kenny
>
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
Re: More Assembly Woes - Robert Richter - Jun 4 1:27:33 2009
--- In r...@yahoogroups.com, "Moore, Robert" wrote:
>
> In DC under Project Options you can optimize the compiler for size or speed. Sort of like the older Inline vs Threaded code option in languages like DECs Fortran IV . . . Although Rabbit doesn't seem to give much real information about this. Anyone know much about this option ??
>
> bob moore
Some expressions involving long integers are done in-line (optimize for speed) or with a system call (optimize for size). There may be more.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )
>
> In DC under Project Options you can optimize the compiler for size or speed. Sort of like the older Inline vs Threaded code option in languages like DECs Fortran IV . . . Although Rabbit doesn't seem to give much real information about this. Anyone know much about this option ??
>
> bob moore
Some expressions involving long integers are done in-line (optimize for speed) or with a system call (optimize for size). There may be more.
------------------------------------
______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!
(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )