27c256 | 4K81H | 68HC11A1 | 68HC11P1 | 68hc24 | 68HC711E9 | 68HC811 | 8255 | A2D | ADC | ADC12138 | Am85C30 | BRCLR | Buffalo | CMOS | EEPROM | EPROM | Ethernet | EVB | EVBU | HC11E1 | HC11E9 | HC711E9 | Horray | ImageCraft | IRQ | Keypad | LCD | MC68HC11D0FN | MC68HC11E1CFU3 | MC68HC11F1 | MC68HC711E9 | MC68HC711E9CFN2 | Microcore11 | Microstamp11 | Minikit | NVRAM | PSD | PSD8xx | PSD9xx | PT1000 | RS232 | RTS | RXD | SPI | SRAM | TXD | Watchdogs | XIRQ

I have tried the C books you guys recomended(a long time ago), but one teaches assembler(not C) and the other I cannot find (reference books from motorola). Please help me find a book that teaches C for embedded systems. I am trying hard to find books, but i don't know if they are for the 68hc11 or not. I also need a good C compiler. I don't know the memory registers or stuff like stack and other things, so I need something very basic.

Thanks for your time,
Ravi
---------------------------------
Yahoo! Personals
Single? There's someone we'd like you to meet.
Lot's of someone's, actually. Yahoo! Personals

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Ravi Haksar wrote:

A single very long unreadable line, which I re-wrapped for him.

> I have tried the C books you guys recomended(a long time ago), but
> one teaches assembler(not C) and the other I cannot find (reference
> books from motorola). Please help me find a book that teaches C for
> embedded systems. I am trying hard to find books, but i don't know
> if they are for the 68hc11 or not. I also need a good C compiler.
> I don't know the memory registers or stuff like stack and other
> things, so I need something very basic.

You are really asking for three different things:

(1) A good book on C which you can learn from.
(2) A good book describing the MC68HC11 architecture.
(3) A good book describing how to do embedded programming
with a particular given compiler.

These are very different things. In a certain sense, C is C is C,
and it doesn't matter what book you learn C from. I suggest
the oldy and goldy by Kernigan and Ritchie to learn C.
Get the newer version which has been adapted to ANSI C.
I recommend you stay away from Schildt's books.

You can't get better than the reference manuals for the 6811
for learning the architecture. They are now owned by Freescale,
not Motorola. I suggest going to http://www.freescale.com/
and poking around.

Now, once you understand C, and you know the architecture of
the processor, you need to understand how *your* compiler gets
things going on the processor. For that, you need documentation
supplied by your compiler vendor.

I'll say this much: once you understand C and the architecture
of your machine, it's not a far leap to writing all but the
startup for the 6811.

For example, let's suppose you need to access the A/D on your
machine, and you want to bypass whatever routines may be
supplied by your compiler vendor. Ok, how to do that?

Well, first understand the A/D. Then understand how to access
the registers. One easy way to access the registers is simply
to put a definition of them into a header file. I'd do all of
one processor family (like the A series).

For example, one could do this in a header like m68hc11a.h

#ifndef M68HC11A_H
#define M68HC11A_H

...

#define ADCTL (*(volatile unsigned char *)0x1030)
#define ADR1 (*(const volatile unsigned char *)0x1031)
#define ADR2 (*(const volatile unsigned char *)0x1032)
#define ADR3 (*(const volatile unsigned char *)0x1033)
#define ADR4 (*(const volatile unsigned char *)0x1034)

#define AD_CCF 0x80
#define AD_SCAN 0x20
#define AD_MULT 0x10
#define AD_CHAN 0x0F

...

#define OPTION (*(unsigned char *)0x1039)

#define ADPU 0x80

...

#endif

Once you've got this, you can write an interface like this:

(in m6811ad.h)

#ifndef M6811AD_H
#define M6811AD_H

#include <m68hc11a.h void AdPowerUp(void);
void AdPowerDn(void);
unsigned int AdConvert(unsigned int Channel,int ConservePower);

#define AdPowerUp() (OPTION |= ADPU)
#define AdPowerDn() (OPTION &= ~ADPU)

#endif

The macros override the routines and place in-line code
into your program. If you take the address of the routine,
though, one *is* provided. Also, you can force using the
routine if you really want to by using parentheses.

And in m6811ad.c

