Maker Pro
Maker Pro

Microcontroller ... which one ??

K

Ken Smith

Jan 1, 1970
0
You are missing my point. If I write a piece of code, I want to be
able to use it on another platform (unless it deals with specific
hardware ofcourse).

No, I fully understand your point. But you said that the code can't be
"reused". I was arguing against that specific point in what you wrote.

I was not suggesesting that the fact that you wanted to run the same code
on different machines is a sign of a sick mind. Nor was I questioning the
manhood of anyone who doesn't code in assembly. Others may argue such
points as whether type checking is leading to laziness and stupidity in
programmers or whether software without line numbers can really be called
software. I made no such statements in my posting.
 
N

Nico Coesel

Jan 1, 1970
0
You can reuse the code. If you write good code for an 8051 you can use it
on any other 8051. I have a set of routines that have been put into 6
very different products. The standard RS232, 32 bit math, a command line
hardware debugger and a huge number of utility routines have been used in
each.

You are missing my point. If I write a piece of code, I want to be
able to use it on another platform (unless it deals with specific
hardware ofcourse).
 
N

Nico Coesel

Jan 1, 1970
0
"Nico Coesel" <[email protected]> schreef in bericht

[snip]
The bottom line is, if you want to use C as a truly portable (and
therefore efficient) language, stick with the micro's that have a
single memory address space (a separate I/O space is not a problem).

My bottom line is that I don't port very often ;)


Besides portable code in "C" is largely a myth. Any program that has been
ported much will have a lot of "#if" logic in the source to make the
different source code you need in different cases. Try porting from a PC
to the Analog Devices Shark and back and you will see.

The Shark has a harvard architecture (separate code & data memories)
if I recall correct. The Analog Devices Blackfin however has a single
addressing range and that makes porting from the PC and back a whole
lot easier.
The C language contains many constructs that hard hardware dependant.
This is a result of the history of the language. The "int" type varies in
the number of bits. The "float" types vary in the range and number of
digits. Unfortunately the language does not let you specify the range of
integers and the details of floats etc.

That's why C has char, short and long types (8, 16 and 32 bit)
independant of the architecture. At my daytime job we put a command
line interpreter in most of the products to aid debugging. It's the
same source for an HC11, H8/300 H8/3000S, a Windows service, a Windows
DLL or a Linux deamon.
 
K

Ken Smith

Jan 1, 1970
0
[email protected] (Ken Smith) wrote:
[...]
The C language contains many constructs that hard hardware dependant.
This is a result of the history of the language. The "int" type varies in
the number of bits. The "float" types vary in the range and number of
digits. Unfortunately the language does not let you specify the range of
integers and the details of floats etc.

That's why C has char, short and long types (8, 16 and 32 bit)
independant of the architecture.

Actually:

"char" means character it is not always 8 bits on some machines that do
not have byte addressing it can be quite a few more than 8 bits. In one
case a "char" was in fact a 32 bit integer because that was the smallest
grain that can be addressed.

"short" does not mean 16 bits and "long" does not mean 32. On most byte
based processors this has become the defacto standard but if the processor
is not byte based, the length is the natural lenth of the numbers in that
machine in an ATT DSP chip a long integer was 24 bits for example.
 
S

Spehro Pefhany

Jan 1, 1970
0
It's hard to find out anything about the state of C these days - the
denizens of comp.lang.c are some kind of high priesthood who have pulled
up the drawbridge.

Seems to me that most on-topic questions in c.l.c. can be answered by
referring to ISO/IEC 9899:1999.


Best regards,
Spehro Pefhany
 
V

~~ VerilogMan ~~

Jan 1, 1970
0
Clarence said:
I general purpose computers there are only two basic Architectures, "Von
Newman," and "Harvard." Although there are many minor variations, there
are
only two. i.e., number os registers, organizarion of the registers,
Interrupt
schemes, I/O features, etc do not change the architecture!

Google for the architecture name to learn more.

But I learnt that X86 was different from Motorola ?
 
C

Clarence

Jan 1, 1970
0
~~ VerilogMan ~~ said:
But I learnt that X86 was different from Motorola ?
Primarily the extensions to memory addressing, and IO!
They are both Von Newman!
 
