Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | Re: Using C to program the 8051 family

There are 61 messages in this thread.

You are currently looking at messages 40 to 50.

Re: Using C to program the 8051 family - Mike Harding - 23:00 06-01-04

On Tue, 6 Jan 2004 21:12:10 -0600, Casey <c...@cox.net>
wrote:

>Albert Lee Mitchell said...
>
>> 	Third, C is essentially impossible to debug without a In Circuit
>> Emulator.  
>
>I guess I've been dreaming for the last 10 years then.  Shipped at 
>least fifteen products and never used an ICE.

Almost likewise. 

Mike Harding




Re: Using C to program the 8051 family - CBFalconer - 23:57 06-01-04

Morris Dovey wrote:
> 
... snip ...
> 
> In 1975 nearly all embedded programming was being done in
> assembly language, with FORTRAN and PL/M to follow. There were
> some fairly compact BASIC interpreters; but their performance was
> generally 'poor' to 'intolerable' for time-critical applications.
> 
> I used C on (first) I8080 and (later) Z80 CPUs and had no serious
> problems - though I was constrained to integer math. Even the
> primitive 8080 could be programmed to produce 32-bit (or larger)
> results when needed.

The 8080 was no more primitive than the Z80, and I found I could
do everything (in assembly) in very little more running time than
in the Z80 code set.  What Z80 opcodes did was primarily to allow
smaller object code.

At any rate, by about 1978 I had moved most of my embedded
machinery to Pascal, using my own compiler, validated against the
test suite for the ISO/ANSI standards.

One notable thing about Pascal is that one can provide many
extensions, in the form of standard procedures, without violating
the standard.  This is because such extensions exist in the
conceptual outer outer block, and therefore never create name
clashes.  Thus there is no need for the C style reserved names, or
C++ namespaces.  In addition I have yet to find an i/o or
communication device that I could not map into Pascal files.

I used such extensions to provide such features as C's unsigned
ints (no overflows), or to allow splitting ints into bytes (or the
reverse) without worrying about endianess, etc.