#include <m68hc11ad.h>

void (AdPowerUp)(void) {
AdPowerUp();
}

void (AdPowerDn)(void) {
AdPowerDn();
}

unsigned int AdConvert(unsigned int Channel,int ConservePower) {
unsigned int Result;

if (Channel > 7)
Result = (unsigned int)-1;
else {
if (ConservePower) {
AdPowerUp();
uDelay(100*MICROSEC);
}
ADCTL = Channel;
while ((ADCTL & AD_CCF) == 0)
;
if (ConservePower)
AdPowerDn();
Result = ADR1;
}
return Result;
} Naturally, these bare routines need comments etc. I'll leave
writing uDelay() as an exercise for the reader. > Thanks for your time,
> Ravi

These routines are provided as-is with no warrantee, etc.
They are examples only, and have not been compiled, tested,
nor are the fit for any purpose.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

I first want to say that your last email was quite helpful. I looked at the book you recommended- The C Programming Language by K&R- and I wondering if it teaches embedded C. I have looked at both embedded C books and regular C books and I noticed that the header files are different. Is there a big difference? Or can C be adapted for embedded systems?

Also, is there any special code for motor controllers? Is it controlled just by switching I/O ports on and off? I have a motor controller chip and I need to know how to control it so I can get my robot to move. I also have a problem in trying to get C compilers. Most of them I see are very expensive and I want to get a free one. Another site recomended a free compiler, but when I try to use it, It comes up with a lot of errors that I don't know to fix.

Lastly, I looked at Freescale reference manuals for it and some of the commands are in assembly. Some tables look weird, but i have been able to reconize things like the memory adresses. I'll keep looking through it and I'm pretty sure I will be able to learn the architecture. I just hope that I will be able to find the adresses for the different modes and ports.

Thanks,
Ravi
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs. Try it free.

[Non-text portions of this message have been removed]