V

~~ VerilogMan ~~

Jan 1, 1970
0
Alex Gibson said:
I think you need to start with a more simple project
then build on it once you know more.

something like sending text to a text mode lcd via rs232
do that as a couple of part project


Well the problem is that I already proposed this project... So it's a bit
too late for me to go back ! :(


It depends on your background, what you are trying to do ?

how you are going to get started either buying or making your own board ?

what electronics knowledge ?


See I just thought that all you neede was the controller and that you had to
attach it to the connections of the LCD module ...
But apparently I need a board and everything with different composants !!
On one side it is good ... I feel like I am learning *a lot* each time I
read you guys. But on the other hand I realize the harder it is ! :)

http://www.controlanything.com/manuals/GraphicDisplayChips.pdf on this
website this guy has done it for graphic lcds but there is not the
touchscreen part
So I pretty much discovered that you needed more than just a microcontroller
! I felt like buying what this guy was sellinh and try to adapt it for what
I wanted to do ... ButI don't think it is possible

Which asm ?
Intel X86

Most libraries you need come with the compilers



DIP - dual inline package, mounts thruough holes in the pcb
so is called through hole

surface mount means it is mounted on the suface of the pcb

pcb - printed circuit board

Depends what you want, either buy a premade board with the microcontroller
of your choice or buy the bits and put your own together.


I think I will go with the first choice man ! :)
Asm and c. C doesn't suit all microcontrollers though.
Some weren't designed to be programmed in c.

Up to you to use or pick the language you want to use.

Even if you choose to use c you really still need to know
some asm for the chip you are using.

I do know asm... but I want to use it as less as i can ...

It can manage what you want but you would need to
buy a premade board if you don't have much electronics experiance.
Surface mount package

www.bdmicro.com make some nice atmega128 boards
can see others at avrfreaks
Avr's of which the atmega128 is one, have free tools
ide for windows , + free c compiler (gcc port) even ada compiler(gcc port)

free avr forth,
then quite a few commerical compilers

www.avrfreaks.com compilers etc

http://www.atmel.com/products/avr/ to get the datasheets and app notes
for the atmega128

Hey, thanks these websites are amazing.... they even have serial
interface.... !
Definitvely my choice is to go with a board now I think. If I have to just
do the programming part and not the interfacing, that would be really a big
lift from my shoulders.
I went on the ATMEGA128 boards page... And these ones looked interesting:

Flexit
MB-128-XXX
Mega128-Dev-MMC
MEGABRAIN128
PROBOmega128
STK 501
Mega128-Net
adn all the BD MICRO

Which one do you think is the best ? With my amateur eyes the BDMICRO looks
nice and same with the STK501...
which one would you ? If you had to make a choice right now ? (that's what I
have to do right now :) !
I guess I would want the one with the most support. and price/quality wise ?
I think this one http://www.bdmicro.com/mavric-iib/ is quite good !

Again, thanks for all your help, all of your help is really making me
progress quickly!
 
D

Dave VanHorn

Jan 1, 1970
0
You should look at what each offers.

I have a Mavric, and it's a very well done board.
 
K

keith

Jan 1, 1970
0
For simple programs it may be possible to do but you'd better watch it if
you use strings. In some cases it is best to just store one character per
integer.

Are you man enough to take it to C.A? Trust me, you'll get chewed up and
spit out by people who do just this for a living.

Not I, I'm only a reporter (and can't stand 'C', BTW). I do either
assembler or highly structured programming (VHDL is more my style ;-).
In C you have no choice. All of the types are hardward dependant. The
simple types (int, float, and pointers etc) are.

Nonsense. Take it to C.A. and report back with your tail burned off.
All more complex types such as structures and unions are composed of the
simple types. They also can't be passed to subroutines.

Of course not, pointers to structures are. But the basic types are
defined in the language specification too. Because *you* choose to
bastardize them, you shoot yourself in the foot. 'C' is really good at
letting the incompetent do that (which is why I don't do 'C').
All complex
types are passed as a pointer to the value rather than the value.
Pointers are hardware dependant. In some processors, you can't type
convert between pointers. This makes any routine that uses the "void *"
type of pointer non-portible.

Tell it to the real programmers over on comp.arch, if you dare. I'll lurk
and watch you burn too. I've seen these flame-fests before. The
incompetents always run away with flaming tails.
 
V

~~ VerilogMan ~~

Jan 1, 1970
0
Clarence said:
Primarily the extensions to memory addressing, and IO!
They are both Von Newman!


Oh k :) i read some stuff I think i got it :)
 
V

~~ VerilogMan ~~

Jan 1, 1970
0
Dave VanHorn said:
You should look at what each offers.

I have a Mavric, and it's a very well done board.


Heh , yea I think I am gonna go with one of them :)
thx
 
K

Ken Smith

Jan 1, 1970
0
I've added the comp.arch news group to the header on this because the
argument has moved into an area that the other poster claims I will get
roarsted in. If you disagree with me, fire away. I think you will agree
with my statements on the subject of C.

I've editted things down a bit to make the basic points easier to pick up
on part way into the argument. You should be able to backtrack the thread
in your news reader. If this ends up purely a comp.arch issue I'll delete
the electronics news group.

The discussion is about the portability of C. We are not talking about
just general purpose computers. DSPs and micro-controllers are at issue.

Are you man enough to take it to C.A? Trust me, you'll get chewed up and
spit out by people who do just this for a living.

Consider it taken there if I did the headers right.
Of course not, pointers to structures are. But the basic types are
defined in the language specification too. Because *you* choose to
bastardize them, you shoot yourself in the foot. 'C' is really good at
letting the incompetent do that (which is why I don't do 'C').

"the basic" types means the same as the "simple types". Or are you
suggesting that some arrays or structures are now part of the language
definition?

I maintain that "complex types" end up being machine dependant because
they are defined from the "simple types". I have also said that "long
int", "short int", "int", "float" and all pointers are machine dependant
because thir meaning changes for non-byte oriented processors. Keith (the
other poster) asserted that "short int" means 16 bits and that "long int"
means 32 bits.
Tell it to the real programmers over on comp.arch, if you dare. I'll lurk
and watch you burn too. I've seen these flame-fests before. The
incompetents always run away with flaming tails.

I assume you mean "comp.arch.c"
 
K

keith

Jan 1, 1970
0
Since it's being cross-posted to a new group, I'll trim closely...

The discussion is about the portability of C. We are not talking about
just general purpose computers. DSPs and micro-controllers are at issue.

Also ignoring Harvard architectures (like the 8051) and special function
registers (which are obviously hardware dependant).
keith said:
[...]
I think if you make that statement over on comp.arch you'll get a lot
of argument. AIUI (I'm just a hardware type, can't spell 'C') it is
possible to write portable 'C', but it's not trivial.

For simple programs it may be possible to do but you'd better watch it
if you use strings. In some cases it is best to just store one
character per integer.

Are you man enough to take it to C.A? Trust me, you'll get chewed up
and spit out by people who do just this for a living.

Consider it taken there if I did the headers right.

No, not C.A.C. It might work, but I meant C.A. I've seen exactly this
argument before in C.A. I've never followed C.A., since I'm a hardware
type. A Google NG search might keep from upsetting the natives too. ;-)
"the basic" types means the same as the "simple types". Or are you
suggesting that some arrays or structures are now part of the language
definition?

I'm only reporting what the language experts say. They claim to do
portable C reliably, every time.
I maintain that "complex types" end up being machine dependant because
they are defined from the "simple types". I have also said that "long
int", "short int", "int", "float" and all pointers are machine dependant
because thir meaning changes for non-byte oriented processors. Keith
(the other poster) asserted that "short int" means 16 bits and that
"long int" means 32 bits.

I never explicitly stated anything of the kind. I states simply that
portable C coding was possible without out polluting the code with
massive IFDEFs and such.
I assume you mean "comp.arch.c"

No, I meant "comp.arch", where much of this stuff has been hashed out
ad-nausium. I've never followed comp.arch.c, so I know none of the
regulars.
 