-- 
Chuck F (c...@yahoo.com) (c...@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>;  USE worldnet address!



Re: Using C to program the 8051 family. C for small processors - CBFalconer - 23:57 06-01-04

Bryan Hackney wrote:
> 
... snip ...
> 
> I'm unaware of any public domain C compilers. Do you have an example?

Small C.  To all practical purposes gcc and lcc also, since you
can do what you like with them, apart from seize them for your
exclusive use.

-- 
Chuck F (c...@yahoo.com) (c...@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>;  USE worldnet address!



Re: Using C to program the 8051 family. C for small processors - Bryan Hackney - 00:12 07-01-04


CBFalconer wrote:
> Bryan Hackney wrote:
> 
> ... snip ...
> 
>>I'm unaware of any public domain C compilers. Do you have an example?
> 
> 
> Small C.  To all practical purposes gcc and lcc also, since you
> can do what you like with them, apart from seize them for your
> exclusive use.
> 

Psst! I have a secret. That's the idea.


Re: Using C to program the 8051 family. C for small processors - David Brown - 02:55 07-01-04

"Bryan Hackney" <b...@bhconsult.com> wrote in message
news:EeKKb.6910$4...@newssvr23.news.prodigy.com...
>
>
> Walter Banks wrote:
> >
> > Dave Hansen wrote:
> >
> >>I'm not sure what you mean by "public domain C compilers."
> >
> >
> > Public domain in the sense that they are widely available (some
> > times with usage restrictions) to port C to new target platforms.
> > Some examples are the portable C compiler and GCC which have
> > been used for this. All of the compilers of this type that I
> > am familiar with were not originally intended for non hosted
> > or limited resource targets.
> >
> [...]
>
> I've never heard of the portable C compiler, but GCC is definitely
> not PD. SDCC, which is intended for micros, is perhaps not ready
> for prime time, but is definitely not PD.
>
> I'm aware of nothing in the computer realm worth 2 bits that is
> PD. Never confuse a free license with PD.
>

Wasn't much of the old unix base declared to be effectively public domain in
the BSD-SCO case many years ago?

But you are right about gcc - there is a large difference between public
domain code (where the author / copyright owner gives everyone free use to
do what they want with the code, apply any licence they want, and make any
copyright notice changes they want) and open source code, where the
copyright is very carefully maintained and specific licences are applied for
specific purposes.  The uncaring end-user might not notice the difference
(after all, in both cases the program is probably free in monetary terms),
but it makes a huge difference to developers and distributers, and thereby
indirectly to all users.




Re: Using C to program the 8051 family - CBFalconer - 02:59 07-01-04

Mike Harding wrote:
> Casey <c...@cox.net> wrote:
> > Albert Lee Mitchell said...
> >
> >> Third, C is essentially impossible to debug without a
> >> In Circuit Emulator.
> >
> > I guess I've been dreaming for the last 10 years then. 
> > Shipped at least fifteen products and never used an ICE.
> 
> Almost likewise.

I can push that time span to 30+ years.  I will concede that once
or twice I have wished for one.

-- 
Chuck F (c...@yahoo.com) (c...@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>;  USE worldnet address!



Re: Using C to program the 8051 family - Paul Burke - 03:43 07-01-04

Graeme Faelban wrote:
> 
> Keil C51 has a number of 8051 specific extensions, which will require 
> rework when migrating to a different processor.
> 

As will any C compiler or any other programming language (including 
assembler). I recently migrated a (reasonably substantial) project from 
8051 to MSP430. It took me less than a day. That included converting all 
header references (they are seldom the same), thinking out and 
redefining the IO allocations, removing references to smart pointers, 
etc, etc. that were no longer required due to the different 
architecture, and running and testing the result on the target. I dare 
say it would have taken rather longer in assembler.

Paul Burke


Re: Using C to program the 8051 family - jim granville - 05:19 07-01-04

> Grant Edwards wrote:
> 
>> On 2004-01-06, Morris Dovey <m...@iedu.com> wrote:
>>
>>> I've never needed to produce code for an 8051 (nearly all of my more 
>>> recent work has been on 16- and 32-bit SOCs) but I'm amazed to hear 
>>> that the 8051 has less capability that Intel's old I8080 or Zilog's Z80!
>>
>>
>> Why?  The 8051 (and it's predecessor the 8048) was aimed at
>> much smaller, simpler applications than the 8080/Z80 family.
>>
>> IIRC, the 8048/8051 were built for Ford.  They were intended
>> for very small, simple automotive control applications with a
>> few KB of code and maybe 50-100 bytes of RAM.  The 8080/Z80 was
>> a much more "powerful" general-pupose CPU with a stack pointer,
>> 16-bit operations, and everything.

The 8048 was released first, and is a simpler (subset) uC than the 8051
which followed as process improved.
The 8051 was well optimised for embedded control, and added BOOLEAN
processor opcodes, and interrupt priority, as well as more register
banks, and efficent direct memory opcodes.
Those fundamentals have not changed

The Z80 was a microprocessor (No RAM/ROM), and was targeting external 
memory apps. First systems needed MANY chips to function
IIRC Hitachi were the first to do a microcontroller version of the Z80,
and Zilog has very recently (in time line terms) released the FLASH
eZ80

-jg


Re: Using C to program the 8051 family - Casey - 09:18 07-01-04

CBFalconer said...
> Mike Harding wrote:
> > Casey <c...@cox.net> wrote:
> > > Albert Lee Mitchell said...
> > >
> > >> Third, C is essentially impossible to debug without a
> > >> In Circuit Emulator.
> > >
> > > I guess I've been dreaming for the last 10 years then. 
> > > Shipped at least fifteen products and never used an ICE.
> > 
> > Almost likewise.
> 
> I can push that time span to 30+ years.  I will concede that once
> or twice I have wished for one.

I'll concede that point as well.  There were a few times.


Casey

Public Domain and Open-Source (was: Using C to program the 8051 family. C for small processors) - CBFalconer - 09:36 07-01-04

David Brown wrote:
> 
... snip ...
> 
> But you are right about gcc - there is a large difference between
> public domain code (where the author / copyright owner gives
> everyone free use to do what they want with the code, apply any
> licence they want, and make any copyright notice changes they
> want) and open source code, where the copyright is very carefully
> maintained and specific licences are applied for specific
> purposes.  The uncaring end-user might not notice the difference
> (after all, in both cases the program is probably free in
> monetary terms), but it makes a huge difference to developers and
> distributers, and thereby indirectly to all users.

I am assuming GNU GPL here, but there are other licenses.

It makes no difference to distributors, because in general the
licenses allow charges for services.  The only thing it prevents
is third parties seizing the code and applying their own
copyrights.

As an example, I could create a new machine, either in hardware or
as a simulator, copyright/patent/whatever that, and adapt gcc to
generate code for it.  I get the useful software to promulgate my
ideas for essentially nothing, or at least a minimum of my
effort.  I retain complete ownership of the machine, the right to
charge whatever I wish for it, but NOT the right to hide or
restrict use of my gcc mods.

Of course, should you wish, you are welcome to create a compiler
for your new machine from scratch, and then charge what you wish,
and hide all the details.  I suspect it will be a few years before
it is as accurate or flexible as gcc.  Meanwhile you will have to
keep your whiz-bang off the market, and the business may well go
elsewhere.

-- 
Chuck F (c...@yahoo.com) (c...@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>;  USE worldnet address!



previous | 1 | 2 | 3 | 4 | 5 | 6 | 7 | next