Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24 - Page 6

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
says...
Quoted text here. Click to load it

I don't follow your logic here Ian.  If you can have strings in ROM and
RAM and allow copy from either ROM or RAM how are you going to do it
without either a qualified pointer that distinguishes between the two
possible sources or a separate routine for each case (or the moral
equivalent thereof)regardless of the language?

Robert

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

I agree and therefore standard library functions will not suffice. Hence my
first assertion. As the specifics are micro specific I contend they are
best written in assembler; hence my second assertion.

Ian


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
says...
Quoted text here. Click to load it

OK, I follow you now.  Thanks

Robert

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

I'm not really suggesting a dynamic "RTTI like" solution,
just a more complete static type model that recognizes
different memory spaces.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

Actually, I would say it's more of a language issue.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

Just to muddy the water a bit more, I'm currently doing some work
for a processor having two disjoint RAM spaces.  I'm certainly
glad I don't have to work out the details of making the C compiler
for it generate the correct code.

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

No they don't. Compilers for Harvard architecture understand Harvard
architecture very well.

What do you mean by "most traditional compilers/languages"?  For
embedded use 99% of C programming uses extensions to C and most
compilers are specialised.




--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

No they don't what?

Quoted text here. Click to load it

I am referring to pure harvard architecture, (e.g. AVR)
where ROM and RAM address spaces are accessed with different
instructions. IOW pointers to to different address spaces
are possible.

Quoted text here. Click to load it

For embedded use, C/C++.

Quoted text here. Click to load it

By definition, "extensions" are not standard.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

only understand a single contiguous address space

Quoted text here. Click to load it

There are quite a few Harvard architecture MCU about. They all have
compilers that handle it with no problems.

Quoted text here. Click to load it

what do you mean by "traditional compilers/languages"  There are many
Harvard compilers about. C and C++ They are separate languages have know
knowledge of HW architectures.

Quoted text here. Click to load it

There are no compilers you would use for embedded work that don't have
extensions to ISO C. Actually there are no Standard C compilers anyway.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

In what way?

Quoted text here. Click to load it

It is almost impossible to write sensible programs on many MCU unless
you do use them.

Quoted text here. Click to load it

Again this is often not possible.

Quoted text here. Click to load it

Very few are. There are good reasons for this.


Quoted text here. Click to load it

Can you name any?

Quoted text here. Click to load it

However the are very open and undefined in some areas.

Quoted text here. Click to load it

It has been done.

Quoted text here. Click to load it

However there are no C99 conforming compilers.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

E.g. oth language standards assume a single address space.

Quoted text here. Click to load it

While this may be true for certain MCU's, it's certainly not
true for all of them. For example the H8 series.

Quoted text here. Click to load it

Certainly, this can be the case for *some* MCUs, and
*any* time the feature set stretches the available resources,
all bets are off.

Quoted text here. Click to load it
Certainly there are exceptions to every rule, and resource
constrained systems are frequently full of exceptions, but
aside from that, surely portability is a consideration.

Quoted text here. Click to load it

Certainly GCC is attempting to be standards conforming.
Are there exceptions/non-conformances? Sure. What is
your point?

Quoted text here. Click to load it

Yes, there are usages that are specified as undefined.
We usually avoid those constructs.

Quoted text here. Click to load it

I refer to the language standards, not to implementation
specific extensions.

Quoted text here. Click to load it

Again, 100% tested conformance? Sure there are bugs and
implementation limitations, but certainly there are compilers
that are moving towards conformance with standards. Probably
not for all targets. Clearly, MCUs with architectures that do
not fit cleanly into the C/C++ language assumptions are supported
by fewer if any vendors.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

really?

Quoted text here. Click to load it

I think you will find it is true for most there are exceptions which are
in the minority.

Quoted text here. Click to load it

MOST MCU's


???

Quoted text here. Click to load it

And you appear to be it.

Quoted text here. Click to load it

As this is comp.arch.embedded most here will be constrained systems.


Quoted text here. Click to load it

That there are no "Standard C" compilers. GCC has it's own standard.

Quoted text here. Click to load it

Unspecified and undefined..... there are hundreds of them.

If you are avoiding all those + the language extensions your programs
must be very inefficient.
Quoted text here. Click to load it

So was I.... The embedded extensions TR.

Quoted text here. Click to load it

"moving towards"? Yes and they have a LONG (or even Long long :-) way to
go. AFAIK there are only 3 or 4 which even come close to C99.

Quoted text here. Click to load it

Not for most at the moment.  

Quoted text here. Click to load it

No they are well supported it is just that the C standard has moved well
away from it target constituency.


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

OK. Please explain to me how one *without going outside of
the C/C++ language standard* declare an "unsigned char" for
the AVR that lives in the AVR ROM space and another that
lives in the AVR RAM space?

Quoted text here. Click to load it

Yep.


Certainly at the low end of the spectrum.

Quoted text here. Click to load it
???

Quoted text here. Click to load it

Ouch. That sounds ... personal. As much as I might like
to think so, however, I'm probably not *that* unique ;-)

Quoted text here. Click to load it

Granted, given the original subject of this thread, that
this is often the case in embedded systems with varying
degrees. *Especially* when combined with the cost pressures
of high volume applications (e.g. consumer products).

However, embedded systems programming is much broader than that.
The system that I will soon begin work on has 128M of RAM, and
it ain't a PC :-)