K

Ken Smith

Jan 1, 1970
0
Since it's being cross-posted to a new group, I'll trim closely...



Also ignoring Harvard architectures (like the 8051) and special function
registers (which are obviously hardware dependant).

Ok, I'll include that limitation to the scope of the argument. Things
like the transputer are alos off the table. I think they are too weird to
make a C compiler for. We can limit the discussion to only those machines
for which a reasonable C compiler can be written.
keith said:
On Sat, 27 Nov 2004 22:07:04 +0000, Ken Smith wrote:

[...]
I think if you make that statement over on comp.arch you'll get a lot
of argument. AIUI (I'm just a hardware type, can't spell 'C') it is
possible to write portable 'C', but it's not trivial.

For simple programs it may be possible to do but you'd better watch it
if you use strings. In some cases it is best to just store one
character per integer.

Are you man enough to take it to C.A? Trust me, you'll get chewed up
and spit out by people who do just this for a living.

Consider it taken there if I did the headers right.

No, not C.A.C. It might work, but I meant C.A. I've seen exactly this
argument before in C.A. I've never followed C.A., since I'm a hardware
type. A Google NG search might keep from upsetting the natives too. ;-)

If we don't get a reaction, one us will have to change the groups line. I
did not because it is way too early to expect any reaction.

I'm only reporting what the language experts say. They claim to do
portable C reliably, every time.


But ... but ... are they porting to microcontrollers etc. In the general
purpose computer world things can be quite different. Companies like
Prime and DEC no longer exist so there aren't many non-byte oriented
general purpose computers any more.

I never explicitly stated anything of the kind. I states simply that
portable C coding was possible without out polluting the code with
massive IFDEFs and such.


I thought you did. Maybe I confused you with some other poster. Sorry if
I did.
No, I meant "comp.arch", where much of this stuff has been hashed out
ad-nausium. I've never followed comp.arch.c, so I know none of the
regulars.

Well we will see if this get more hash or just ignored. Fasten your seat
belt, it may be a bumpy ride.
 
N

Nico Coesel

Jan 1, 1970
0
But ... but ... are they porting to microcontrollers etc. In the general
purpose computer world things can be quite different. Companies like
Prime and DEC no longer exist so there aren't many non-byte oriented
general purpose computers any more.

In the last 2 decades microcontroller and DSP manufacturors started to
make their processors to be easy programmable using C. Even DSPs with
all their oddities to make them fast are getting better to program
using C nowadays.
 
K

Ken Smith

Jan 1, 1970
0
Nico Coesel said:
In the last 2 decades microcontroller and DSP manufacturors started to
make their processors to be easy programmable using C. Even DSPs with
all their oddities to make them fast are getting better to program
using C nowadays.

Yes, they are a lot better today. Better was easy to do since they were
generally awful in the past.

DSPs still often have limitation on the smallest grain size and some don't
use IEEE floats to do the actual floating calculations.

If C allowed you to specify the range of values and the minimum bits in
mantissas etc. The processors would have had to change less to make them
easy to program in C.
 
V

~~ VerilogMan ~~

Jan 1, 1970
0
Dave VanHorn said:
You should look at what each offers.

I have a Mavric, and it's a very well done board.

I actually looker for the support part and the STK501 seems to have more
suport ! It has assembler program from ATMEL for example but not the MAVRIC
....
so which one would you go with ??
 
V

~~ VerilogMan ~~

Jan 1, 1970
0
Dave VanHorn said:
You should look at what each offers.

I have a Mavric, and it's a very well done board.

I actually looker for the support part and the STK501 seems to have more
suport ! It has assembler program from ATMEL for example but not the MAVRIC
....
so which one would you go with ??
 
D

Dave VanHorn

Jan 1, 1970
0
The STK boards are general purpose development tools.
The Mavric is a designed for just the one processor.

Depends on what you want.

Both will work with AVR Studio, but with the Mavric, you'll need a
programmer, like an AVRISP.

If you want a little board that you can embed in your project, then the
mavric is a better choice.
If you want to work with many different AVRs, then the STK is better.
 
Top