(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

In a message dated 11/29/2005 2:26:53 PM Pacific Standard Time,
r0807s@r080... writes:

wondering if it teaches embedded C. I have looked at both embedded C books
and regular C books and I noticed that the header files are different. Is
there a big difference? Or can C be adapted for embedded systems?
====================================================
On an embedded system, you have to init all the io things you want to use.
On a pc, the os does all that for you. On an embedded system, the program is in
rom. So you can't do clever things like writing a different address into an
instruction. Folks thought this was cool back in the 8086 assembler days on
pcs. A comp sci grad asked me to help him debug his program once... said it
worked fiine in ram, then he relinked it for rom and it didnt work. I asked him
'You dont have any initialized variables you are trying to modify do you?'.
He says no. When you look at his program, there it is, 1st line in the
subroutine int counter=10; 'Its acting like its not going thru the loop 10 times',
Doh! [Non-text portions of this message have been removed]

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Ravi Haksar wrote:

> I first want to say that your last email was quite helpful. I
> looked at the book you recommended- The C Programming Language by
> K&R- and I wondering if it teaches embedded C. I have looked at
> both embedded C books and regular C books and I noticed that the
> header files are different. Is there a big difference? Or can C be
> adapted for embedded systems?

As I said, the C language is pretty much standardized. Even
"embedded" compilers implement ANSI C.

However, there are definite differences between a hosted
environment and a freestanding environment. Even the startup
code may be very minimal. I have a relatively usable
freestanding environment for the MC68HC11 which I did,
based on Small C version 2.something for the 80x86.
It is fairly complete as freestanding environments go.
But the language does not support long int, float, double,
struct, union, and enum. It does generate fairly reasonable
code, though. It does have, for example, <stdio.h> which
supports printf(), sprintf(), fprintf(), vsprintf(), vfprintf(),
for stdin, stdout, stderr, rawin, and rawout, all mapped to the SCI.
Also supported are fgets(), gets(), fgetc(), getc(), putc(),
fputc(), putchar(), also a complete implementation of
<string.h> etc. The string functions are all written in assembler
and are pretty much optimal. For example, memset(.,.,.) uses
word stores rather than bytes when it can.

> Also, is there any special code for motor controllers? Is it
> controlled just by switching I/O ports on and off? I have a motor
> controller chip and I need to know how to control it so I can get my
> robot to move. I also have a problem in trying to get C compilers.
> Most of them I see are very expensive and I want to get a free one.
> Another site recomended a free compiler, but when I try to use it,
> It comes up with a lot of errors that I don't know to fix.

All projects have "special code". The means used to control a motor
depends on the hardware used to connect it. If you have a special
interface chip, then you need to decide how you are going to connect
the I/F chip (via an I/O port(s) or via memory mapping) and then
you have to follow the programming protocol for that chip.

Until you decide (1) what chip you are connecting and (2) how you
are connecting it you can't decide how the code is going to look.

> Lastly, I looked at Freescale reference manuals for it and some of
> the
commands are in assembly. Some tables look weird, but i have been able
to reconize things like the memory adresses. I'll keep looking through
it and I'm pretty sure I will be able to learn the architecture. I just
hope that I will be able to find the adresses for the different modes
and ports.

Since the architecture manuals are dedicated to that particular
processor, they are *not* going to describe the C language.
Nor are they going to describe Pascal, BASIC, FORTRAN or MUMPS.
They are going to describe the architecture of the machine, which
includes its *machine* language, along with some mnemonics
(called "assembly language").

I suggest that you take the example I gave you (an I/F for the
A/D converter) and read the section on the A/D and compare
what I wrote to what the manual says. Perhaps then you can
get some idea of how this works generally.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Mike McCarty wrote:
> Ravi Haksar wrote: >>I first want to say that your last email was quite helpful. I
>>looked at the book you recommended- The C Programming Language by
>>K&R- and I wondering if it teaches embedded C. I have looked at
>>both embedded C books and regular C books and I noticed that the
>>header files are different. Is there a big difference? Or can C be
>>adapted for embedded systems? > As I said, the C language is pretty much standardized. Even
> "embedded" compilers implement ANSI C.
>
> However, there are definite differences between a hosted
> environment and a freestanding environment. Even the startup
> code may be very minimal. I have a relatively usable
> freestanding environment for the MC68HC11 which I did,
> based on Small C version 2.something for the 80x86.
> It is fairly complete as freestanding environments go.
> But the language does not support long int, float, double,
> struct, union, and enum. It does generate fairly reasonable
> code, though. It does have, for example, <stdio.h> which
> supports printf(), sprintf(), fprintf(), vsprintf(), vfprintf(),
> for stdin, stdout, stderr, rawin, and rawout, all mapped to the SCI.
> Also supported are fgets(), gets(), fgetc(), getc(), putc(),
> fputc(), putchar(), also a complete implementation of
> <string.h> etc. The string functions are all written in assembler
> and are pretty much optimal. For example, memset(.,.,.) uses
> word stores rather than bytes when it can. >>Also, is there any special code for motor controllers? Is it
>>controlled just by switching I/O ports on and off? I have a motor
>>controller chip and I need to know how to control it so I can get my
>>robot to move. I also have a problem in trying to get C compilers.
>>Most of them I see are very expensive and I want to get a free one.
>>Another site recomended a free compiler, but when I try to use it,
>>It comes up with a lot of errors that I don't know to fix. > All projects have "special code". The means used to control a motor
> depends on the hardware used to connect it. If you have a special
> interface chip, then you need to decide how you are going to connect
> the I/F chip (via an I/O port(s) or via memory mapping) and then
> you have to follow the programming protocol for that chip.
>
> Until you decide (1) what chip you are connecting and (2) how you
> are connecting it you can't decide how the code is going to look. >>Lastly, I looked at Freescale reference manuals for it and some of
>>the
>
> commands are in assembly. Some tables look weird, but i have been able
> to reconize things like the memory adresses. I'll keep looking through
> it and I'm pretty sure I will be able to learn the architecture. I just
> hope that I will be able to find the adresses for the different modes
> and ports.
>
> Since the architecture manuals are dedicated to that particular
> processor, they are *not* going to describe the C language.
> Nor are they going to describe Pascal, BASIC, FORTRAN or MUMPS.
> They are going to describe the architecture of the machine, which
> includes its *machine* language, along with some mnemonics
> (called "assembly language").
>
> I suggest that you take the example I gave you (an I/F for the
> A/D converter) and read the section on the A/D and compare
> what I wrote to what the manual says. Perhaps then you can
> get some idea of how this works generally. Mike,

Using complex library function such a printf(), sprintf(), fprintf(),
vsprintf(), vfprintf() when writing for me is a sure way to get to do the
job/assignment over. They all use more overhead than they are worth and
can be be replaced in a great deal less space with similar functions that
run faster. In the case of printf() print_int(), print_char(), print_str()
and print_long() take only a few lines.

All I really have to have from a compiler is a getc and putc. I generally
to in and modify the code that implements them to drop line feeds if they
next to carriage returns and convert them to carriage returns when there
not paired with one. pets() and puts() are a nice bonus and I copy
puts(char *s, char c) to make a putstr() that lets me have putstr() that
doest always tag on a carriage return but what I want it to tag on the end
of a string.

Gordon Couger
Biosystems& Ag Engineering (retired)
Oklahoma State University
www.couger.com/gcouger

/* Global variables*/
char hex_str[] = {"0123456789ABCDEF"};

/* code in library somewhere*/

void print_int(unsigned int n)
/* I have implemented it this ways as well*/
/*void print_int(unsigned int n, int base, int length, char c)*/
/* this version work or any base up to 0xff*/
/*let you format the length and chose the trailing character*/
/* space, CR, comma, nothing or what ever*/
{
char s[10];
int count;

count = 0;
if(n==0)
{
s[0]='0';

count = 1;
}
while(n>0)
{
s[count++]=hex_str[n%10];
n = n/10;
}
count--;
while(count>=0) /*unroll the output in order*/
putch(s[count--]);
} void print_hex(unsigned char h)
{
char s[4];
s[1]=hex_str[h % 16]; /* only set up for 8 bit Char */
h = h / 16; /*in this case */
s[0]=hex_str[h % 16];
s[2] = 0;
putch(s[0]);
putch(s[1]);
}

______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.


(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Gordon Couger wrote:
>
> Mike McCarty wrote:
>
>>Ravi Haksar wrote:
>>
>>
>>
>>>I first want to say that your last email was quite helpful. I
>>>looked at the book you recommended- The C Programming Language by
>>>K&R- and I wondering if it teaches embedded C. I have looked at
>>>both embedded C books and regular C books and I noticed that the
>>>header files are different. Is there a big difference? Or can C be
>>>adapted for embedded systems?
>>
>>
>>As I said, the C language is pretty much standardized. Even
>>"embedded" compilers implement ANSI C.
>>
>>However, there are definite differences between a hosted
>>environment and a freestanding environment. Even the startup
>>code may be very minimal. I have a relatively usable
>>freestanding environment for the MC68HC11 which I did,
>>based on Small C version 2.something for the 80x86.
>>It is fairly complete as freestanding environments go.
>>But the language does not support long int, float, double,
>>struct, union, and enum. It does generate fairly reasonable
>>code, though. It does have, for example, <stdio.h> which
>>supports printf(), sprintf(), fprintf(), vsprintf(), vfprintf(),
>>for stdin, stdout, stderr, rawin, and rawout, all mapped to the SCI.
>>Also supported are fgets(), gets(), fgetc(), getc(), putc(),
>>fputc(), putchar(), also a complete implementation of
>><string.h> etc. The string functions are all written in assembler
>>and are pretty much optimal. For example, memset(.,.,.) uses
>>word stores rather than bytes when it can.
>>
>>
>>
>>>Also, is there any special code for motor controllers? Is it
>>>controlled just by switching I/O ports on and off? I have a motor
>>>controller chip and I need to know how to control it so I can get my
>>>robot to move. I also have a problem in trying to get C compilers.
>>>Most of them I see are very expensive and I want to get a free one.
>>>Another site recomended a free compiler, but when I try to use it,
>>>It comes up with a lot of errors that I don't know to fix.
>>
>>
>>All projects have "special code". The means used to control a motor
>>depends on the hardware used to connect it. If you have a special
>>interface chip, then you need to decide how you are going to connect
>>the I/F chip (via an I/O port(s) or via memory mapping) and then
>>you have to follow the programming protocol for that chip.
>>
>>Until you decide (1) what chip you are connecting and (2) how you
>>are connecting it you can't decide how the code is going to look.
>>
>>
>>
>>>Lastly, I looked at Freescale reference manuals for it and some of
>>>the
>>
>>commands are in assembly. Some tables look weird, but i have been able
>>to reconize things like the memory adresses. I'll keep looking through
>>it and I'm pretty sure I will be able to learn the architecture. I just
>>hope that I will be able to find the adresses for the different modes
>>and ports.
>>
>>Since the architecture manuals are dedicated to that particular
>>processor, they are *not* going to describe the C language.
>>Nor are they going to describe Pascal, BASIC, FORTRAN or MUMPS.
>>They are going to describe the architecture of the machine, which
>>includes its *machine* language, along with some mnemonics
>>(called "assembly language").
>>
>>I suggest that you take the example I gave you (an I/F for the
>>A/D converter) and read the section on the A/D and compare
>>what I wrote to what the manual says. Perhaps then you can
>>get some idea of how this works generally.
> > Mike,
>
> Using complex library function such a printf(), sprintf(), fprintf(),
> vsprintf(), vfprintf() when writing for me is a sure way to get to do the
> job/assignment over. They all use more overhead than they are worth and

[snip]

My point was that various freestanding implementations span a wide
range of just what is provided. I did what I did to meet *my*
requirements, and not yours. I also did a very complete floating
point implementation of the standard and some not-so-standard
elementary transcendental functions, some of which used algorithms
I developed myself. But I didn't mention them, because they
weren't germaine. As I say, the point is to show that freestanding
implementations span a wide range of what is provided.

Most of my projects are done in assembler, anyway.

I guess you didn't bother to read the previous message which showed
the actual type of code I was recommending him to consider.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )

Gordon Couger wrote:
>
> Mike McCarty wrote:
>
>>Ravi Haksar wrote:
>>

[that he wanted to learn how to create a robot using C] > Mike, I apologize for the sharpness of my other post.

> Using complex library function such a printf(), sprintf(), fprintf(),
> vsprintf(), vfprintf() when writing for me is a sure way to get to do the
> job/assignment over. They all use more overhead than they are worth and
> can be be replaced in a great deal less space with similar functions that
> run faster. In the case of printf() print_int(), print_char(), print_str()
> and print_long() take only a few lines.

Different tools are appropriate for different uses. What is appropriate
for a library writer to put into a library is different from what is
appropriate to put into a production device.

We have here a fellow who (1) does not know C (2) is unfamiliar with
the 6811 architecture (3) does not know how to control motor speed
and (4) wants to make a robot. I suggested that he disentangle (1)
(2) and (3). My plan (if one may even use that word) is
(1) help him learn C (2) help him learn to use an implementation for
the 6811 by porting programs unrelated to robotics to the
implementation, then (3) start writing code to try to control
his external devices.

I was not by any means suggesting that printf() would be appropriate
in a robot with lmited resources intended for industrial use, i.e.
quantity production.

For some quick debugging code, or even permanently in a hobby robot
with 32K of RAM to hold the code, and a program which without printf()
is only 2K anyway, the use of printf() is certainly acceptable.
Especially when the only exposure one has to C is helloworld.c.

> All I really have to have from a compiler is a getc and putc. I generally

Usually, I want two versions of them. One which does newline translation
and one which does not, IOW rawin() and rawout() as well as getc() and
putc().

> to in and modify the code that implements them to drop line feeds if they
> next to carriage returns and convert them to carriage returns when there
> not paired with one. pets() and puts() are a nice bonus and I copy
> puts(char *s, char c) to make a putstr() that lets me have putstr() that
> doest always tag on a carriage return but what I want it to tag on the end
> of a string.

Yes, I almost always wind up with PutString somewhere in my code.

> Gordon Couger
> Biosystems& Ag Engineering (retired)
> Oklahoma State University
> www.couger.com/gcouger
>
> /* Global variables*/
> char hex_str[] = {"0123456789ABCDEF"};
>
> /* code in library somewhere*/
>
> void print_int(unsigned int n)
> /* I have implemented it this ways as well*/
> /*void print_int(unsigned int n, int base, int length, char c)*/
> /* this version work or any base up to 0xff*/
> /*let you format the length and chose the trailing character*/
> /* space, CR, comma, nothing or what ever*/

My versions of sprintf(), vsprintf(), fprintf(), vfprintf(),
and printf() all use a routine very like this, which
accept the buffer, its size, the value, the base, and
whether the number is to be considered to be unsigned.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!





(You need to be a member of m68hc11 -- send a blank email to m68hc11-subscribe@yahoogroups.com )