Quoted text here. Click to load it

GCC has extensions ... yes, but they have been emphasizing
standards conformance in recent years.

Quoted text here. Click to load it

Of course, there is a time and place for each facet
of efficiency, as it's needed. Identify and isolate those
instances. Right?

Quoted text here. Click to load it

 From the ISO website:
ISO/IEC TR 18037:2004 deals with the following topics: extensions to
support fixed-point arithmetic, named address spaces, and basic I/O
hardware addressing.

Nice, though I haven't read this. The "named address spaces"
seems like what I am asking for.

Quoted text here. Click to load it

And?

Quoted text here. Click to load it

Yep.


Without reading it, it seems like TR 18037 is fighting
that trend. I worry that the C/C++ languages are moving
from their systems programming roots as well.

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

  unsigned char lives_in_RAM = 'a';
  const unsigned char lives_in_ROM = 'b';

works for all the HI-TECH C compilers I have installed at work, for
Harvard or von Neumann architectures.  As several people have
mentioned (but not in detail), they allocate constant objects to
addresses in ROM that are outside the range of valid addresses in RAM,
so can be distinguished at runtime.

mlp
(Disclosure of Interest: employed by, but not speaking for, HI-TECH;
just pointing out a mechanism that can be and is used.)

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

I agree that the embedded community is less concerned with portability
than other programming environments.  But I would argue that this is a
result of that writing portable code for an embedded environment is
*hard* -- not because the concept of portability has no merit for
embedded projects.

Over the past two years, three out of the four projects I worked on the
code either had to be rewritten due to changes in the micro or that we
had to have inhouse projects to port third-part software packages
because our legacy code base was bound to unsupported microcontrollers.
 IMHO portable source code is requirement - not a luxury - for
embedded projects because of the potential volatility of the hardware -
 i.e. new features requiring the latest micro, feature growth requiring
more memory/address space, and cost reduction selecting a cheaper
micro.


Quoted text here. Click to load it

Why does a constrained system environment mitigate good software
engineering practices?  Yes a constrained system makes it harder or
impossible to the follow the "letter of the law" with respect to
software engineering - but the "spirit" of software engineering
practices can still be followed.  The projects I mentioned above where
all projects involving 8bit micros with 16K to 32K of ROM.  For the
projects that we rewrote, the code is now 98% portable across
microprocessors as well as compilers.  Moving to a new micro only
requires new implementations of the board support packages and a small
collection of HAL interfaces - no application has to be modified.
And yes, we have verified the portability by having the code compile
under multiple compilers as well as run on different processors.


Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

I won't say it has no merit, but I will say that in my
experience, the few percent of code in embedded projects that
is non-portable is so because it's target specific.  There's
simply no point in trying to write portable code to deal with
features that are particular to a single target.

Who _cares_ if the code I wront to deal with the interrupt
controller on a Samsung S3C4530B won't compile correctly under
VAX/VMS using DEC's compiler?

--
Grant Edwards                   grante             Yow!  Did an Italian CRANE
                                  at               OPERATOR just experience
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
On Monday, in article
Quoted text here. Click to load it
....

I would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines. This has been by #pragma and more recently by function attribute
for GCC, I ought to know about that.

I know of no standard definition for ISO C or whatever standard that
has been used across compilers to define hardware/software interupt
functions and vector tables.

Quoted text here. Click to load it

It is almost impossible to make an embedded application *fully*
portable the bits that directly relate to the hardware, memory
map constraints, interupts and processor are target dependent.
Some parts may only be portable to systems with the same OS.

Algorithms and quite a few functions may well be portable.

Quoted text here. Click to load it

GCC for H8 is not standards compliant for interupts at least, as
I am not aware of any standard for defining them in C.

.....
Quoted text here. Click to load it

Where in C99 does it specify how to define functions as interupt
routines, and if you can find it name a compiler that uses it.

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it

Extensions do not make a compiler non-ISO-compliant, as long as those
extensions do not alter the behavior of a conforming program.

--
John W. Temples, III

Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24

Quoted text here. Click to load it

I do hate it when people remove TOO much context as the previous poster
said that NO extensions were needed at all. A conforming program that
uses NO extensions will NOT work on all the targets *I* have seen. By this
I mean ALL types of programmes, not just tasks added to an OS on an embedded
system.

=== Previous context ======
Quoted text here. Click to load it

I would like to know WHICH compiler you use for H8 series that is ISO C
fully compliant and does not rely on an extension to define interupt
routines. This has been by #pragma and more recently by function attribute
for GCC, I ought to know about that.
=== End previous context =====

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Quoted text here. Click to load it


Err... assembly language, possibly calling a C function?

Quoted text here. Click to load it

I *never* said, nor implied that any C standard specified
interrupt handling. I simply lament the fact that the C/C++
language standards have not (yet) dealt with the issue of multiple
address spaces.

Quoted text here. Click to load it

Sure. However, there are other parts that can be made
portable. The more the merrier.

Quoted text here. Click to load it

Sure. There are many possible levels/layers of
portability/reusability.

Quoted text here. Click to load it

Yep, unless they must be optimized for a particular
architecture due to resource constraints.

Quoted text here. Click to load it

Yep. Again, there are means other than C/C++ for
implementing interrupt services, and ISRs can use
proprietary extensions in a separate module isolating
their impact on the rest of the code.


--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline