Lpc2000

For a professional developer which would be the compiler of choice:

IAR
Keil
Or another?

I would like to keep the costs under 3K if possible.

Hi,

IMHO, GCC if you are not about to squeeze the last 5% out of it. It is 
far the most configurable compiler, although its usage requires some 
more initial time investment. Debugging is another qestion. For that 
purposes I use JTAGjet/Chameleon from Signum.

regards,
marko

timothymarknorton wrote:

>For a professional developer which would be the compiler of choice:
>
>IAR
>Keil
>Or another?
>
>I would like to keep the costs under 3K if possible.
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

--- In lpc2000@yahoogroups.com, "timothymarknorton" 
<timothymarknorton@y...> wrote:
>
> For a professional developer which would be the compiler of choice:
> 
> IAR
> Keil
> Or another?
> 
> I would like to keep the costs under 3K if possible.
>

I've had a very good experience with Rowley crossworks + crosslink.  
It uses GCC as the compiler with their own IDE wrapped around it.

Great support (even (sometimes) on weekends!).

About 1200 USD including crosslink (USB JTAG debugger).

>> IAR
Keil
Or another?

I would like to keep the costs under 3K if possible. <<

I think all of the compilers would come in under \ufffd3000, that's quite a 
lot of money these days for compilers.

Support from IAR is usually not great in my experience. The Rowley IDE 
is \ufffd495+VAT and does have very good support. It's the gcc with an 
integrated debugger which works very well. This is what I use and am 
very happy with. I am lead to believe the Keil compiler has slightly 
better efficiency in terms of code density, but most of the time people 
have hundreds of kilobytes to play with and that's not such an issue! ;-)

Cheers,

Rob

I am a strong IAR advocate.  I have used Keil, struggled with GNU.

 

For serious work, the debug environment is really the key for me.  You
can use another editor, but you pretty much must us the IDE's debugger.
The IAR debugger is far superior IMO to Keil.  

 

Support from IAR has been pretty good. For some problems, I have
exchanged several emails a day with IAR.  

 

IAR also seems to be the vendor of choice for the embedded ARM demo
boards - OKI, Philips, Atmel, all use IAR for their demo kits.

 

I believe that the 256K limited product is under $2500.  I bought the
unlimited, but most programs have been quite small.  Seems like about
1:1 code size as compared with 8051 - but ARM has so much more
performance.

 

Hope this helps.

 

Dan

 

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of bell_c_d
Sent: Sunday, November 06, 2005 9:20 AM
To: lpc2000@yahoogroups.com
Subject: [lpc2000] Re: Looking to buy compiler

 

--- In lpc2000@yahoogroups.com, "timothymarknorton" 
<timothymarknorton@y...> wrote:
>
> For a professional developer which would be the compiler of choice:
> 
> IAR
> Keil
> Or another?
> 
> I would like to keep the costs under 3K if possible.
>

I've had a very good experience with Rowley crossworks + crosslink.  
It uses GCC as the compiler with their own IDE wrapped around it.

Great support (even (sometimes) on weekends!).

About 1200 USD including crosslink (USB JTAG debugger).







  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



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

timothymarknorton wrote:

>For a professional developer which would be the compiler of choice:
>
>IAR
>Keil
>Or another?
>
>I would like to keep the costs under 3K if possible.
>
>  
>
I went with gcc-3.4.3, newlib-1.13 and Insight-6.0.  Since I spend so 
little on the compiler / debug setup, I splurged and spent $2700USD for 
an Abatron BDI2000.  It has been well worth the investment.  I connect 
to it via ethernet, and use it to program the Flash (via tftp).


TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Tom Walsh wrote:
> timothymarknorton wrote:
> 
> 
>>For a professional developer which would be the compiler of choice:
>>
>>IAR
>>Keil
>>Or another?
>>
>>I would like to keep the costs under 3K if possible.
>>
>> 
>>
> 
> I went with gcc-3.4.3, newlib-1.13 and Insight-6.0.  Since I spend so 
> little on the compiler / debug setup, I splurged and spent $2700USD for 
> an Abatron BDI2000.  It has been well worth the investment.  I connect 
> to it via ethernet, and use it to program the Flash (via tftp).
> 
> 
> TomW

Good choice! ;-)

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/

> For a professional developer which would be the compiler of choice:
> 
> IAR
> Keil
> Or another?

I use Keil and like it a lot.  What few problems with the compiler I've
found had been fixed with in several days.  The support is great.

There are going to be a lot of people suggesting GNU and while I sure it a
powerful development tool I can't stand to use it.  I'm a hardware engineer
that programs and I don't want to have to be a frigg'n GNU expert just to
use a compiler.  I compare buying a compiler to buying a car;  buy
Keil/Iar/... and you get a fully assembled car, use GNU and you get a box
full of unlabeled parts, crappy documentation, no support, and you put your
own car together out of these parts...

If you want a great tool that is well supported grab Keil or one of the
other commercial compiler packages.

Fermi National Accelerator Laboratory
Electronic Systems Engineering Group
Greg Deuerling

I am with you about GNU.  Cheap, but my time is worth a lot.  IAR and
Keil are Chevy vs Ford.  

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of Greg Deuerling
Sent: Sunday, November 06, 2005 11:48 AM
To: lpc2000@yahoogroups.com
Subject: RE: [lpc2000] Looking to buy compiler

 


> For a professional developer which would be the compiler of choice:
> 
> IAR
> Keil
> Or another?

I use Keil and like it a lot.  What few problems with the compiler I've
found had been fixed with in several days.  The support is great.

There are going to be a lot of people suggesting GNU and while I sure it
a
powerful development tool I can't stand to use it.  I'm a hardware
engineer
that programs and I don't want to have to be a frigg'n GNU expert just
to
use a compiler.  I compare buying a compiler to buying a car;  buy
Keil/Iar/... and you get a fully assembled car, use GNU and you get a
box
full of unlabeled parts, crappy documentation, no support, and you put
your
own car together out of these parts...

If you want a great tool that is well supported grab Keil or one of the
other commercial compiler packages.

Fermi National Accelerator Laboratory
Electronic Systems Engineering Group
Greg Deuerling





SPONSORED LINKS 

Microprocessor
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2
=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96ET
RMZhDQ>  

Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&
w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4x
FnkFUcUw>  

Pic microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces
sor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZU
mIq6ZO0okS1g>  

 

  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



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

Hi,

Mr. Dan and Mr. Greg said some thing which I simply must comment. Sorry.

While I agree that if you are a HW engineer and you have just to toggle 
some IO pins go with a commercial product which is very easy to use, I 
totally disagree that GCC is bad documented, no support,...and things 
like you wrote. For sure you don't know GCC world enough to comment like 
this. I don't want to go further with this bar discussion but 
inform/teach yourself a little bit about GCC/Gdb/RDI and such things and 
you will be pretty surprised how powerful GCC and companion tools are.

And really you don't have to build your own car, because you can get 
precompiled packages of GCC. (www.gnuarm.com, www.codesourcery.com) , 
and try to RTFM before comment so hard.

Regards,
marko



Dan Beadle wrote:

>I am with you about GNU.  Cheap, but my time is worth a lot.  IAR and
>Keil are Chevy vs Ford.  
>
> 
>
>  _____  
>
>From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
>Of Greg Deuerling
>Sent: Sunday, November 06, 2005 11:48 AM
>To: lpc2000@yahoogroups.com
>Subject: RE: [lpc2000] Looking to buy compiler
>
> 
>
>
>  
>
>>For a professional developer which would be the compiler of choice:
>>
>>IAR
>>Keil
>>Or another?
>>    
>>
>
>I use Keil and like it a lot.  What few problems with the compiler I've
>found had been fixed with in several days.  The support is great.
>
>There are going to be a lot of people suggesting GNU and while I sure it
>a
>powerful development tool I can't stand to use it.  I'm a hardware
>engineer
>that programs and I don't want to have to be a frigg'n GNU expert just
>to
>use a compiler.  I compare buying a compiler to buying a car;  buy
>Keil/Iar/... and you get a fully assembled car, use GNU and you get a
>box
>full of unlabeled parts, crappy documentation, no support, and you put
>your
>own car together out of these parts...
>
>If you want a great tool that is well supported grab Keil or one of the
>other commercial compiler packages.
>
>Fermi National Accelerator Laboratory
>Electronic Systems Engineering Group
>Greg Deuerling
>
>
>
>
>
>SPONSORED LINKS 
>
>Microprocessor
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2
>=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96ET
>RMZhDQ>  
>
>Microcontrollers
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&
>w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4x
>FnkFUcUw>  
>
>Pic microcontrollers
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces
>sor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZU
>mIq6ZO0okS1g>  
>
> 
>
>  _____  
>
>YAHOO! GROUPS LINKS 
>
> 
>
>*	 Visit your group "lpc2000
><http://groups.yahoo.com/group/lpc2000> " on the web.
>	  
>*	 To unsubscribe from this group, send an email to:
>	 lpc2000-unsubscribe@yahoogroups.com
><mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
>	  
>*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>Service <http://docs.yahoo.com/info/terms/> . 
>
> 
>
>  _____  
>
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>



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

My last shot...

 

GNU is free.  But the learning curve to use it is higher than IAR or
Keil.  (They pretty much work in the first hour out of the box)

 

I bought a $1000 pre-configured GNU  a couple years a go.  It still
didn't solve the learning curve.  

 

I like and use the IDEs.  I often use an external editor, but making
quick change in the IDE is nice.  I work on projects with 50+ source
files.  The IDE manages builds well.

 

Finally, most all of the benchmarks show that the professional compilers
generate better code: smaller and faster.  Smaller is not that useful,
but faster always is a priority.

 

GNU is valuable once you climb the learning curve, but the $2500 or so
to buy commercial tools is cheap compared to the value of my time in
lashing together a system.  If you have climbed the learning curve,
great. 

 

Dan

 

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of Marko Panger
Sent: Sunday, November 06, 2005 1:26 PM
To: lpc2000@yahoogroups.com
Subject: Re: [lpc2000] Looking to buy compiler

 

Hi,

Mr. Dan and Mr. Greg said some thing which I simply must comment. Sorry.

While I agree that if you are a HW engineer and you have just to toggle 
some IO pins go with a commercial product which is very easy to use, I 
totally disagree that GCC is bad documented, no support,...and things 
like you wrote. For sure you don't know GCC world enough to comment like

this. I don't want to go further with this bar discussion but 
inform/teach yourself a little bit about GCC/Gdb/RDI and such things and

you will be pretty surprised how powerful GCC and companion tools are.

And really you don't have to build your own car, because you can get 
precompiled packages of GCC. (www.gnuarm.com, www.codesourcery.com) , 
and try to RTFM before comment so hard.

Regards,
marko



Dan Beadle wrote:

>I am with you about GNU.  Cheap, but my time is worth a lot.  IAR and
>Keil are Chevy vs Ford.  
>
> 
>
>  _____  
>
>From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On
Behalf
>Of Greg Deuerling
>Sent: Sunday, November 06, 2005 11:48 AM
>To: lpc2000@yahoogroups.com
>Subject: RE: [lpc2000] Looking to buy compiler
>
> 
>
>
>  
>
>>For a professional developer which would be the compiler of choice:
>>
>>IAR
>>Keil
>>Or another?
>>    
>>
>
>I use Keil and like it a lot.  What few problems with the compiler I've
>found had been fixed with in several days.  The support is great.
>
>There are going to be a lot of people suggesting GNU and while I sure
it
>a
>powerful development tool I can't stand to use it.  I'm a hardware
>engineer
>that programs and I don't want to have to be a frigg'n GNU expert just
>to
>use a compiler.  I compare buying a compiler to buying a car;  buy
>Keil/Iar/... and you get a fully assembled car, use GNU and you get a
>box
>full of unlabeled parts, crappy documentation, no support, and you put
>your
>own car together out of these parts...
>
>If you want a great tool that is well supported grab Keil or one of the
>other commercial compiler packages.
>
>Fermi National Accelerator Laboratory
>Electronic Systems Engineering Group
>Greg Deuerling
>
>
>
>
>
>SPONSORED LINKS 
>
>Microprocessor
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w
2
>=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96E
T
>RMZhDQ>  
>
>Microcontrollers
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor
&
>w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4
x
>FnkFUcUw>  
>
>Pic microcontrollers
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproce
s
>sor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZ
U
>mIq6ZO0okS1g>  
>
> 
>
>  _____  
>
>YAHOO! GROUPS LINKS 
>
> 
>
>*      Visit your group "lpc2000
><http://groups.yahoo.com/group/lpc2000> " on the web.
>        
>*      To unsubscribe from this group, send an email to:
>      lpc2000-unsubscribe@yahoogroups.com
><mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
>        
>*      Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>Service <http://docs.yahoo.com/info/terms/> . 
>
> 
>
>  _____  
>
>
>
>[Non-text portions of this message have been removed]
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>



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




  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



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

I for one respect your comments about GCC.

As one of those how have tried to use GCC and the like, I would like
to share an experience I have will the whole open source issue.

I purchased the book "Embedded System Design on a Shoestring" by Lewin
Edwards. ( this message is about the software, _not_ this book and its
author.)

I loaded the CD from the book, and nothing.
Two weeks with working with a "knowledge" friend I got the compiler
working. ( two hobby time weeks)

Great, now I have a compiler.

I built up a wiggler and tried to run the debugger and nothing again.

I asked for help from Lewin, could not figure it out.
I asked on the GCC/GDB groups, no answer (not a peep).
I asked a few more time, and someone said "are you using PRN or LPT"

Doh, whats that ?

Its the difference between DOS/WIN and *nix.

Oh. it works now...

6 weeks of tring to solve what should have been a simple problem.

It seems that if the GCC/GDB people would try to understand what the
DOS/WIN people understand rather that say "go learn it for your self",
the whole open source problem would go away.

But, I understand "whos got time to learn...." Works both ways.

Don Hamilton

Hi Don,

I am one of them open source guys that makes life difficult for you. ;-)

You have to expect some problems with many open source tools (o well,,, 
with closed source tools as well to be hounest)  but if people like you 
contribute back (in your case publish the steps you went true to get it 
all to work) it will be simpler for everyone else coming after you and 
the maintainers can possible add your info to the docs or change stuff 
in the software. This is the essence of the open source movement. We 
have to share code, send in patches and share knowledge between each 
other. There is no support to phone to get help. If people don't do this 
the tool(s) will not move forward quality vice.

I understand well the thinking that buying a compiler from Keil or IAR 
etc can be a great advantage for many people. Also as they today create 
more efficent code. But using Eclipse (which IMHO is a very good IDE)  
with GCC one can have the same compiler/environments for many, many 
target environments. And you can reuse knowledge from different 
platforms. But in the end this is just a matter of personal preference.

Cheers
/Ake

donhamilton2002 wrote:

> I for one respect your comments about GCC.
>
> As one of those how have tried to use GCC and the like, I would like
> to share an experience I have will the whole open source issue.
>
> I purchased the book "Embedded System Design on a Shoestring" by Lewin
> Edwards. ( this message is about the software, _not_ this book and its
> author.)
>
> I loaded the CD from the book, and nothing.
> Two weeks with working with a "knowledge" friend I got the compiler
> working. ( two hobby time weeks)
>
> Great, now I have a compiler.
>
> I built up a wiggler and tried to run the debugger and nothing again.
>
> I asked for help from Lewin, could not figure it out.
> I asked on the GCC/GDB groups, no answer (not a peep).
> I asked a few more time, and someone said "are you using PRN or LPT"
>
> Doh, whats that ?
>
> Its the difference between DOS/WIN and *nix.
>
> Oh. it works now...
>
> 6 weeks of tring to solve what should have been a simple problem.
>
> It seems that if the GCC/GDB people would try to understand what the
> DOS/WIN people understand rather that say "go learn it for your self",
> the whole open source problem would go away.
>
> But, I understand "whos got time to learn...." Works both ways.
>
> Don Hamilton
>
>
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>


-- 
 ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org



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

Hi all,

for choice a ARM Compiler Its' very simple.
No professional use GCC.

Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)

The GCC it's only for student, home work or for Linux user.

Best regards
Yodathegreat


--- In lpc2000@yahoogroups.com, "Ake Hedman, eurosource" <akhe@b...>
wrote:
>
> Hi Don,
> 
> I am one of them open source guys that makes life difficult for you. ;-)
> 
> You have to expect some problems with many open source tools (o well,,, 
> with closed source tools as well to be hounest)  but if people like you 
> contribute back (in your case publish the steps you went true to get it 
> all to work) it will be simpler for everyone else coming after you and 
> the maintainers can possible add your info to the docs or change stuff 
> in the software. This is the essence of the open source movement. We 
> have to share code, send in patches and share knowledge between each 
> other. There is no support to phone to get help. If people don't do
this 
> the tool(s) will not move forward quality vice.
> 
> I understand well the thinking that buying a compiler from Keil or IAR 
> etc can be a great advantage for many people. Also as they today create 
> more efficent code. But using Eclipse (which IMHO is a very good IDE)  
> with GCC one can have the same compiler/environments for many, many 
> target environments. And you can reuse knowledge from different 
> platforms. But in the end this is just a matter of personal preference.
> 
> Cheers
> /Ake
> 
> donhamilton2002 wrote:
> 
> > I for one respect your comments about GCC.
> >
> > As one of those how have tried to use GCC and the like, I would like
> > to share an experience I have will the whole open source issue.
> >
> > I purchased the book "Embedded System Design on a Shoestring" by Lewin
> > Edwards. ( this message is about the software, _not_ this book and its
> > author.)
> >
> > I loaded the CD from the book, and nothing.
> > Two weeks with working with a "knowledge" friend I got the compiler
> > working. ( two hobby time weeks)
> >
> > Great, now I have a compiler.
> >
> > I built up a wiggler and tried to run the debugger and nothing again.
> >
> > I asked for help from Lewin, could not figure it out.
> > I asked on the GCC/GDB groups, no answer (not a peep).
> > I asked a few more time, and someone said "are you using PRN or LPT"
> >
> > Doh, whats that ?
> >
> > Its the difference between DOS/WIN and *nix.
> >
> > Oh. it works now...
> >
> > 6 weeks of tring to solve what should have been a simple problem.
> >
> > It seems that if the GCC/GDB people would try to understand what the
> > DOS/WIN people understand rather that say "go learn it for your self",
> > the whole open source problem would go away.
> >
> > But, I understand "whos got time to learn...." Works both ways.
> >
> > Don Hamilton
> >
> >
> >
> >
> >
> >
------------------------------------------------------------------------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "lpc2000
> >       <http://groups.yahoo.com/group/lpc2000>" on the web.
> >        
> >     *  To unsubscribe from this group, send an email to:
> >        lpc2000-unsubscribe@yahoogroups.com
> >       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
> >        
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> >
------------------------------------------------------------------------

> >
> 
> 
> -- 
>  ---
> Ake Hedman (YAP - Yet Another Programmer)
> eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
> Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
> Company home: http://www.eurosource.se      
> Kryddor/Te/Kaffe: http://www.brattberg.com
> Personal homepage: http://www.eurosource.se/akhe
> Automated home: http://www.vscp.org
> 
> 
> 
> [Non-text portions of this message have been removed]
>

> -----Original Message-----
> From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> Of Marko Panger
> Sent: Sunday, November 06, 2005 3:26 PM
> To: lpc2000@yahoogroups.com
> Subject: Re: [lpc2000] Looking to buy compiler
> 
> Hi,
> Mr. Dan and Mr. Greg said some thing which I simply must comment. Sorry.

Free speech is a wonderful thing :)

> While I agree that if you are a HW engineer and you have just to toggle
> some IO pins go with a commercial product which is very easy to use, I
> totally disagree that GCC is bad documented, no support,...and things
> like you wrote. For sure you don't know GCC world enough to comment like
> this. I don't want to go further with this bar discussion but
> inform/teach yourself a little bit about GCC/Gdb/RDI and such things and
> you will be pretty surprised how powerful GCC and companion tools are.

Err, the system we designed that had 2000 PowerPC processors in that
reconstructed particle tracks from proton/antiproton collisions was hardly
bit banging...  I never said GCC was not powerful, it very powerful with a
very steep learning curve.  I can walk away from a Keil project and come
back to it in several months and be back up to speed in minutes.  My
experiences with GCC are not so good.

> And really you don't have to build your own car, because you can get
> precompiled packages of GCC. (www.gnuarm.com, www.codesourcery.com) ,
> and try to RTFM before comment so hard.

Pre-built or not it's still hard to use.  For instance, I wanted to set the
code protection bit on a LPC2194.  Keil I do this in the C code:

const unsigned int CodeReadProtect _at_ 0x000001Fc = 0x87654321;	//
Turns on security bit in the LPC2194

This was VERY easy to find on the Keil documentation on how to specify a
variable at a fixed location.  Even if I did not find it in the
documentation all I would have had to do is to call Keil and they would have
helped me out.

I tried and tried to RTFM on how to do this with gcc, got no where.  Asked
this news group how to do this and was told to look into linker scripts.  I
FTFM'd the linker script documentation and woke up in a pool of drool and a
real bad headache.  GCC/GNU documentation is written for GCC/GNU programmers
and experts NOT hardware engineers.

I answered the original post the way I did just in case the poster was like
me.  I really really wish GCC was as easy to use as Keil, I hate spending
the yearly maintenance fee's and would dump it in a minute if I could.  I am
going to look into ImageCraft's ARM compiler when it gets a bit more mature
and try that.  It's MUCH cheaper and I have had great success with their
HC11, AVR, and MSP430 compilers.

Timothymarknorton, good luck in your compiler search!!!


Fermi National Accelerator Laboratory
Electronic Systems Engineering Group
Greg Deuerling

--- In lpc2000@yahoogroups.com, "yodathgreat" 
<christophe.darnet@l...> wrote:
>
> Hi all,
> 
> for choice a ARM Compiler Its' very simple.
> No professional use GCC.
> 
> Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
> 
> The GCC it's only for student, home work or for Linux user.
> 
> Best regards
> Yodathegreat
> 
> 

Just one data point, but: I'm a professional developer (30 years s/w 
development experience from micros to mainframes).  Now working on 
third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
chose Rowley Crossworks (gcc-based).

A recent poll was done on this group that showed Keil and Rowley 
leading the pack for most-used compiler/IDE, so you might be 
surprised at how many professionals use gcc.

b> Just one data point, but: I'm a professional developer (30 years s/w
b> development experience from micros to mainframes).  Now working on 
b> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
b> chose Rowley Crossworks (gcc-based).

Oh, I can't hold out from the reply.
I tried to use Crossworks in the begining to explore LPC2xxx.
It ugly work with the structures. I tried to define T0MCR like
 struct:
{{
typedef struct
  { 
    __REG32 MR0I :1;
    __REG32 MR0R :1;
    __REG32 MR0S :1;

    __REG32 MR1I :1;
    __REG32 MR1R :1;
    __REG32 MR1S :1;
    
    __REG32 MR2I :1;
    __REG32 MR2R :1;
    __REG32 MR2S :1;
    
    __REG32 MR3I :1;
    __REG32 MR3R :1;
    __REG32 MR3S :1;    
    __REG32      :4;    
} __txmcr_bits;

#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)

}}

but when I handle to it, Crossworks GCC compile it to this code:

<<T0MCRbits.MR0I = 1;>>

mov r3, #0xE0000000
add r3, r3, #0x00004000
add r3, r3, #0x00000014
ldrb r2, [r3]
orr r2, r2, #0x00000001
strb r2, [r3]

so, I get change in LSB and _in_the_second_byte_!.

OK, forget about structures.
But when I try to compile code with some IRQ, I found, that optimize
level has affect on the code! The code works differ with optimize
level 1 and optimize level 3!
After that I found that interrupt context keeped incorrectly. So I had
to keep context by ASM macros.

After that I try IAR. I have not desire to come back to GCC.
My time is money.

b> A recent poll was done on this group that showed Keil and Rowley 
b> leading the pack for most-used compiler/IDE, so you might be 
b> surprised at how many professionals use gcc.







 
b> Yahoo! Groups Links



 




-- 
Best regards,
 Alex_Rambler                            mailto:bor-alex@...

> I am a strong IAR advocate.  I have used Keil, struggled with GNU.
> 1:1 code size as compared with 8051 - but ARM has so much 
> more performance.

Interesting. I don't know if it's due to the nature of my application,
or maybe the relative crappieness of the HiTech 8051 C compiler compared
to IAR, but I've actually been seeing a significant code size
*reduction* for the  same code moving from 8051 to ARM Gnu Gcc. And
that's using pure ARM kode rather than thumb as I have no pressing space
problems at this stage. (pure byte space size reduction, not cheating
comparing number of instruction words).
I did do a number of tests comparing code size for various compilers
early on using demo versions, and IAR was smaller than GCC for the same
code, but this seemed to be largely due to C-library granularity rather
than C->asm efficiency.

Cheers,
Bruce

Hi,

I'm deciding between using GCC and purchasing the Rowley Crossworks 
compiler.

I have a question though. If the Rowley compiler is GCC based, what is 
the advantage of it over the GCC one?

Cheers,

Peter.

bell_c_d wrote:

> --- In lpc2000@yahoogroups.com, "yodathgreat" 
> <christophe.darnet@l...> wrote:
> 
>>Hi all,
>>
>>for choice a ARM Compiler Its' very simple.
>>No professional use GCC.
>>
>>Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
>>
>>The GCC it's only for student, home work or for Linux user.
>>
>>Best regards
>>Yodathegreat
>>
>>
> 
> 
> Just one data point, but: I'm a professional developer (30 years s/w 
> development experience from micros to mainframes).  Now working on 
> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
> chose Rowley Crossworks (gcc-based).
> 
> A recent poll was done on this group that showed Keil and Rowley 
> leading the pack for most-used compiler/IDE, so you might be 
> surprised at how many professionals use gcc.
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> .
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

Hi, 

> I'm deciding between using GCC and purchasing the Rowley 
> Crossworks compiler.
> 
> I have a question though. If the Rowley compiler is GCC 
> based, what is the advantage of it over the GCC one?

The value is in the fact we support many target boards off the shelf
with examples.  We support ARM7, ARM9, and Xscale processors.  We have
our own CrossConnect that supports those three architectures; we have a
custom embedded C library; we can download and flash many processors
with integrated and external flashes.  The IDE has lots of features (too
many for some).  We run on Windows or Linux.  And we support our
products.

A pre-built GCC is an option for many who wish to build their
environment from bits and pieces.  We just make it all much simpler.
The only GPL code out product is GCC and the binutils themselves,
everything else we wrote.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

I have ported code from a C51 to a XAG49 and now to the LPC (ARM mode)
and found that data size is about 15% more data and about 12% less
code size and I am getting 25% more speed at the same clock frequencey
set by all three compilers. 

I used a Tasking XA and am currently using the IAR for the ARM. The
C51 was a Kiel derivative company called Franklin Software. In terms
of the best compiler I liked Tasking and was sorry to see that they
did not make an ARM version.

There are many reasons people like the compiler or hate it. It's just
a prefernce issue more then anything else. We bought IAR which has
done a great job, but they have issues as well. Documentation being
one of them. Knowing what I know now I may have purchased the Rowley
compiler instead.

just my opinion,
Charles

>> I'm deciding between using GCC and purchasing the Rowley Crossworks
compiler.

I have a question though. If the Rowley compiler is GCC based, what is
the advantage of it over the GCC one? <<

1. It just installs and works. Even on Linux it's pretty straightforward.
2. It has a nice integrated debugger.
3. First class support.

All for £495+VAT. You could maybe spend that with all the mucking
around setting up GCC and get no support.

Hi,

I have make some bench, Speed and Size code.
GCC vs ADS 1.2
GCC vs ADS 2.2
GCC vs IAR 4.30
IAR 4.30 vs ADS 1.2
IAR 4.30 vs ADS 2.2

And the GCC lose allways....

and for Rowley may be it's ok for you.
But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
And it's impossible on Rowley configuration, I have download
the eval...

35ko/sec with CrossConnect.it's funny.....My code size is 2Mo

The JTAG/Software of Rowley is a good configuration
if you have a little code on little ARM...
But if your code is big....Drink some Coffee....

And the problem with some little company (Rowley)
is the support...I'm french and I want a french Support no
a english support.

best regards
Yodathegreat

-- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:

>
> --- In lpc2000@yahoogroups.com, "yodathgreat" 
> <christophe.darnet@l...> wrote:
> >
> > Hi all,
> > 
> > for choice a ARM Compiler Its' very simple.
> > No professional use GCC.
> > 
> > Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
> > 
> > The GCC it's only for student, home work or for Linux user.
> > 
> > Best regards
> > Yodathegreat
> > 
> > 
> 
> Just one data point, but: I'm a professional developer (30 years s/w 
> development experience from micros to mainframes).  Now working on 
> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
> chose Rowley Crossworks (gcc-based).
> 
> A recent poll was done on this group that showed Keil and Rowley 
> leading the pack for most-used compiler/IDE, so you might be 
> surprised at how many professionals use gcc.
>

Hi,

I have make some bench, Speed and Size code.
GCC vs ADS 1.2
GCC vs ADS 2.2
GCC vs IAR 4.30
IAR 4.30 vs ADS 1.2
IAR 4.30 vs ADS 2.2

And the GCC lose allways....

and for Rowley may be it's ok for you.
But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
And it's impossible on Rowley configuration, I have download
the eval...

35ko/sec with CrossConnect.it's funny.....My code size is 2Mo

The JTAG/Software of Rowley is a good configuration
if you have a little code on little ARM...
But if your code is big....Drink some Coffee....

And the problem with some little company (Rowley)
is the support...I'm french and I want a french Support no
a english support.

best regards
Yodathegreat

-- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:

>
> --- In lpc2000@yahoogroups.com, "yodathgreat" 
> <christophe.darnet@l...> wrote:
> >
> > Hi all,
> > 
> > for choice a ARM Compiler Its' very simple.
> > No professional use GCC.
> > 
> > Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
> > 
> > The GCC it's only for student, home work or for Linux user.
> > 
> > Best regards
> > Yodathegreat
> > 
> > 
> 
> Just one data point, but: I'm a professional developer (30 years s/w 
> development experience from micros to mainframes).  Now working on 
> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
> chose Rowley Crossworks (gcc-based).
> 
> A recent poll was done on this group that showed Keil and Rowley 
> leading the pack for most-used compiler/IDE, so you might be 
> surprised at how many professionals use gcc.
>

Hi,

I have make some bench, Speed and Size code.
GCC vs ADS 1.2
GCC vs ADS 2.2
GCC vs IAR 4.30
IAR 4.30 vs ADS 1.2
IAR 4.30 vs ADS 2.2

And the GCC lose allways....

and for Rowley may be it's ok for you.
But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
And it's impossible on Rowley configuration, I have download
the eval...

35ko/sec with CrossConnect.it's funny.....My code size is 2Mo

The JTAG/Software of Rowley is a good configuration
if you have a little code on little ARM...
But if your code is big....Drink some Coffee....

And the problem with some little company (Rowley)
is the support...I'm french and I want a french Support no
a english support.

best regards
Yodathegreat

-- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:

>
> --- In lpc2000@yahoogroups.com, "yodathgreat" 
> <christophe.darnet@l...> wrote:
> >
> > Hi all,
> > 
> > for choice a ARM Compiler Its' very simple.
> > No professional use GCC.
> > 
> > Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
> > 
> > The GCC it's only for student, home work or for Linux user.
> > 
> > Best regards
> > Yodathegreat
> > 
> > 
> 
> Just one data point, but: I'm a professional developer (30 years s/w 
> development experience from micros to mainframes).  Now working on 
> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
> chose Rowley Crossworks (gcc-based).
> 
> A recent poll was done on this group that showed Keil and Rowley 
> leading the pack for most-used compiler/IDE, so you might be 
> surprised at how many professionals use gcc.
>

Dan Beadle wrote:

>I am with you about GNU.  Cheap, but my time is worth a lot.  IAR and
>Keil are Chevy vs Ford.  
>
>  
>
I don't wish to start a war on this topic, everybody has thier own 
favorite ways of working.  Myself, I became intrigued with Linux back in 
late 1996 when I discovered that they gave me the source code to 
everything in the system.  I just was looking to build a webserver and 
then I started thinking about how to "embed this thing!".

Well, in 1998, I decided to make a concerted effort to "master Linux".  
It was growing to take over many of the jobs I had for computers to do.  
It took me two years of intense effort: bash scripting, perl scripting, 
regular expressions, run-levels, building the kernel, learning gcc + 
binutils, etc..

I run a DOS based cross compiler for 8051, eventually it was running on 
Windows 98 in a VMware virtual machine.  I have no choice as to the 
compiler as there is a lot of legacy code written on it.  I ran the 
VMware for several years.  Finally, in 2003 I began migrating this 
development over onto the Linux platform.

First to move was the file editing, got a nice increase in productivity 
as I could now use perl to process source files and data files.  As I 
learned the vi editor (I am a touch typist), I found that I liked it.  I 
could edit files without having to reach for the mouse or grope for the 
cursor keys.  I can keep my hands on the home keys of the keyboard and: 
navigate, edit and issue commands (such as search and replace), all 
without touching the cursors or mouse.

Next to go was to take the makefile system, which was running 
Microsoft's nmake, and use dosemu + the Linux make.  The GNU make would 
run a copy operation to replace the autoexec.bat of the the dosemu, 
launch the dosemu to run the compiler / assembler / linker under DOS and 
exit.  Another nice increase in productivity as I now could stay on the 
command line to launch vi to edit files, and then type 'make' when I exited.

Finally, I implemented cvs code versioning.   This was another large 
increase in productivity as I could make massive changes to my source to 
try out new ideas, and, if it didn't work out, I could rewind the source 
back to a particular date & time.

What most people forget is that there was a learning curve to MSDOS, 
Win3.x, WinNT 4, and so on.  Each time we had a new version of Microsoft 
come out we had to relearn some things while we found other things were 
broken.  What I have discovered in my 8 years of running Linux is that 
things seldom break.  I don't have the horrific crashes that I used to 
have with the "other" O/S.  When I upgrade, software still works, I 
don't have to get a new cross-compiler version, another copy of VMware, 
EagleCAD still runs.

What I have also learned is that the effort I spent on learning / 
mastering this new thing called Linux has paid off in increased 
productivity and stability.  I would encourage other Embedded Systems 
people to take a closer look at the system.

I still run Windows 98 / NT for the occasional CPLD compiler, or to run 
QuickBooks.   Windows runs about an hour or two a week, all the rest of 
the time I'm running Linux.


Regards,

TomW

>>For a professional developer which would be the compiler of choice:
>>
>>IAR
>>Keil
>>Or another?
>>    
>>
>
>I use Keil and like it a lot.  What few problems with the compiler I've
>found had been fixed with in several days.  The support is great.
>
>There are going to be a lot of people suggesting GNU and while I sure it
>a
>powerful development tool I can't stand to use it.  I'm a hardware
>engineer
>that programs and I don't want to have to be a frigg'n GNU expert just
>to
>use a compiler.  I compare buying a compiler to buying a car;  buy
>Keil/Iar/... and you get a fully assembled car, use GNU and you get a
>box
>full of unlabeled parts, crappy documentation, no support, and you put
>your
>own car together out of these parts...
>
>If you want a great tool that is well supported grab Keil or one of the
>other commercial compiler packages.
>
>Fermi National Accelerator Laboratory
>Electronic Systems Engineering Group
>Greg Deuerling
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




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

Peter Homann wrote:

>Hi,
>
>I'm deciding between using GCC and purchasing the Rowley Crossworks 
>compiler.
>
>I have a question though. If the Rowley compiler is GCC based, what is 
>the advantage of it over the GCC one?
>
>  
>
They make it brain-dead simple to install & invoke the gcc compiler.

TomW



>Cheers,
>
>Peter.
>
>bell_c_d wrote:
>
>  
>
>>--- In lpc2000@yahoogroups.com, "yodathgreat" 
>><christophe.darnet@l...> wrote:
>>
>>    
>>
>>>Hi all,
>>>
>>>for choice a ARM Compiler Its' very simple.
>>>No professional use GCC.
>>>
>>>Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
>>>
>>>The GCC it's only for student, home work or for Linux user.
>>>
>>>Best regards
>>>Yodathegreat
>>>
>>>
>>>      
>>>
>>Just one data point, but: I'm a professional developer (30 years s/w 
>>development experience from micros to mainframes).  Now working on 
>>third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
>>chose Rowley Crossworks (gcc-based).
>>
>>A recent poll was done on this group that showed Keil and Rowley 
>>leading the pack for most-used compiler/IDE, so you might be 
>>surprised at how many professionals use gcc.
>>
>>
>>
>>
>>
>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>
>>.
>>
>>    
>>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Hi Paul,

Thanks for the quick response. Your answer was pretty much what I was 
expecting. One of the reasons I'm interested in the set-up is the 
Tasking library CTL that comes with it.

Is there any documentation about CTL that I can look at to gauge it's 
capability? My other choice is FreeRTOS.

Cheers,

Peter.


Paul Curtis wrote:

> Hi, 
> 
> 
>>I'm deciding between using GCC and purchasing the Rowley 
>>Crossworks compiler.
>>
>>I have a question though. If the Rowley compiler is GCC 
>>based, what is the advantage of it over the GCC one?
> 
> 
> The value is in the fact we support many target boards off the shelf
> with examples.  We support ARM7, ARM9, and Xscale processors.  We have
> our own CrossConnect that supports those three architectures; we have a
> custom embedded C library; we can download and flash many processors
> with integrated and external flashes.  The IDE has lots of features (too
> many for some).  We run on Windows or Linux.  And we support our
> products.
> 
> A pre-built GCC is an option for many who wish to build their
> environment from bits and pieces.  We just make it all much simpler.
> The only GPL code out product is GCC and the binutils themselves,
> everything else we wrote.
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

--- In lpc2000@yahoogroups.com, "yodathgreat" 
<christophe.darnet@l...> wrote:
>
> Hi,
> 
> I have make some bench, Speed and Size code.
> GCC vs ADS 1.2
> GCC vs ADS 2.2
> GCC vs IAR 4.30
> IAR 4.30 vs ADS 1.2
> IAR 4.30 vs ADS 2.2
> 
> And the GCC lose allways....
> 
> and for Rowley may be it's ok for you.
> But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
> And it's impossible on Rowley configuration, I have download
> the eval...
> 
> 35ko/sec with CrossConnect.it's funny.....My code size is 2Mo
> 
> The JTAG/Software of Rowley is a good configuration
> if you have a little code on little ARM...
> But if your code is big....Drink some Coffee....
> 
> And the problem with some little company (Rowley)
> is the support...I'm french and I want a french Support no
> a english support.
> 
> best regards
> Yodathegreat
> 

Dear Mr. Yodathegreat,

I was simply responding to your blanket statement that "no 
professionals use gcc".  I don't see how that lead to comparisons of 
benchmarks, download speeds, and what language the ts engineer 
speaks.

But since you brought up the subject, I did benchmarks and object 
code comparisons and there was little if any difference, and no 
practical difference because the limiting factor in my projects has 
been peripheral speed.  YMMV.

Regarding jtag download speeds, it was established in an earlier 
series of posts that download speed is mostly limited by the lpc 
hardware so all the usb-based emulators download at about the same 
speed.

Finally, if support in french is important, why didn't you list that 
as one of your original constraints in your compiler choice?  That 
may or may not be relevant to the original poster's question.

The tone of this discussion is becoming too religious for me so I 
will say no more.

Hi bell_c_d,

It's ok for me, it's just for speak.
the problem with Forum (all) we don't know if
the message writer is a student, professional expert or beginner.

And I compare only the professional solution vs Shareware solution.

example Rowley is expensive for a GCC solution...
But ADS or IAR + JTAG (EPITOOLS or ARM) is very very expensive.

The choise is very complicated that depend of projets, money etc...

For me, and just for me, the support is very important.
Example :
IAR respond very quickly for buf found in Compiler or other.
ARM no support, if you don't win 10 000 000 $$$ no support......
EPITOOLS Good support but not perfect.
ASHLING very good support etc etc

best regards
Christophe (Yodathegreat)

--- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:

>
> --- In lpc2000@yahoogroups.com, "yodathgreat" 
> <christophe.darnet@l...> wrote:
> >
> > Hi,
> > 
> > I have make some bench, Speed and Size code.
> > GCC vs ADS 1.2
> > GCC vs ADS 2.2
> > GCC vs IAR 4.30
> > IAR 4.30 vs ADS 1.2
> > IAR 4.30 vs ADS 2.2
> > 
> > And the GCC lose allways....
> > 
> > and for Rowley may be it's ok for you.
> > But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
> > And it's impossible on Rowley configuration, I have download
> > the eval...
> > 
> > 35ko/sec with CrossConnect.it's funny.....My code size is 2Mo
> > 
> > The JTAG/Software of Rowley is a good configuration
> > if you have a little code on little ARM...
> > But if your code is big....Drink some Coffee....
> > 
> > And the problem with some little company (Rowley)
> > is the support...I'm french and I want a french Support no
> > a english support.
> > 
> > best regards
> > Yodathegreat
> > 
> 
> Dear Mr. Yodathegreat,
> 
> I was simply responding to your blanket statement that "no 
> professionals use gcc".  I don't see how that lead to comparisons of 
> benchmarks, download speeds, and what language the ts engineer 
> speaks.
> 
> But since you brought up the subject, I did benchmarks and object 
> code comparisons and there was little if any difference, and no 
> practical difference because the limiting factor in my projects has 
> been peripheral speed.  YMMV.
> 
> Regarding jtag download speeds, it was established in an earlier 
> series of posts that download speed is mostly limited by the lpc 
> hardware so all the usb-based emulators download at about the same 
> speed.
> 
> Finally, if support in french is important, why didn't you list that 
> as one of your original constraints in your compiler choice?  That 
> may or may not be relevant to the original poster's question.
> 
> The tone of this discussion is becoming too religious for me so I 
> will say no more.
>

The Rowley USB-JTAG cable ("emulator") is called crossconnect.

Regards
Michael

>--- In lpc2000@yahoogroups.com, "timothymarknorton" 
><timothymarknorton@y...> wrote:
>  
>
>>For a professional developer which would be the compiler of choice:
>>
>>IAR
>>Keil
>>Or another?
>>
>>I would like to keep the costs under 3K if possible.
>>
>>    
>>
>
>I've had a very good experience with Rowley crossworks + crosslink.  
>It uses GCC as the compiler with their own IDE wrapped around it.
>
>Great support (even (sometimes) on weekends!).
>
>About 1200 USD including crosslink (USB JTAG debugger).
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

yodathgreat wrote:

>Hi,
>
>I have make some bench, Speed and Size code.
>GCC vs ADS 1.2
>GCC vs ADS 2.2
>GCC vs IAR 4.30
>IAR 4.30 vs ADS 1.2
>IAR 4.30 vs ADS 2.2
>
>And the GCC lose allways....
>
>and for Rowley may be it's ok for you.
>But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
>And it's impossible on Rowley configuration, I have download
>the eval...
>
>35ko/sec with CrossConnect.it's funny.....My code size is 2Mo
>  
>
The download speed for the Philips part has improved in the next 
firmware release - we have optimised the RTCK implementation. Are you 
really planning to download 2Mb to an LPC2xxx board?

>The JTAG/Software of Rowley is a good configuration
>if you have a little code on little ARM...
>But if your code is big....Drink some Coffee....
>  
>
>And the problem with some little company (Rowley)
>is the support...I'm french and I want a french Support no
>a english support.
>  
>
Sounds like you have a firm criteria for product purchase - bon chance.

Regards
Michael

>best regards
>Yodathegreat
>
>-- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:
>  
>
>>--- In lpc2000@yahoogroups.com, "yodathgreat" 
>><christophe.darnet@l...> wrote:
>>    
>>
>>>Hi all,
>>>
>>>for choice a ARM Compiler Its' very simple.
>>>No professional use GCC.
>>>
>>>Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
>>>
>>>The GCC it's only for student, home work or for Linux user.
>>>
>>>Best regards
>>>Yodathegreat
>>>
>>>
>>>      
>>>
>>Just one data point, but: I'm a professional developer (30 years s/w 
>>development experience from micros to mainframes).  Now working on 
>>third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
>>chose Rowley Crossworks (gcc-based).
>>
>>A recent poll was done on this group that showed Keil and Rowley 
>>leading the pack for most-used compiler/IDE, so you might be 
>>surprised at how many professionals use gcc.
>>
>>    
>>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>

I have to agree with the other rowley users.

it just works.

previously i was using gcc for hitachi H8S projects. this had cost 
me alot of time, working with just the gcc package. the rowley ide 
makes it simple. then the debugger it's great. the flash is 
programmed and of you go.

joost

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Hi,
> 
> I'm deciding between using GCC and purchasing the Rowley 
Crossworks 
> compiler.
> 
> I have a question though. If the Rowley compiler is GCC based, 
what is 
> the advantage of it over the GCC one?
> 
> Cheers,
> 
> Peter.
> 
> bell_c_d wrote:
> 
> > --- In lpc2000@yahoogroups.com, "yodathgreat" 
> > <christophe.darnet@l...> wrote:
> > 
> >>Hi all,
> >>
> >>for choice a ARM Compiler Its' very simple.
> >>No professional use GCC.
> >>
> >>Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
> >>
> >>The GCC it's only for student, home work or for Linux user.
> >>
> >>Best regards
> >>Yodathegreat
> >>
> >>
> > 
> > 
> > Just one data point, but: I'm a professional developer (30 years 
s/w 
> > development experience from micros to mainframes).  Now working 
on 
> > third LPC-based commercial product.  Compared Keil, IAR, and gcc 
and 

> > chose Rowley Crossworks (gcc-based).
> > 
> > A recent poll was done on this group that showed Keil and Rowley 
> > leading the pack for most-used compiler/IDE, so you might be 
> > surprised at how many professionals use gcc.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > .
> > 
> 
> -- 
> ------------------------------------------------------------------
> Web:   www.homanndesigns.com
> email: homann@h...
> Phone: +61 421 601 665
> www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>

Hi,

I'm using KEIL, and i'm very happy about code generation, code size and 
support.

I received IAR and GCC for tests. Because i hadn't a lot of time to decide, 
i choosed which compiler was faster to implement.

In one day KEIL was configurated and was loaded on a target.

I choosed FREE RTOS and with keil it's very easy to implement, because you 
have directly in free rtos a project file for KEIL. So in one day i 
implemented free rtos in keil.






----- Original Message ----- 

From: "timothymarknorton" <timothymarknorton@...>
To: <lpc2000@yahoogroups.com>
Sent: Sunday, November 06, 2005 5:48 PM
Subject: [lpc2000] Looking to buy compiler


> For a professional developer which would be the compiler of choice:
>
> IAR
> Keil
> Or another?
>
> I would like to keep the costs under 3K if possible.
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>

Hi Michael,

It's not a sounds...it's my experience.
And no, I don't have a 2Mo Code for LPC.
My Bigs codes is for EP9312 and PXA270.

I work in Gambling Machine, see my Web, http://www.dev-elec.com

And my customer don't want a bug..even not small bug..
0.0 BUG.....It's very hard.
For my job is 60% Gambling Machine, 40% industrial company.

many customers don't want GCC because it's free..paradoxal...no

Best regards At All
Christophe Also Yodathegreat


--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:

>
> yodathgreat wrote:
> 
> >Hi,
> >
> >I have make some bench, Speed and Size code.
> >GCC vs ADS 1.2
> >GCC vs ADS 2.2
> >GCC vs IAR 4.30
> >IAR 4.30 vs ADS 1.2
> >IAR 4.30 vs ADS 2.2
> >
> >And the GCC lose allways....
> >
> >and for Rowley may be it's ok for you.
> >But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
> >And it's impossible on Rowley configuration, I have download
> >the eval...
> >
> >35ko/sec with CrossConnect.it's funny.....My code size is 2Mo
> >  
> >
> The download speed for the Philips part has improved in the next 
> firmware release - we have optimised the RTCK implementation. Are you 
> really planning to download 2Mb to an LPC2xxx board?
> 
> >The JTAG/Software of Rowley is a good configuration
> >if you have a little code on little ARM...
> >But if your code is big....Drink some Coffee....
> >  
> >
> >And the problem with some little company (Rowley)
> >is the support...I'm french and I want a french Support no
> >a english support.
> >  
> >
> Sounds like you have a firm criteria for product purchase - bon chance.
> 
> Regards
> Michael
> 
> >best regards
> >Yodathegreat
> >
> >-- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:
> >  
> >
> >>--- In lpc2000@yahoogroups.com, "yodathgreat" 
> >><christophe.darnet@l...> wrote:
> >>    
> >>
> >>>Hi all,
> >>>
> >>>for choice a ARM Compiler Its' very simple.
> >>>No professional use GCC.
> >>>
> >>>Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
> >>>
> >>>The GCC it's only for student, home work or for Linux user.
> >>>
> >>>Best regards
> >>>Yodathegreat
> >>>
> >>>
> >>>      
> >>>
> >>Just one data point, but: I'm a professional developer (30 years s/w 
> >>development experience from micros to mainframes).  Now working on 
> >>third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
> >>chose Rowley Crossworks (gcc-based).
> >>
> >>A recent poll was done on this group that showed Keil and Rowley 
> >>leading the pack for most-used compiler/IDE, so you might be 
> >>surprised at how many professionals use gcc.
> >>
> >>    
> >>
> >
> >
> >
> >
> >
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >
> >  
> >
>

Hi Christophe,

>Hi Michael,
>
>It's not a sounds...it's my experience.
>And no, I don't have a 2Mo Code for LPC.
>My Bigs codes is for EP9312 and PXA270.
>  
>
Okay, CrossWorks/CrossConnect can download at 200Kbytes per second on an 
XScale - we are currently looking to find an affordable PXA270 
development board to target.

>I work in Gambling Machine, see my Web, http://www.dev-elec.com
>
>And my customer don't want a bug..even not small bug..
>0.0 BUG.....It's very hard.
>  
>
I wouldn't want to work for people in the gambling industry - perhaps 
I've seen too many films...

>For my job is 60% Gambling Machine, 40% industrial company.
>
>many customers don't want GCC because it's free..paradoxal...no
>  
>
I can understand this. CrossWorks/CrossConnect can be used with an 
Elf/Dwarf image created by a different compiler. We have had one 
customer who was using CrossWorks with the ImageCraft compiler.

Regards
Michael

>Best regards At All
>Christophe Also Yodathegreat
>
>
>--- In lpc2000@yahoogroups.com, Michael Johnson <mpj@r...> wrote:
>  
>
>>yodathgreat wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>I have make some bench, Speed and Size code.
>>>GCC vs ADS 1.2
>>>GCC vs ADS 2.2
>>>GCC vs IAR 4.30
>>>IAR 4.30 vs ADS 1.2
>>>IAR 4.30 vs ADS 2.2
>>>
>>>And the GCC lose allways....
>>>
>>>and for Rowley may be it's ok for you.
>>>But we uses a real JTAG. (JENNI, NOHAU, MAJIC MX , OPELLA, GENIA)
>>>And it's impossible on Rowley configuration, I have download
>>>the eval...
>>>
>>>35ko/sec with CrossConnect.it's funny.....My code size is 2Mo
>>> 
>>>
>>>      
>>>
>>The download speed for the Philips part has improved in the next 
>>firmware release - we have optimised the RTCK implementation. Are you 
>>really planning to download 2Mb to an LPC2xxx board?
>>
>>    
>>
>>>The JTAG/Software of Rowley is a good configuration
>>>if you have a little code on little ARM...
>>>But if your code is big....Drink some Coffee....
>>> 
>>>
>>>And the problem with some little company (Rowley)
>>>is the support...I'm french and I want a french Support no
>>>a english support.
>>> 
>>>
>>>      
>>>
>>Sounds like you have a firm criteria for product purchase - bon chance.
>>
>>Regards
>>Michael
>>
>>    
>>
>>>best regards
>>>Yodathegreat
>>>
>>>-- In lpc2000@yahoogroups.com, "bell_c_d" <bell_c_d@y...> wrote:
>>> 
>>>
>>>      
>>>
>>>>--- In lpc2000@yahoogroups.com, "yodathgreat" 
>>>><christophe.darnet@l...> wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>Hi all,
>>>>>
>>>>>for choice a ARM Compiler Its' very simple.
>>>>>No professional use GCC.
>>>>>
>>>>>Only ADS 1.2 or 2.2, Or IAR compiler.(there are similar)
>>>>>
>>>>>The GCC it's only for student, home work or for Linux user.
>>>>>
>>>>>Best regards
>>>>>Yodathegreat
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Just one data point, but: I'm a professional developer (30 years s/w 
>>>>development experience from micros to mainframes).  Now working on 
>>>>third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
>>>>chose Rowley Crossworks (gcc-based).
>>>>
>>>>A recent poll was done on this group that showed Keil and Rowley 
>>>>leading the pack for most-used compiler/IDE, so you might be 
>>>>surprised at how many professionals use gcc.
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>
>>>
>>>
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>  
>

I tried the IAR kit, and I was not happy.  They had quite a few bugs.  Far more than I expected for an expensive compiler.   Then I tried the GNUARM and it worked right off the bat.  I've never looked back since.  I was fully prepared to pay $2K for a dev system, but the fact is the GNUARM worked better and was free.  I just run it out of UltraEdit as my IDE and I have no desire to change.  If the GCC compiler is good enough to compile all of 10GB Linux on multiple platforms, it's good enough for my embedded apps.

Chris.

  ----- Original Message ----- 
  From: timothymarknorton 
  To: lpc2000@yahoogroups.com 
  Sent: Sunday, November 06, 2005 8:48 AM
  Subject: [lpc2000] Looking to buy compiler


  For a professional developer which would be the compiler of choice:

  IAR
  Keil
  Or another?

  I would like to keep the costs under 3K if possible.





------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "lpc2000" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     lpc2000-unsubscribe@yahoogroups.com
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------------------------------------------------------------------------------



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

Hi Peter, 

> Thanks for the quick response. Your answer was pretty much 
> what I was expecting. One of the reasons I'm interested in 
> the set-up is the Tasking library CTL that comes with it.
> 
> Is there any documentation about CTL that I can look at to 
> gauge it's capability? My other choice is FreeRTOS.

It's all on the web:

http://www.rowley.co.uk/documentation/arm/ctl.htm

The CTL will be fleshed out with some more capability, not necessarily
related to tasking, in future releases.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

----- Original Message ----- 

From: <sig5534@...>
To: <lpc2000@yahoogroups.com>
Sent: Monday, November 07, 2005 10:10 AM
Subject: Re: [lpc2000] Looking to buy compiler


>I tried the IAR kit, and I was not happy.  They had quite a few bugs.  Far 
>more than I expected for an expensive compiler.   Then I tried the GNUARM 
>and it worked right off the bat.  I've never looked back since.  I was 
>fully prepared to pay $2K for a dev system, but the fact is the GNUARM 
>worked better and was free.  I just run it out of UltraEdit as my IDE and I 
>have no desire to change.  If the GCC compiler is good enough to compile 
>all of 10GB Linux on multiple platforms, it's good enough for my embedded 
>apps.

When I worked for Racal Comms, the software engineers on one project gave up 
on the very expensive 68K compiler they were supposed to use as it had too 
many bugs and used gcc instead. Management wasn't told for some time and was 
horrified when they heard that free software was being used on a \ufffd10 million 
MoD project. They couldn't do much about it, especially as the firmware 
worked and was on time. 8-)

Leon 

---
[This E-mail has been scanned for viruses but it is your responsibility 
to maintain up to date anti virus software on the device that you are
currently using to read this email. ]

>> I am with you about GNU.  Cheap, but my time is worth a lot.  IAR and
Keil are Chevy vs Ford.  <<

Sorry to be slow, but I don't understand this analogy. For people in the 
parts of the world that don't have Chevrolet (I assume that's what Chevy 
is), are Chevrolets much better than Fords? Does that mean to you IAR is 
much better than Keil? And shouldn't it be Chevy v VW if you're 
comparing it with Keil?! ;-)

Mark, 

> Currenty I am testing with a 32K limit IAR compiler and 
> J-Link.  My new question is will the Rowley setup with 
> Crossconnect give me the same debugging capabilities, 

I would say so, but if you can enumerate...

> how about the same speed?  

Faster than everything up to v1.4 J-Link hardware into RAM and flash,
CrossConnect is slower than the J-Link v1.5 hardware (must just have hit
the streets) into RAM.  But we'll fix that.  :-)

> Also I see on the Rowley website that the J-link is supported. 

Yes.

> Would this require me to purchase the RDI driver from Seggar 
> or will the J-link that came in my IAR kickstart kit work 
> with the Rowley IDE?

You don't need the RDI drivers.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Currenty I am testing with a 32K limit IAR compiler
and J-Link.  My new question is will the Rowley setup
with Crossconnect give me the same debugging
capabilities, how about the same speed?  Also I see on
the Rowley website that the J-link is supported. 
Would this require me to purchase the RDI driver from
Seggar or will the J-link that came in my IAR
kickstart kit work with the Rowley IDE?

--- Michael Johnson <mpj@...> wrote:

> The Rowley USB-JTAG cable ("emulator") is called
> crossconnect.
> 
> Regards
> Michael
> 
> >--- In lpc2000@yahoogroups.com, "timothymarknorton"
> 
> ><timothymarknorton@y...> wrote:
> >  
> >
> >>For a professional developer which would be the
> compiler of choice:
> >>
> >>IAR
> >>Keil
> >>Or another?
> >>
> >>I would like to keep the costs under 3K if
> possible.
> >>
> >>    
> >>
> >
> >I've had a very good experience with Rowley
> crossworks + crosslink.  
> >It uses GCC as the compiler with their own IDE
> wrapped around it.
> >
> >Great support (even (sometimes) on weekends!).
> >
> >About 1200 USD including crosslink (USB JTAG
> debugger).
> >
> >
> >
> >
> >
> >
> >
> > 
> >Yahoo! Groups Links
> >
> >
> >
> > 
> >
> >
> >  
> >
> 
> 



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Hi Mark, 

> -----Original Message-----
> From: Mark Norton [mailto:timothymarknorton@...] 
> Sent: 07 November 2005 14:23
> To: lpc2000@yahoogroups.com
> Subject: RE: [lpc2000] Re: Looking to buy compiler
> 
> So I should be able to download the eval copy and use my 
> J-Link to test?  

Yes.  You need to match firmware in the J-Link and the DLL, though.
This isn't well documented...

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

So I should be able to download the eval copy and use
my J-Link to test?  

--- Paul Curtis <plc@...> wrote:

> Mark, 
> 
> > Currenty I am testing with a 32K limit IAR
> compiler and 
> > J-Link.  My new question is will the Rowley setup
> with 
> > Crossconnect give me the same debugging
> capabilities, 
> 
> I would say so, but if you can enumerate...
> 
> > how about the same speed?  
> 
> Faster than everything up to v1.4 J-Link hardware
> into RAM and flash,
> CrossConnect is slower than the J-Link v1.5 hardware
> (must just have hit
> the streets) into RAM.  But we'll fix that.  :-)
> 
> > Also I see on the Rowley website that the J-link
> is supported. 
> 
> Yes.
> 
> > Would this require me to purchase the RDI driver
> from Seggar 
> > or will the J-link that came in my IAR kickstart
> kit work 
> > with the Rowley IDE?
> 
> You don't need the RDI drivers.
> 
> --
> Paul Curtis, Rowley Associates Ltd 
> http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ
> processors
> 



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Hello all,

I am receiving the answers of Paul 2 minutes before the questions of Mark.
Isn't that fast support...

Greetings from Aalt,

-- 
==============================
Aalt Lokhorst
Schut Geometrische Meettechniek bv
Duinkerkenstraat 21
9723 BN Groningen
P.O. Box 5225
9700 GE Groningen
The Netherlands
Tel: +31-50-5877877
Fax: +31-50-5877899
E-mail: Lokhorst@...
==============================


Paul Curtis wrote:

> Hi Mark,
> 
>  > -----Original Message-----
>  > From: Mark Norton [mailto:timothymarknorton@...]
>  > Sent: 07 November 2005 14:23
>  > To: lpc2000@yahoogroups.com
>  > Subject: RE: [lpc2000] Re: Looking to buy compiler
>  >
>  > So I should be able to download the eval copy and use my
>  > J-Link to test? 
> 
> Yes.  You need to match firmware in the J-Link and the DLL, though.
> This isn't well documented...
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> 
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
> 
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
> 
> 
> ------------------------------------------------------------------------
>

I download the eval and it worked out of the box with
the j-link.  I'll browse the tutoral and probably get
back with some questions.

--- Paul Curtis <plc@...> wrote:

> Hi Mark, 
> 
> > -----Original Message-----
> > From: Mark Norton
> [mailto:timothymarknorton@...] 
> > Sent: 07 November 2005 14:23
> > To: lpc2000@yahoogroups.com
> > Subject: RE: [lpc2000] Re: Looking to buy compiler
> > 
> > So I should be able to download the eval copy and
> use my 
> > J-Link to test?  
> 
> Yes.  You need to match firmware in the J-Link and
> the DLL, though.
> This isn't well documented...
> 
> --
> Paul Curtis, Rowley Associates Ltd 
> http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ
> processors
> 



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

Have you tried gcc with Eclipse as an IDE? That puts you right into a
driver seat of a BMW.

--- In lpc2000@yahoogroups.com, "Dan Beadle" <dan.beadle@i...> wrote:

>
> I am with you about GNU.  Cheap, but my time is worth a lot.  IAR and
> Keil are Chevy vs Ford.  
> 
>  
> 
>   _____  
> 
> From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
> Of Greg Deuerling
> Sent: Sunday, November 06, 2005 11:48 AM
> To: lpc2000@yahoogroups.com
> Subject: RE: [lpc2000] Looking to buy compiler
> 
>  
> 
> 
> > For a professional developer which would be the compiler of choice:
> > 
> > IAR
> > Keil
> > Or another?
> 
> I use Keil and like it a lot.  What few problems with the compiler I've
> found had been fixed with in several days.  The support is great.
> 
> There are going to be a lot of people suggesting GNU and while I sure it
> a
> powerful development tool I can't stand to use it.  I'm a hardware
> engineer
> that programs and I don't want to have to be a frigg'n GNU expert just
> to
> use a compiler.  I compare buying a compiler to buying a car;  buy
> Keil/Iar/... and you get a fully assembled car, use GNU and you get a
> box
> full of unlabeled parts, crappy documentation, no support, and you put
> your
> own car together out of these parts...
> 
> If you want a great tool that is well supported grab Keil or one of the
> other commercial compiler packages.
> 
> Fermi National Accelerator Laboratory
> Electronic Systems Engineering Group
> Greg Deuerling
> 
> 
> 
> 
> 
> SPONSORED LINKS 
> 
> Microprocessor
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2
> =Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=YXTZih-RJw5W96ET
> RMZhDQ>  
> 
> Microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&
> w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=bE-R787UQ86O4x
> FnkFUcUw>  
> 
> Pic microcontrollers
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces
> sor&w2=Microcontrollers&w3=Pic+microcontrollers&c=3&s=68&.sig=kb_XlXirZU
> mIq6ZO0okS1g>  
> 
>  
> 
>   _____  
> 
> YAHOO! GROUPS LINKS 
> 
>  
> 
> *	 Visit your group "lpc2000
> <http://groups.yahoo.com/group/lpc2000> " on the web.
> 	  
> *	 To unsubscribe from this group, send an email to:
> 	 lpc2000-unsubscribe@yahoogroups.com
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
> 	  
> *	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/> . 
> 
>  
> 
>   _____  
> 
> 
> 
> [Non-text portions of this message have been removed]
>

--- In lpc2000@yahoogroups.com, "lpcarmed" <lpcarmed@g...> wrote:
>
> Have you tried gcc with Eclipse as an IDE? That puts you right into a
> driver seat of a BMW.

I am using that setup and it works well.  However, I haven't really 
come to love OCD Remote and Insight.  Besides, I don't have enough 
pins to give away just to use jtag.

Eventually I need to find out how to cut back on the library code - it 
is GIGANTIC.

Richard

Hi, 

> I have make some bench, Speed and Size code.
> GCC vs ADS 1.2
> GCC vs ADS 2.2
> GCC vs IAR 4.30
> IAR 4.30 vs ADS 1.2
> IAR 4.30 vs ADS 2.2
> 
> And the GCC lose allways....

You don't say which version of GCC you're using (yet you do quote
versions for other tools), nor which libraries you're linking in.  Code
size is dependent upon the libraries you link which is why we have
written our own.

> 35ko/sec with CrossConnect.it's funny.....My code size is 2Mo

You only pay £99 for CrossConnect, but we can download at more than
35KB/second.  2MB and you'll need to use a big LPC with external memory.

> The JTAG/Software of Rowley is a good configuration if you 
> have a little code on little ARM...
> But if your code is big....Drink some Coffee....

Why would anything else be better *if* you're downloading to flash?
From our experience, StataFlash-based devices take one hell of a long
time to erase, but can be programmed at about 200K/second.  RAM
development is, of course, another matter but even then an ARM7TDMI-S is
limited in speed.  We're looking at accelerating the CrossConnect and
keeping the price point the same.

> And the problem with some little company (Rowley) is the 
> support...I'm french and I want a french Support no a english support.

Try Raisonance... :-)

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

rtstofer wrote:

>--- In lpc2000@yahoogroups.com, "lpcarmed" <lpcarmed@g...> wrote:
>  
>
>>Have you tried gcc with Eclipse as an IDE? That puts you right into a
>>driver seat of a BMW.
>>    
>>
>
>I am using that setup and it works well.  However, I haven't really 
>come to love OCD Remote and Insight.  Besides, I don't have enough 
>pins to give away just to use jtag.
>
>Eventually I need to find out how to cut back on the library code - it 
>is GIGANTIC.
>
>  
>
What library are you using?  I'm using NewLib and it seems to be 
reasonable in size.  Of course, I stay away from stuff like sprintf(), 
sscanf() and use itoa() + my own atoi() routines..  Sometimes you just 
gotta write your own stuff, heh.  ;-)

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




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

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> rtstofer wrote:
> 
> >--- In lpc2000@yahoogroups.com, "lpcarmed" <lpcarmed@g...> wrote:
> >  
> >
> >>Have you tried gcc with Eclipse as an IDE? That puts you right 
into a
> >>driver seat of a BMW.
> >>    
> >>
> >
> >I am using that setup and it works well.  However, I haven't 
really 
> >come to love OCD Remote and Insight.  Besides, I don't have 
enough 
> >pins to give away just to use jtag.
> >
> >Eventually I need to find out how to cut back on the library 
code - it 
> >is GIGANTIC.
> >
> >  
> >
> What library are you using?  I'm using NewLib and it seems to be 
> reasonable in size.  Of course, I stay away from stuff like sprintf
(), 
> sscanf() and use itoa() + my own atoi() routines..  Sometimes you 
just 
> gotta write your own stuff, heh.  ;-)
> 
> TomW

As far as I know, I am using newlib.  However, the uIP web server 
application uses vsprintf and that pulls in a LOT of library code.  
The entire network project seems to take about 23k (0000h - 5887h) 
and the library adds nearly another 32K (5888h - D244h).

After reading the promo stuff about uIP, I thought the stack would 
be on the small side.  When I got the web server running (without 
FreeRTOS), it takes 60444 bytes including the .rodata.  HUGE!

Maybe I am bringing in too many libraries but it seemed right at the 
time:

ARCHIVE1= "C:/Program Files/GNUARM/lib/gcc/arm-elf/3.4.3"
ARCHIVE2= "C:/Program Files/GNUARM/arm-elf/lib"
LIBFLAGS= -L${ARCHIVE2} -lc -lg -L$(ARCHIVE1) -lgcc 

Anyway, I now want to integrate FreeRTOS (I think) and add my 
FAT32/CF drivers and my MP3 stuff.  The objective is a simple 
networkable MP3 player for special effects.  I will probably change 
from httpd to telnetd so I can just open a connection and send a 
command to play a file.

But FreeRTOS will require a lot of thought.  I have to share things 
like the 8 bit data bus, 4 bit addr bus, chip select and RD/WR 
signals.  No one process can just own them.  And, I can't have 
buffer underrun for the MP3 chip.  It would be even more interesting 
if I stored the MP3 files on an nfs server but I already have a 
Linux board doing that - see www.gumstix.com using the gumstix, 
cfstix and audiostix.  It works but it is price prohibitive for 
Halloween effects.  I need about 6 of these gadgets.

If I have messed up on the libraries, please let me know!

Thanks
Richard

Paul Curtis wrote:

>Hi, 
>
>  
>
>>I have make some bench, Speed and Size code.
>>GCC vs ADS 1.2
>>GCC vs ADS 2.2
>>GCC vs IAR 4.30
>>IAR 4.30 vs ADS 1.2
>>IAR 4.30 vs ADS 2.2
>>
>>And the GCC lose allways....
>>    
>>
>
>You don't say which version of GCC you're using (yet you do quote
>versions for other tools), nor which libraries you're linking in.  Code
>size is dependent upon the libraries you link which is why we have
>written our own.
>
>  
>
Yes, if you look at the code emitted by the gcc compiler under the -Os 
(optimize for size) you would find it amazingly tight!  Now, if you turn 
off the optimizer, -O0, you will get very wordy code...

What people should do in performance testing is to compare apples to 
apples: use the same libraries to link against.  Not just use, for 
example, NewLib, but the same binary image of NewLib, not one compiled 
for the development system.

Libraries are key, you chose the library for the level of complexity you 
need.  If you do not need re-entrant code, or file descriptor support, 
choose a library to that is stripped of that.  However, where file 
streams are part of the library, you will suffer a performance penalty.

Even if you don't use the streams / file descriptors, a function such as 
printf() may be looking to see what stdout file handle to process the 
data stream through.  The advantage is that you can direct the stdout 
stream to a file (drive), or direct it to a console (serial port). Or, 
you can use fprintf() to dynamically print to various streams.

With reduced footprint libraries, your default output of printf may be 
fixed to a serial port, hence, a decision has been made for you and the 
unnecessary code has been stripped.  The resulting code *will* run 
faster, becuase it is doing less work.

With the project that I am working on, I need file streams.  There is an 
MMC drive on the LPC2138, a serial port to the outside world and another 
serial port to an LPC2106.  On this system, I plan to assign the stderr 
stream to a logfile on the MMC drive.

The file stream example is just that, an example.  I am not saying that 
any of the development systems offered don't support file streams, they 
may.  But since I have been working in ANSI C for many years, and high 
level operations of the library are needed (errno, etc.), I went with a 
"standard" library.  I had used a stripped library to do C programming 
on an 8051 and you couldn't do things like file streams without adding a 
lot of new code to the library.

The LPC2138 application, which will be doing file streams, is not that 
time critical, a few seconds either way is no big deal.  However, the 
LPC2106 has tighter timing restrictions, that is one of the reasons for 
two processors: one to loaf along collecting / processing data, the 
other to accept the data and pass it downstream to monitoring systems.

Everything is a tradeoff.  Just because you can perform an operation in 
1/10 of the time is not reason enough  to justify that level of 
performance...


Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




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

rtstofer wrote:

>As far as I know, I am using newlib.  However, the uIP web server 
>application uses vsprintf and that pulls in a LOT of library code.  
>The entire network project seems to take about 23k (0000h - 5887h) 
>and the library adds nearly another 32K (5888h - D244h).
>
>After reading the promo stuff about uIP, I thought the stack would 
>be on the small side.  When I got the web server running (without 
>FreeRTOS), it takes 60444 bytes including the .rodata.  HUGE!
>  
>
No, you're probably right on target.  Functions like printf(), in any 
form, usually pull in a lot of other code.  It may be lazy programming 
on the part of the writer of the uIP stack, or, that that level of 
complexity is needed and that the target processor you've chosen is not 
capable of supporting the code.

"Champagne tastes on a beer budget"?  You might consider doing what I 
did.  I needed a lot of codespace to write a DOS layer for MMC, plus 
another goal was to put 11 programs into one processor (old product was 
64K EPROM on 8051).  The problem was that I needed 16K just to hold 
data, I have to track external events and give instant status reports 
when queried.  The solution was to use an LPC2138 to hold the very large 
code store, then use an LCP2106 to store the data in RAM.

Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

> As far as I know, I am using newlib.  However, the uIP web server
> application uses vsprintf and that pulls in a LOT of library code.
> The entire network project seems to take about 23k (0000h - 5887h)
> and the library adds nearly another 32K (5888h - D244h).

More than I would expect.

I originally got the FreeRTOS lwIP demo running using CrossWorks.  When I
came to compile the same code using the standard command line GCC (with
newLib) I found it to be *much* more stack hungry and had to increase the
stack allocated to the WEB server and lwIP tasks.

While increased stack usage was not a surprise as the CrossWorks build used
the libraries without floating point support (for printf, etc.) the size of
the difference was surprising.  I have not yet analysed the map files to see
where the difference is occurring.

Regards,
Richard.


http://www.FreeRTOS.org

--- In lpc2000@yahoogroups.com, "FreeRTOS Info" <nospam@F...> wrote:
>
> > As far as I know, I am using newlib.  However, the uIP web server
> > application uses vsprintf and that pulls in a LOT of library 
code.
> > The entire network project seems to take about 23k (0000h - 
5887h)
> > and the library adds nearly another 32K (5888h - D244h).
> 
> More than I would expect.
> 
> I originally got the FreeRTOS lwIP demo running using CrossWorks.  
When I
> came to compile the same code using the standard command line GCC 
(with
> newLib) I found it to be *much* more stack hungry and had to 
increase the
> stack allocated to the WEB server and lwIP tasks.
> 
> While increased stack usage was not a surprise as the CrossWorks 
build used
> the libraries without floating point support (for printf, etc.) 
the size of
> the difference was surprising.  I have not yet analysed the map 
files to see
> where the difference is occurring.
> 
> Regards,
> Richard.
> 
> 
> http://www.FreeRTOS.org
>

I am in no danger of running out of memory on the LPC2106 even if I 
add FreeRTOS and my CF/MP3 stuff.

Worst case: HTTP needs D244h (including library), FreeRTOS (from the 
LPC2106 demo) needs 578Ch and CF/MP3 needs 46D8h for a total of 
170A8h.  There is certainly some common code that will reduce the 
total size.

In reviewing the design, I may not have to move to the larger 
LPC2138 or LPC2148 to get additional pins.  I don't need very much 
RAM so even if I do make the move for pins, I will still be ok.

If I use Telnet instead of HTTP, the library requirement drops way 
down and the telnet application (only) takes 5E34h bytes (24116) 
reducing the code space by around 29000 bytes.

Funny thing: the entire CP/M operating system only took about 8K 
including the BIOS and some of that (the console command processor) 
could be overlayed.

The very powerful macro assembler only needs 32k and the PL/I 
compiler will run on a 64k machine.

I like to older machines!

Richard

> Have you tried gcc with Eclipse as an IDE? That puts you 
> right into a driver seat of a BMW.

As soon as I hear Eclipse can support hardware breakpoints into flash
I'll give it a whirl.

Now it may be that the latest ocdremote (which recently was announced
here supports hardware breakpoints from Insight) may also result in
hardware breakpoints from Eclipse also (eg. Code single step). Can an
Eclipse user verify this ?

My code is simply too large to debug from RAM, and moving individual
modules into RAM one by one as needed is not something I'm prepared to
do in a object modular system. 

In other words...I need a 4WD because the BMW gets stuck as soon as I
take it off-ram :)

Cheers,
Bruce

rtstofer wrote:

>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>  
>
>>rtstofer wrote:
>>
>>    
>>
>>>--- In lpc2000@yahoogroups.com, "lpcarmed" <lpcarmed@g...> wrote:
>>> 
>>>
>>>      
>>>
>>>>Have you tried gcc with Eclipse as an IDE? That puts you right 
>>>>        
>>>>
>into a
>  
>
>>>>driver seat of a BMW.
>>>>   
>>>>
>>>>        
>>>>
>>>I am using that setup and it works well.  However, I haven't 
>>>      
>>>
>really 
>  
>
>>>come to love OCD Remote and Insight.  Besides, I don't have 
>>>      
>>>
>enough 
>  
>
>>>pins to give away just to use jtag.
>>>
>>>Eventually I need to find out how to cut back on the library 
>>>      
>>>
>code - it 
>  
>
>>>is GIGANTIC.
>>>
>>> 
>>>
>>>      
>>>
>>What library are you using?  I'm using NewLib and it seems to be 
>>reasonable in size.  Of course, I stay away from stuff like sprintf
>>    
>>
>(), 
>  
>
>>sscanf() and use itoa() + my own atoi() routines..  Sometimes you 
>>    
>>
>just 
>  
>
>>gotta write your own stuff, heh.  ;-)
>>
>>TomW
>>    
>>
>
>As far as I know, I am using newlib.  However, the uIP web server 
>application uses vsprintf and that pulls in a LOT of library code.  
>The entire network project seems to take about 23k (0000h - 5887h) 
>and the library adds nearly another 32K (5888h - D244h).
>
>After reading the promo stuff about uIP, I thought the stack would 
>be on the small side.  When I got the web server running (without 
>FreeRTOS), it takes 60444 bytes including the .rodata.  HUGE!
>
>Maybe I am bringing in too many libraries but it seemed right at the 
>time:
>
>ARCHIVE1= "C:/Program Files/GNUARM/lib/gcc/arm-elf/3.4.3"
>ARCHIVE2= "C:/Program Files/GNUARM/arm-elf/lib"
>LIBFLAGS= -L${ARCHIVE2} -lc -lg -L$(ARCHIVE1) -lgcc 
>
>Anyway, I now want to integrate FreeRTOS (I think) and add my 
>FAT32/CF drivers and my MP3 stuff.  The objective is a simple 
>networkable MP3 player for special effects.  I will probably change 
>from httpd to telnetd so I can just open a connection and send a 
>command to play a file.
>
>But FreeRTOS will require a lot of thought.  I have to share things 
>like the 8 bit data bus, 4 bit addr bus, chip select and RD/WR 
>signals.  No one process can just own them.  And, I can't have 
>buffer underrun for the MP3 chip.  It would be even more interesting 
>if I stored the MP3 files on an nfs server but I already have a 
>Linux board doing that - see www.gumstix.com using the gumstix, 
>cfstix and audiostix.  It works but it is price prohibitive for 
>Halloween effects.  I need about 6 of these gadgets.
>
>If I have messed up on the libraries, please let me know!
>
>  
>

I built my newlib with some Makefile options that I edited in after the 
configure:


CFLAGS_FOR_TARGET = -O2 $(CFLAGS) -DREENTRANT_SYSCALLS_PROVIDED 
-DINTEGER_ONLY -DPREFER_SIZE_OVER_SPEED

The build was done from a script:

===============  03makeNewLib.sh ====================
*#!/bin/sh
if [ "$TARGET" == "" ] ;  then echo "You need to set the environment 
first!" ; exit ; fi
cd newlib_build
../newlib_sources/configure --target=$TARGET --prefix=$PREFIX
zcat ../downloads/newlib_makefile_patch.gz | patch -p0
make all install 2>&1 | tee make.log
cd ..
*==================== snip ========================

the patch file is:

==============  newlib_makefile_patch.gz =================
*--- Makefile.orig       2005-10-15 16:08:26.000000000 -0400
+++ Makefile    2005-10-15 16:08:38.000000000 -0400
@@ -388,7 +388,7 @@
 # CFLAGS will be just -g.  We want to ensure that TARGET libraries
 # (which we know are built with gcc) are built with optimizations so
 # prepend -O2 when setting CFLAGS_FOR_TARGET.
-CFLAGS_FOR_TARGET = -O2 $(CFLAGS)
+CFLAGS_FOR_TARGET = -O2 $(CFLAGS) -DREENTRANT_SYSCALLS_PROVIDED 
-DINTEGER_ONLY -DPREFER_SIZE_OVER_SPEED
 # If GCC_FOR_TARGET is not overriden on the command line, then this
 # variable is passed down to the gcc Makefile, where it is used to
 # build libgcc2.a.  We define it here so that it can itself be
*================ snip ===========================

This may work for you, or it may disable things that you need (like 
sscanf, sprintf, etc).

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




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

Alex, 

> b> Just one data point, but: I'm a professional developer (30 
> years s/w 
> b> development experience from micros to mainframes).  Now working on 
> b> third LPC-based commercial product.  Compared Keil, IAR, 
> and gcc and 
> b> chose Rowley Crossworks (gcc-based).
> 
> Oh, I can't hold out from the reply.
> I tried to use Crossworks in the begining to explore LPC2xxx.
> It ugly work with the structures. I tried to define T0MCR like
>  struct:
> {{
> typedef struct
>   { 
>     __REG32 MR0I :1;
>     __REG32 MR0R :1;
>     __REG32 MR0S :1;
> 
>     __REG32 MR1I :1;
>     __REG32 MR1R :1;
>     __REG32 MR1S :1;
>     
>     __REG32 MR2I :1;
>     __REG32 MR2R :1;
>     __REG32 MR2S :1;
>     
>     __REG32 MR3I :1;
>     __REG32 MR3R :1;
>     __REG32 MR3S :1;    
>     __REG32      :4;    
> } __txmcr_bits;
> 
> #define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
> 
> }}
> 
> but when I handle to it, Crossworks GCC compile it to this code:
> 
> <<T0MCRbits.MR0I = 1;>>
> 
> mov r3, #0xE0000000
> add r3, r3, #0x00004000
> add r3, r3, #0x00000014
> ldrb r2, [r3]
> orr r2, r2, #0x00000001
> strb r2, [r3]
> 
> so, I get change in LSB and _in_the_second_byte_!.

And you tell me *why* this is incorrect code generation?  You might not
like what is generated, but is is *not* incorrect according to the
standard.  It is only incorrect *if* you think volatile has some extra
meaning above what it does in the standard.  Or *if* you think an
"unsigned long" bitfield is somehow "standard".  That is why the
Embedded C TR has I/O support.  Volatile does *not* mean "I'm dealing
with a device" or "Access this data atomically".  Far from it.

> OK, forget about structures.
> But when I try to compile code with some IRQ, I found, that 
> optimize level has affect on the code! The code works differ 
> with optimize level 1 and optimize level 3!
> After that I found that interrupt context keeped incorrectly. 
> So I had to keep context by ASM macros.

In the next release of CrossWorks, we have a revamp of the way
interrupts are handled across processors.  This will make working with
the device library very attractive.

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Alex_Rambler wrote:

>b> Just one data point, but: I'm a professional developer (30 years s/w
>b> development experience from micros to mainframes).  Now working on 
>b> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
>b> chose Rowley Crossworks (gcc-based).
>
>Oh, I can't hold out from the reply.
>I tried to use Crossworks in the begining to explore LPC2xxx.
>It ugly work with the structures. I tried to define T0MCR like
> struct:
>{{
>typedef struct
>  { 
>    __REG32 MR0I :1;
>    __REG32 MR0R :1;
>    __REG32 MR0S :1;
>
>    __REG32 MR1I :1;
>    __REG32 MR1R :1;
>    __REG32 MR1S :1;
>    
>    __REG32 MR2I :1;
>    __REG32 MR2R :1;
>    __REG32 MR2S :1;
>    
>    __REG32 MR3I :1;
>    __REG32 MR3R :1;
>    __REG32 MR3S :1;    
>    __REG32      :4;    
>} __txmcr_bits;
>
>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>
>}}
>
>but when I handle to it, Crossworks GCC compile it to this code:
>
><<T0MCRbits.MR0I = 1;>>
>
>mov r3, #0xE0000000
>add r3, r3, #0x00004000
>add r3, r3, #0x00000014
>ldrb r2, [r3]
>orr r2, r2, #0x00000001
>strb r2, [r3]
>
>so, I get change in LSB and _in_the_second_byte_!.
>
>  
>
Huh?  I only see the LSB getting changed, where do you see a second byte 
involved??

_ldrb_ and _strb_ are byte operations, not word ops.

You got what you said in the typedef, assignment of address to the 
structure, and the the bit being set in T1MCR.  What is your problem???  
As I read the code, nothing looks out of place, it all makes sense...


TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Alex_Rambler wrote:

>b> Just one data point, but: I'm a professional developer (30 years s/w
>b> development experience from micros to mainframes).  Now working on 
>b> third LPC-based commercial product.  Compared Keil, IAR, and gcc and 
>b> chose Rowley Crossworks (gcc-based).
>
>Oh, I can't hold out from the reply.
>I tried to use Crossworks in the begining to explore LPC2xxx.
>It ugly work with the structures. I tried to define T0MCR like
> struct:
>{{
>typedef struct
>  { 
>    __REG32 MR0I :1;
>    __REG32 MR0R :1;
>    __REG32 MR0S :1;
>
>    __REG32 MR1I :1;
>    __REG32 MR1R :1;
>    __REG32 MR1S :1;
>    
>    __REG32 MR2I :1;
>    __REG32 MR2R :1;
>    __REG32 MR2S :1;
>    
>    __REG32 MR3I :1;
>    __REG32 MR3R :1;
>    __REG32 MR3S :1;    
>    __REG32      :4;    
>} __txmcr_bits;
>
>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>
>}}
>
>  
>
The only thing I am curious about is why you bounded your struct def 
inside a double code block?

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

That the first bit of the second byte also changed is very possible. 
This is de to the processor. The timer register should be handled in 
a 32 bit access. this is what i found out. so instead of these kind 
of structures i just handle them in 32-bit. this way it is also 
quicker, you can change all values at the same time.

is this really the fault of the compiler?????

BTW using rowley and being very happy with it.

Joost van Eenbergen
ELC lighting

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> Alex_Rambler wrote:
> 
> >b> Just one data point, but: I'm a professional developer (30 
years s/w
> >b> development experience from micros to mainframes).  Now 
working on 
> >b> third LPC-based commercial product.  Compared Keil, IAR, and 
gcc and 
> >b> chose Rowley Crossworks (gcc-based).
> >
> >Oh, I can't hold out from the reply.
> >I tried to use Crossworks in the begining to explore LPC2xxx.
> >It ugly work with the structures. I tried to define T0MCR like
> > struct:
> >{{
> >typedef struct
> >  { 
> >    __REG32 MR0I :1;
> >    __REG32 MR0R :1;
> >    __REG32 MR0S :1;
> >
> >    __REG32 MR1I :1;
> >    __REG32 MR1R :1;
> >    __REG32 MR1S :1;
> >    
> >    __REG32 MR2I :1;
> >    __REG32 MR2R :1;
> >    __REG32 MR2S :1;
> >    
> >    __REG32 MR3I :1;
> >    __REG32 MR3R :1;
> >    __REG32 MR3S :1;    
> >    __REG32      :4;    
> >} __txmcr_bits;
> >
> >#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
> >
> >}}
> >
> >but when I handle to it, Crossworks GCC compile it to this code:
> >
> ><<T0MCRbits.MR0I = 1;>>
> >
> >mov r3, #0xE0000000
> >add r3, r3, #0x00004000
> >add r3, r3, #0x00000014
> >ldrb r2, [r3]
> >orr r2, r2, #0x00000001
> >strb r2, [r3]
> >
> >so, I get change in LSB and _in_the_second_byte_!.
> >
> >  
> >
> Huh?  I only see the LSB getting changed, where do you see a 
second byte 
> involved??
> 
> _ldrb_ and _strb_ are byte operations, not word ops.
> 
> You got what you said in the typedef, assignment of address to the 
> structure, and the the bit being set in T1MCR.  What is your 
problem???  
> As I read the code, nothing looks out of place, it all makes 
sense...

> 
> 
> TomW
> 
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

Yes, I mean exactly this!! Crossworks GCC compiler works with bit 
fields of structures using byte instructions. So if you access to the 
VICIntSelect (if it defined like struct) you can even fall out to the 
Data Abort.
And it not Philips feature, it's ARM feature (data access), am I 
right?

As against, IAR, Keil work with the bit fields of struct relatively to 
it (struct) absolute size (used byte or word instructions).

> That the first bit of the second byte also changed is very possible. 
> This is de to the processor. The timer register should be handled in 
> a 32 bit access. this is what i found out. so instead of these kind 
> of structures i just handle them in 32-bit. this way it is also 
> quicker, you can change all values at the same time.
> 
> is this really the fault of the compiler?????
> 
> BTW using rowley and being very happy with it.
> 
> Joost van Eenbergen
> ELC lighting
> 
> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>>
>> Alex_Rambler wrote:
>> 
>> >b> Just one data point, but: I'm a professional developer (30 
> years s/w
>> >b> development experience from micros to mainframes).  Now 
> working on 
>> >b> third LPC-based commercial product.  Compared Keil, IAR, and 
> gcc and 
>> >b> chose Rowley Crossworks (gcc-based).
>> >
>> >Oh, I can't hold out from the reply.
>> >I tried to use Crossworks in the begining to explore LPC2xxx.
>> >It ugly work with the structures. I tried to define T0MCR like
>> > struct:
>> >{{
>> >typedef struct
>> >  { 
>> >    __REG32 MR0I :1;
>> >    __REG32 MR0R :1;
>> >    __REG32 MR0S :1;
>> >
>> >    __REG32 MR1I :1;
>> >    __REG32 MR1R :1;
>> >    __REG32 MR1S :1;
>> >    
>> >    __REG32 MR2I :1;
>> >    __REG32 MR2R :1;
>> >    __REG32 MR2S :1;
>> >    
>> >    __REG32 MR3I :1;
>> >    __REG32 MR3R :1;
>> >    __REG32 MR3S :1;    
>> >    __REG32      :4;    
>> >} __txmcr_bits;
>> >
>> >#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>> >
>> >}}
>> >
>> >but when I handle to it, Crossworks GCC compile it to this code:
>> >
>> ><<T0MCRbits.MR0I = 1;>>
>> >
>> >mov r3, #0xE0000000
>> >add r3, r3, #0x00004000
>> >add r3, r3, #0x00000014
>> >ldrb r2, [r3]
>> >orr r2, r2, #0x00000001
>> >strb r2, [r3]
>> >
>> >so, I get change in LSB and _in_the_second_byte_!.
>> >
>> >  
>> >
>> Huh?  I only see the LSB getting changed, where do you see a 
> second byte 
>> involved??
>> 
>> _ldrb_ and _strb_ are byte operations, not word ops.
>> 
>> You got what you said in the typedef, assignment of address to the 
>> structure, and the the bit being set in T1MCR.  What is your 
> problem???  
>> As I read the code, nothing looks out of place, it all makes 
> sense...
>> 
>> 
>> TomW
>> 
>> 
>> 
>> -- 
>> Tom Walsh - WN3L - Embedded Systems Consultant
>> http://openhardware.net, http://cyberiansoftware.com
>> "Windows? No thanks, I have work to do..."
>> ----------------------------------------------------
>>
> 
> 
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
>

On Mon, 07 Nov 2005 21:05:46 -0500
  Tom Walsh <tom@...> wrote:
> Alex_Rambler wrote:
> 
>>b> Just one data point, but: I'm a professional developer (30 years 
>>s/w
>>b> development experience from micros to mainframes).  Now working on 
>>b> third LPC-based commercial product.  Compared Keil, IAR, and gcc 
>>and 
>>b> chose Rowley Crossworks (gcc-based).
>>
>>Oh, I can't hold out from the reply.
>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>It ugly work with the structures. I tried to define T0MCR like
>> struct:
>>{{
>>typedef struct
>>  { 
>>    __REG32 MR0I :1;
>>    __REG32 MR0R :1;
>>    __REG32 MR0S :1;
>>
>>    __REG32 MR1I :1;
>>    __REG32 MR1R :1;
>>    __REG32 MR1S :1;
>>    
>>    __REG32 MR2I :1;
>>    __REG32 MR2R :1;
>>    __REG32 MR2S :1;
>>    
>>    __REG32 MR3I :1;
>>    __REG32 MR3R :1;
>>    __REG32 MR3S :1;    
>>    __REG32      :4;    
>>} __txmcr_bits;
>>
>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>
>>}}
>>
>>  
>>
> The only thing I am curious about is why you bounded your struct def 
> inside a double code block?
> 
> TomW
> 
It's only for code separation in this mail :-)

> Alex, 
> 
>> b> Just one data point, but: I'm a professional developer (30 
>> years s/w 
>> b> development experience from micros to mainframes).  Now working 
>>on 
>> b> third LPC-based commercial product.  Compared Keil, IAR, 
>> and gcc and 
>> b> chose Rowley Crossworks (gcc-based).
>> 
>> Oh, I can't hold out from the reply.
>> I tried to use Crossworks in the begining to explore LPC2xxx.
>> It ugly work with the structures. I tried to define T0MCR like
>>  struct:
>> {{
>> typedef struct
>>   { 
>>     __REG32 MR0I :1;
>>     __REG32 MR0R :1;
>>     __REG32 MR0S :1;
>> 
>>     __REG32 MR1I :1;
>>     __REG32 MR1R :1;
>>     __REG32 MR1S :1;
>>     
>>     __REG32 MR2I :1;
>>     __REG32 MR2R :1;
>>     __REG32 MR2S :1;
>>     
>>     __REG32 MR3I :1;
>>     __REG32 MR3R :1;
>>     __REG32 MR3S :1;    
>>     __REG32      :4;    
>> } __txmcr_bits;
>> 
>> #define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>> 
>> }}
>> 
>> but when I handle to it, Crossworks GCC compile it to this code:
>> 
>> <<T0MCRbits.MR0I = 1;>>
>> 
>> mov r3, #0xE0000000
>> add r3, r3, #0x00004000
>> add r3, r3, #0x00000014
>> ldrb r2, [r3]
>> orr r2, r2, #0x00000001
>> strb r2, [r3]
>> 
>> so, I get change in LSB and _in_the_second_byte_!.
> 
> And you tell me *why* this is incorrect code generation?  You might 
>not
> like what is generated, but is is *not* incorrect according to the
> standard.  It is only incorrect *if* you think volatile has some 
>extra
> meaning above what it does in the standard.  Or *if* you think an
> "unsigned long" bitfield is somehow "standard".  That is why the
> Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>dealing
> with a device" or "Access this data atomically".  Far from it.

I tried to explain my point of view in other mail.
The generated code works incorrectly because it use BYTE instructions. 
You can compile it, load into the chip and debug. We discuss compiler 
for ARM core, or what? I think IAR, Keil compilers know about data 
access in the ARM core.

>> OK, forget about structures.
>> But when I try to compile code with some IRQ, I found, that 
>> optimize level has affect on the code! The code works differ 
>> with optimize level 1 and optimize level 3!
>> After that I found that interrupt context keeped incorrectly. 
>> So I had to keep context by ASM macros.
> 
> In the next release of CrossWorks, we have a revamp of the way
> interrupts are handled across processors.  This will make working 
>with
> the device library very attractive.

It's good news.
Please understand, I like Crossworks IDE, it's the best IDE that I 
used. But compiler...

> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Alex,

> >> b> Just one data point, but: I'm a professional developer (30 
> >> years s/w 
> >> b> development experience from micros to mainframes).  Now working 
> >>on 
> >> b> third LPC-based commercial product.  Compared Keil, IAR, 
> >> and gcc and 
> >> b> chose Rowley Crossworks (gcc-based).
> >> 
> >> Oh, I can't hold out from the reply.
> >> I tried to use Crossworks in the begining to explore LPC2xxx.
> >> It ugly work with the structures. I tried to define T0MCR like
> >>  struct:
> >> {{
> >> typedef struct
> >>   { 
> >>     __REG32 MR0I :1;
> >>     __REG32 MR0R :1;
> >>     __REG32 MR0S :1;
> >> 
> >>     __REG32 MR1I :1;
> >>     __REG32 MR1R :1;
> >>     __REG32 MR1S :1;
> >>     
> >>     __REG32 MR2I :1;
> >>     __REG32 MR2R :1;
> >>     __REG32 MR2S :1;
> >>     
> >>     __REG32 MR3I :1;
> >>     __REG32 MR3R :1;
> >>     __REG32 MR3S :1;    
> >>     __REG32      :4;    
> >> } __txmcr_bits;
> >> 
> >> #define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
> >> 
> >> }}
> >> 
> >> but when I handle to it, Crossworks GCC compile it to this code:
> >> 
> >> <<T0MCRbits.MR0I = 1;>>
> >> 
> >> mov r3, #0xE0000000
> >> add r3, r3, #0x00004000
> >> add r3, r3, #0x00000014
> >> ldrb r2, [r3]
> >> orr r2, r2, #0x00000001
> >> strb r2, [r3]
> >> 
> >> so, I get change in LSB and _in_the_second_byte_!.
> > 
> > And you tell me *why* this is incorrect code generation?  You might 
> >not
> > like what is generated, but is is *not* incorrect according to the
> > standard.  It is only incorrect *if* you think volatile has some 
> >extra
> > meaning above what it does in the standard.  Or *if* you think an
> > "unsigned long" bitfield is somehow "standard".  That is why the
> > Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
> >dealing
> > with a device" or "Access this data atomically".  Far from it.
> 
> I tried to explain my point of view in other mail.
> The generated code works incorrectly because it use BYTE 
> instructions. 

So what?  It might not be what you want, but it is not incorrect
according to the ISO standard.

> You can compile it, load into the chip and debug. We discuss compiler 
> for ARM core, or what? I think IAR, Keil compilers know about data 
> access in the ARM core.

Sure, GCC knows about alignment.  But you are now using bitfields which
are a completely different kettle of fish and mixing in volatile to try
to do something which is not possible to describe in *standard* ANSI C.
If you can point me to a paragraph or clause in the ISO standard that
says my interpretetation is incorrect or yours is correct that's good,
we can make some progress.  Supposition isn't any use.  As I said, the
generated code might be as useful as a box of chocolate frogs and seen
to be incorrect from one viewpoint, but it does not violate the ANSI/ISO
standard, so is correct from another viewpoint.

> >> OK, forget about structures.
> >> But when I try to compile code with some IRQ, I found, that 
> >> optimize level has affect on the code! The code works differ 
> >> with optimize level 1 and optimize level 3!
> >> After that I found that interrupt context keeped incorrectly. 
> >> So I had to keep context by ASM macros.
> > 
> > In the next release of CrossWorks, we have a revamp of the way
> > interrupts are handled across processors.  This will make working 
> >with
> > the device library very attractive.
> 
> It's good news.
> Please understand, I like Crossworks IDE, it's the best IDE that I 
> used. But compiler...

Sure, I understand about the compiler.  That might change.

-- Paul.

\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd wrote:

>>Alex, 
>>
>>    
>>
>>>b> Just one data point, but: I'm a professional developer (30 
>>>years s/w 
>>>b> development experience from micros to mainframes).  Now working 
>>>on 
>>>b> third LPC-based commercial product.  Compared Keil, IAR, 
>>>and gcc and 
>>>b> chose Rowley Crossworks (gcc-based).
>>>
>>>Oh, I can't hold out from the reply.
>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>It ugly work with the structures. I tried to define T0MCR like
>>> struct:
>>>{{
>>>typedef struct
>>>  { 
>>>    __REG32 MR0I :1;
>>>    __REG32 MR0R :1;
>>>    __REG32 MR0S :1;
>>>
>>>    __REG32 MR1I :1;
>>>    __REG32 MR1R :1;
>>>    __REG32 MR1S :1;
>>>    
>>>    __REG32 MR2I :1;
>>>    __REG32 MR2R :1;
>>>    __REG32 MR2S :1;
>>>    
>>>    __REG32 MR3I :1;
>>>    __REG32 MR3R :1;
>>>    __REG32 MR3S :1;    
>>>    __REG32      :4;    
>>>} __txmcr_bits;
>>>
>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>
>>>}}
>>>
>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>
>>><<T0MCRbits.MR0I = 1;>>
>>>
>>>mov r3, #0xE0000000
>>>add r3, r3, #0x00004000
>>>add r3, r3, #0x00000014
>>>ldrb r2, [r3]
>>>orr r2, r2, #0x00000001
>>>strb r2, [r3]
>>>
>>>so, I get change in LSB and _in_the_second_byte_!.
>>>      
>>>
>>And you tell me *why* this is incorrect code generation?  You might 
>>not
>>like what is generated, but is is *not* incorrect according to the
>>standard.  It is only incorrect *if* you think volatile has some 
>>extra
>>meaning above what it does in the standard.  Or *if* you think an
>>"unsigned long" bitfield is somehow "standard".  That is why the
>>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>>dealing
>>with a device" or "Access this data atomically".  Far from it.
>>    
>>
>
>I tried to explain my point of view in other mail.
>The generated code works incorrectly because it use BYTE instructions. 
>You can compile it, load into the chip and debug. We discuss compiler 
>for ARM core, or what? I think IAR, Keil compilers know about data 
>access in the ARM core.
>
>  
>
You are very very confused...  You have absolutely no idea what "__REG32 
MR0I :1" means, do you???  It is obvious that you are operating under 
some other understanding of just what it is that you wrote.

Go have someone explain it to you, it would take too long to do here.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd wrote:
>>Alex, 
>>
>>
>>>b> Just one data point, but: I'm a professional developer (30 
>>>years s/w 
>>>b> development experience from micros to mainframes).  Now working 
>>>on 
>>>b> third LPC-based commercial product.  Compared Keil, IAR, 
>>>and gcc and 
>>>b> chose Rowley Crossworks (gcc-based).
>>>
>>>Oh, I can't hold out from the reply.
>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>It ugly work with the structures. I tried to define T0MCR like
>>> struct:
>>>{{
>>>typedef struct
>>>  { 
>>>    __REG32 MR0I :1;
>>>    __REG32 MR0R :1;
>>>    __REG32 MR0S :1;
>>>
>>>    __REG32 MR1I :1;
>>>    __REG32 MR1R :1;
>>>    __REG32 MR1S :1;
>>>    
>>>    __REG32 MR2I :1;
>>>    __REG32 MR2R :1;
>>>    __REG32 MR2S :1;
>>>    
>>>    __REG32 MR3I :1;
>>>    __REG32 MR3R :1;
>>>    __REG32 MR3S :1;    
>>>    __REG32      :4;    
>>>} __txmcr_bits;
>>>
>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>
>>>}}
>>>
>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>
>>><<T0MCRbits.MR0I = 1;>>
>>>
>>>mov r3, #0xE0000000
>>>add r3, r3, #0x00004000
>>>add r3, r3, #0x00000014
>>>ldrb r2, [r3]
>>>orr r2, r2, #0x00000001
>>>strb r2, [r3]
>>>
>>>so, I get change in LSB and _in_the_second_byte_!.
>>
>>And you tell me *why* this is incorrect code generation?  You might 
>>not
>>like what is generated, but is is *not* incorrect according to the
>>standard.  It is only incorrect *if* you think volatile has some 
>>extra
>>meaning above what it does in the standard.  Or *if* you think an
>>"unsigned long" bitfield is somehow "standard".  That is why the
>>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>>dealing
>>with a device" or "Access this data atomically".  Far from it.
> 
> 
> I tried to explain my point of view in other mail.
> The generated code works incorrectly because it use BYTE instructions. 
> You can compile it, load into the chip and debug. We discuss compiler 
> for ARM core, or what? I think IAR, Keil compilers know about data 
> access in the ARM core.
> 

This behaviour is not bug, it's really a feature. GCC is optimizing the
accesss to this bit-field to a minimum. Loading and storing only _one_
byte for modifing only _one_ bit is a very good optimization on designs
with external memory, which is not 32bit wide, to minimize memory access
cycles. GCC doesn't know that a certain register _must_ be accessed with
32bit (with or without "volatile") and C standard does not say that a
bit field manipulation is forced to be a 16bit or 32bit access. What
should happen, in your opinion, if you declare a bit field with more
than 32 bit??? How should it be handled?
With other words: Compiler which are using a 32bit access for such a bit
field manipulation lacks an optimization feature!!!

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/

????????? ??????? wrote:

>On Mon, 07 Nov 2005 21:05:46 -0500
>  Tom Walsh <tom@...> wrote:
>  
>
>>Alex_Rambler wrote:
>>
>>    
>>
>>>b> Just one data point, but: I'm a professional developer (30 years 
>>>s/w
>>>b> development experience from micros to mainframes).  Now working on 
>>>b> third LPC-based commercial product.  Compared Keil, IAR, and gcc 
>>>and 
>>>b> chose Rowley Crossworks (gcc-based).
>>>
>>>Oh, I can't hold out from the reply.
>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>It ugly work with the structures. I tried to define T0MCR like
>>>struct:
>>>{{
>>>typedef struct
>>> { 
>>>   __REG32 MR0I :1;
>>>   __REG32 MR0R :1;
>>>   __REG32 MR0S :1;
>>>
>>>   __REG32 MR1I :1;
>>>   __REG32 MR1R :1;
>>>   __REG32 MR1S :1;
>>>   
>>>   __REG32 MR2I :1;
>>>   __REG32 MR2R :1;
>>>   __REG32 MR2S :1;
>>>   
>>>   __REG32 MR3I :1;
>>>   __REG32 MR3R :1;
>>>   __REG32 MR3S :1;    
>>>   __REG32      :4;    
>>>} __txmcr_bits;
>>>
>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>
>>>}}
>>>
>>> 
>>>
>>>      
>>>
>>The only thing I am curious about is why you bounded your struct def 
>>inside a double code block?
>>
>>TomW
>>
>>    
>>
>It's only for code separation in this mail :-)
>
>  
>
Oh, well, convention has been to use a string of '=',  a string of 
dashes '-' has a meaning for some mail clients.  The braces also confuse 
things as they are a non-neutral character (code block).  The '=' sign 
has been pretty much used over the years to bound code examples, usually 
like this:

========= mycode.c ============
blah
blah
...
========== snip ==============

You may notice the effect that the '--' double dash does to the font of 
the signature below?  That is also another convention, '--' on a line by 
itself denotes "signature to follow".


TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

vaneenbergen wrote:

>That the first bit of the second byte also changed is very possible. 
>This is de to the processor. The timer register should be handled in 
>a 32 bit access. this is what i found out. so instead of these kind 
>of structures i just handle them in 32-bit. this way it is also 
>quicker, you can change all values at the same time.
>
>is this really the fault of the compiler?????
>  
>
He didn't understand what it was that he wrote so how can he answer that 
question?


TomW





>BTW using rowley and being very happy with it.
>
>Joost van Eenbergen
>ELC lighting
>
>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>  
>
>>Alex_Rambler wrote:
>>
>>    
>>
>>>b> Just one data point, but: I'm a professional developer (30 
>>>      
>>>
>years s/w
>  
>
>>>b> development experience from micros to mainframes).  Now 
>>>      
>>>
>working on 
>  
>
>>>b> third LPC-based commercial product.  Compared Keil, IAR, and 
>>>      
>>>
>gcc and 
>  
>
>>>b> chose Rowley Crossworks (gcc-based).
>>>
>>>Oh, I can't hold out from the reply.
>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>It ugly work with the structures. I tried to define T0MCR like
>>>struct:
>>>{{
>>>typedef struct
>>> { 
>>>   __REG32 MR0I :1;
>>>   __REG32 MR0R :1;
>>>   __REG32 MR0S :1;
>>>
>>>   __REG32 MR1I :1;
>>>   __REG32 MR1R :1;
>>>   __REG32 MR1S :1;
>>>   
>>>   __REG32 MR2I :1;
>>>   __REG32 MR2R :1;
>>>   __REG32 MR2S :1;
>>>   
>>>   __REG32 MR3I :1;
>>>   __REG32 MR3R :1;
>>>   __REG32 MR3S :1;    
>>>   __REG32      :4;    
>>>} __txmcr_bits;
>>>
>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>
>>>}}
>>>
>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>
>>><<T0MCRbits.MR0I = 1;>>
>>>
>>>mov r3, #0xE0000000
>>>add r3, r3, #0x00004000
>>>add r3, r3, #0x00000014
>>>ldrb r2, [r3]
>>>orr r2, r2, #0x00000001
>>>strb r2, [r3]
>>>
>>>so, I get change in LSB and _in_the_second_byte_!.
>>>
>>> 
>>>
>>>      
>>>
>>Huh?  I only see the LSB getting changed, where do you see a 
>>    
>>
>second byte 
>  
>
>>involved??
>>
>>_ldrb_ and _strb_ are byte operations, not word ops.
>>
>>You got what you said in the typedef, assignment of address to the 
>>structure, and the the bit being set in T1MCR.  What is your 
>>    
>>
>problem???  
>  
>
>>As I read the code, nothing looks out of place, it all makes 
>>    
>>
>sense...
>  
>
>>TomW
>>
>>
>>
>>-- 
>>Tom Walsh - WN3L - Embedded Systems Consultant
>>http://openhardware.net, http://cyberiansoftware.com
>>"Windows? No thanks, I have work to do..."
>>----------------------------------------------------
>>
>>    
>>
>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Tom

> You may notice the effect that the '--' double dash does to the font of
> the signature below?  That is also another convention, '--' on a line by
> itself denotes "signature to follow".

Slight correction (I've been corrected before myself):
"-- " openes the signature not "--"
    ^ SPACE

-- 
42Bastian Schick

On Tue, 8 Nov 2005 09:08:29 -0000
  "Paul Curtis" <plc@...> wrote:
> Alex,
> 
>> >> b> Just one data point, but: I'm a professional developer (30 
>> >> years s/w 
>> >> b> development experience from micros to mainframes).  Now 
>>working 
>> >>on 
>> >> b> third LPC-based commercial product.  Compared Keil, IAR, 
>> >> and gcc and 
>> >> b> chose Rowley Crossworks (gcc-based).
>> >> 
>> >> Oh, I can't hold out from the reply.
>> >> I tried to use Crossworks in the begining to explore LPC2xxx.
>> >> It ugly work with the structures. I tried to define T0MCR like
>> >>  struct:
>> >> {{
>> >> typedef struct
>> >>   { 
>> >>     __REG32 MR0I :1;
>> >>     __REG32 MR0R :1;
>> >>     __REG32 MR0S :1;
>> >> 
>> >>     __REG32 MR1I :1;
>> >>     __REG32 MR1R :1;
>> >>     __REG32 MR1S :1;
>> >>     
>> >>     __REG32 MR2I :1;
>> >>     __REG32 MR2R :1;
>> >>     __REG32 MR2S :1;
>> >>     
>> >>     __REG32 MR3I :1;
>> >>     __REG32 MR3R :1;
>> >>     __REG32 MR3S :1;    
>> >>     __REG32      :4;    
>> >> } __txmcr_bits;
>> >> 
>> >> #define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>> >> 
>> >> }}
>> >> 
>> >> but when I handle to it, Crossworks GCC compile it to this code:
>> >> 
>> >> <<T0MCRbits.MR0I = 1;>>
>> >> 
>> >> mov r3, #0xE0000000
>> >> add r3, r3, #0x00004000
>> >> add r3, r3, #0x00000014
>> >> ldrb r2, [r3]
>> >> orr r2, r2, #0x00000001
>> >> strb r2, [r3]
>> >> 
>> >> so, I get change in LSB and _in_the_second_byte_!.
>> > 
>> > And you tell me *why* this is incorrect code generation?  You 
>>might 
>> >not
>> > like what is generated, but is is *not* incorrect according to the
>> > standard.  It is only incorrect *if* you think volatile has some 
>> >extra
>> > meaning above what it does in the standard.  Or *if* you think an
>> > "unsigned long" bitfield is somehow "standard".  That is why the
>> > Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>> >dealing
>> > with a device" or "Access this data atomically".  Far from it.
>> 
>> I tried to explain my point of view in other mail.
>> The generated code works incorrectly because it use BYTE 
>> instructions. 
> 
> So what?  It might not be what you want, but it is not incorrect
> according to the ISO standard.

We discuss not any abstract ISO C compiler, but 
_C_compiler_for_ARM_core.
So, do you agree, that my _C_code_ correct? My target is to set one 
bit in T0MCR.
I compile it, load, and I see, that _ASM_code_ set TWO BITS (in LBS, 
as I want, and in previous byte). And after that you convince me that 
_ASM_code_ right?
Please don't tell me about ISO, K&R and other, we discuss concrete 
realisation of compiler _for_ARM_core. You can spend a little time to 
check it. This code really set TWO bits. WHY, I answer anoter mail.
I think decision in check of struct absolute size. If it bigger than 
byte - use word ARM ASM instruction, else use byte ARM ASM 
instruction.

>> You can compile it, load into the chip and debug. We discuss 
>>compiler 
>> for ARM core, or what? I think IAR, Keil compilers know about data 
>> access in the ARM core.
> 
> Sure, GCC knows about alignment.  But you are now using bitfields 
>which
> are a completely different kettle of fish and mixing in volatile to 
>try
> to do something which is not possible to describe in *standard* ANSI 
>C.
> If you can point me to a paragraph or clause in the ISO standard 
>that
> says my interpretetation is incorrect or yours is correct that's 
>good,
> we can make some progress.  Supposition isn't any use.  As I said, 
>the
> generated code might be as useful as a box of chocolate frogs and 
>seen
> to be incorrect from one viewpoint, but it does not violate the 
>ANSI/ISO
> standard, so is correct from another viewpoint.
> 
>> >> OK, forget about structures.
>> >> But when I try to compile code with some IRQ, I found, that 
>> >> optimize level has affect on the code! The code works differ 
>> >> with optimize level 1 and optimize level 3!
>> >> After that I found that interrupt context keeped incorrectly. 
>> >> So I had to keep context by ASM macros.
>> > 
>> > In the next release of CrossWorks, we have a revamp of the way
>> > interrupts are handled across processors.  This will make working 
>> >with
>> > the device library very attractive.
>> 
>> It's good news.
>> Please understand, I like Crossworks IDE, it's the best IDE that I 
>> used. But compiler...
> 
> Sure, I understand about the compiler.  That might change.
> 
> -- Paul.
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
>

On Tue, 08 Nov 2005 04:47:49 -0500
  Tom Walsh <tom@...> wrote:
> vaneenbergen wrote:
> 
>>That the first bit of the second byte also changed is very possible. 
>>This is de to the processor. The timer register should be handled in 
>>a 32 bit access. this is what i found out. so instead of these kind 
>>of structures i just handle them in 32-bit. this way it is also 
>>quicker, you can change all values at the same time.
>>
>>is this really the fault of the compiler?????
>>  
>>
> He didn't understand what it was that he wrote so how can he answer 
>that 
> question?
> 
> 
> TomW
> 

What you mean? I think it obviously, that it's really fault of 
compiler. I explain my point of view to Paul

> 
> 
>>BTW using rowley and being very happy with it.
>>
>>Joost van Eenbergen
>>ELC lighting
>>
>>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>>  
>>
>>>Alex_Rambler wrote:
>>>
>>>    
>>>
>>>>b> Just one data point, but: I'm a professional developer (30 
>>>>      
>>>>
>>years s/w
>>  
>>
>>>>b> development experience from micros to mainframes).  Now 
>>>>      
>>>>
>>working on 
>>  
>>
>>>>b> third LPC-based commercial product.  Compared Keil, IAR, and 
>>>>      
>>>>
>>gcc and 
>>  
>>
>>>>b> chose Rowley Crossworks (gcc-based).
>>>>
>>>>Oh, I can't hold out from the reply.
>>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>>It ugly work with the structures. I tried to define T0MCR like
>>>>struct:
>>>>{{
>>>>typedef struct
>>>> { 
>>>>   __REG32 MR0I :1;
>>>>   __REG32 MR0R :1;
>>>>   __REG32 MR0S :1;
>>>>
>>>>   __REG32 MR1I :1;
>>>>   __REG32 MR1R :1;
>>>>   __REG32 MR1S :1;
>>>>   
>>>>   __REG32 MR2I :1;
>>>>   __REG32 MR2R :1;
>>>>   __REG32 MR2S :1;
>>>>   
>>>>   __REG32 MR3I :1;
>>>>   __REG32 MR3R :1;
>>>>   __REG32 MR3S :1;    
>>>>   __REG32      :4;    
>>>>} __txmcr_bits;
>>>>
>>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>>
>>>>}}
>>>>
>>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>>
>>>><<T0MCRbits.MR0I = 1;>>
>>>>
>>>>mov r3, #0xE0000000
>>>>add r3, r3, #0x00004000
>>>>add r3, r3, #0x00000014
>>>>ldrb r2, [r3]
>>>>orr r2, r2, #0x00000001
>>>>strb r2, [r3]
>>>>
>>>>so, I get change in LSB and _in_the_second_byte_!.
>>>>
>>>> 
>>>>
>>>>      
>>>>
>>>Huh?  I only see the LSB getting changed, where do you see a 
>>>    
>>>
>>second byte 
>>  
>>
>>>involved??
>>>
>>>_ldrb_ and _strb_ are byte operations, not word ops.
>>>
>>>You got what you said in the typedef, assignment of address to the 
>>>structure, and the the bit being set in T1MCR.  What is your 
>>>    
>>>
>>problem???  
>>  
>>
>>>As I read the code, nothing looks out of place, it all makes 
>>>    
>>>
>>sense...
>>  
>>
>>>TomW
>>>
>>>
>>>
>>>-- 
>>>Tom Walsh - WN3L - Embedded Systems Consultant
>>>http://openhardware.net, http://cyberiansoftware.com
>>>"Windows? No thanks, I have work to do..."
>>>----------------------------------------------------
>>>
>>>    
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>  
>>
> 
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
>

At the risk of adding yet more controversy to what is getting to be a 
somewhat heated discussion, can I suggest that access to hardware 
registers is best done using something like:

1. Define general MACRO in some hardware-specific include file:

#define REG(addr) (*(volatile unsigned int *)(addr))

1. Define machine registers in some include file:

/* example is I2C control register */

#define I2C_I2CONSET  (0xE001C000) /* ctrl set reg */

3. Use as follows:

REG(I2C_I2CONSET) = 0x44;   /* set I2EN and AA */

As an alternative, you can define extra values as follows:

#define	I2C_BIT_AA   (0x04)
#define	I2C_BIT_SI   (0x08)
#define	I2C_BIT_STO  (0x10)
#define	I2C_BIT_STA  (0x20)
#define	I2C_BIT_I2EN (0x40)

and use as follows:

REG(I2C_I2CONSET) = I2C_BIT_I2EN | I2C_BIT_AA;

This has the advantage of:

- it always works, regardless of compiler, optimisation settings, 
time of day,....
- it's easy to follow (or as easy as any other alternative)
- it's invariably efficiently encoded by the compiler

Contrast this with the number of questions you see on why particular 
bit-field constructs mapped to hardware registers don't work, and it 
might change your mind on how to do this.

Regards
Brendan Murphy

P.S. On the main topic, I've used GCC on and off for maybe ten years 
now. I find it fine for professional development, PROVIDED someone 
else has set it up for the development system being used (we use 
Ashling for LPC2000 developments, which package it nicely with their 
IDE and ICE). It's not worth the time and effort of doing it 
yourself, unless you're into that sort of thing (maybe you should get 
out more if you are?). We don't use any built-in library functions, 
so library size isn't an issue for us. The reason I like it (apart 
from the cost!) is the lack of bugs in the code generation, unlike 
ither commercial compilers I've used. Reasons for not liking it are 
the usual (limited support, overwhelming documentation etc. etc.). 

--- In lpc2000@yahoogroups.com, Sten <list@n...> wrote:
>
> Àëåêñàíäð Áîðèñîâ wrote:
> >>Alex, 
> >>
> >>
> >>>b> Just one data point, but: I'm a professional developer (30 
> >>>years s/w 
> >>>b> development experience from micros to mainframes).  Now 
working 
> >>>on 
> >>>b> third LPC-based commercial product.  Compared Keil, IAR, 
> >>>and gcc and 
> >>>b> chose Rowley Crossworks (gcc-based).
> >>>
> >>>Oh, I can't hold out from the reply.
> >>>I tried to use Crossworks in the begining to explore LPC2xxx.
> >>>It ugly work with the structures. I tried to define T0MCR like
> >>> struct:
> >>>{{
> >>>typedef struct
> >>>  { 
> >>>    __REG32 MR0I :1;
> >>>    __REG32 MR0R :1;
> >>>    __REG32 MR0S :1;
> >>>
> >>>    __REG32 MR1I :1;
> >>>    __REG32 MR1R :1;
> >>>    __REG32 MR1S :1;
> >>>    
> >>>    __REG32 MR2I :1;
> >>>    __REG32 MR2R :1;
> >>>    __REG32 MR2S :1;
> >>>    
> >>>    __REG32 MR3I :1;
> >>>    __REG32 MR3R :1;
> >>>    __REG32 MR3S :1;    
> >>>    __REG32      :4;    
> >>>} __txmcr_bits;
> >>>
> >>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
> >>>
> >>>}}
> >>>
> >>>but when I handle to it, Crossworks GCC compile it to this code:
> >>>
> >>><<T0MCRbits.MR0I = 1;>>
> >>>
> >>>mov r3, #0xE0000000
> >>>add r3, r3, #0x00004000
> >>>add r3, r3, #0x00000014
> >>>ldrb r2, [r3]
> >>>orr r2, r2, #0x00000001
> >>>strb r2, [r3]
> >>>
> >>>so, I get change in LSB and _in_the_second_byte_!.
> >>
> >>And you tell me *why* this is incorrect code generation?  You 
might 
> >>not
> >>like what is generated, but is is *not* incorrect according to the
> >>standard.  It is only incorrect *if* you think volatile has some 
> >>extra
> >>meaning above what it does in the standard.  Or *if* you think an
> >>"unsigned long" bitfield is somehow "standard".  That is why the
> >>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
> >>dealing
> >>with a device" or "Access this data atomically".  Far from it.
> > 
> > 
> > I tried to explain my point of view in other mail.
> > The generated code works incorrectly because it use BYTE 
instructions. 
> > You can compile it, load into the chip and debug. We discuss 
compiler 
> > for ARM core, or what? I think IAR, Keil compilers know about 
data 
> > access in the ARM core.
> > 
> 
> This behaviour is not bug, it's really a feature. GCC is optimizing 
the
> accesss to this bit-field to a minimum. Loading and storing only 
_one_
> byte for modifing only _one_ bit is a very good optimization on 
designs
> with external memory, which is not 32bit wide, to minimize memory 
access
> cycles. GCC doesn't know that a certain register _must_ be accessed 
with
> 32bit (with or without "volatile") and C standard does not say that 
a
> bit field manipulation is forced to be a 16bit or 32bit access. What
> should happen, in your opinion, if you declare a bit field with more
> than 32 bit??? How should it be handled?
> With other words: Compiler which are using a 32bit access for such 
a bit

> field manipulation lacks an optimization feature!!!
> 
>   Sten
> 
> -- 
> /************************************************
>  Do you need a tiny and efficient real time
>  operating system (RTOS) with a preemtive
>  multitasking for LPC2000 or AT91SAM7?
> 
>    http://nanortos.net-attack.de/
> 
>  Or some open-source tools and code for LPC2000?
> 
>    http://www.net-attack.de/
> 
> ************************************************/
>

Sure, I know about such abstract like "mask".
But maybe I want to use struct...
Regardless of this, thank you for your answer.

> At the risk of adding yet more controversy to what is getting to be 
>a 
> somewhat heated discussion, can I suggest that access to hardware 
> registers is best done using something like:
> 
> 1. Define general MACRO in some hardware-specific include file:
> 
> #define REG(addr) (*(volatile unsigned int *)(addr))
> 
> 1. Define machine registers in some include file:
> 
> /* example is I2C control register */
> 
> #define I2C_I2CONSET  (0xE001C000) /* ctrl set reg */
> 
> 3. Use as follows:
> 
> REG(I2C_I2CONSET) = 0x44;   /* set I2EN and AA */
> 
> As an alternative, you can define extra values as follows:
> 
> #define	I2C_BIT_AA   (0x04)
> #define	I2C_BIT_SI   (0x08)
> #define	I2C_BIT_STO  (0x10)
> #define	I2C_BIT_STA  (0x20)
> #define	I2C_BIT_I2EN (0x40)
> 
> and use as follows:
> 
> REG(I2C_I2CONSET) = I2C_BIT_I2EN | I2C_BIT_AA;
> 
> This has the advantage of:
> 
> - it always works, regardless of compiler, optimisation settings, 
> time of day,....
> - it's easy to follow (or as easy as any other alternative)
> - it's invariably efficiently encoded by the compiler
> 
> Contrast this with the number of questions you see on why particular 
> bit-field constructs mapped to hardware registers don't work, and it 
> might change your mind on how to do this.
> 
> Regards
> Brendan Murphy
> 
> P.S. On the main topic, I've used GCC on and off for maybe ten years 
> now. I find it fine for professional development, PROVIDED someone 
> else has set it up for the development system being used (we use 
> Ashling for LPC2000 developments, which package it nicely with their 
> IDE and ICE). It's not worth the time and effort of doing it 
> yourself, unless you're into that sort of thing (maybe you should 
>get 
> out more if you are?). We don't use any built-in library functions, 
> so library size isn't an issue for us. The reason I like it (apart 
> from the cost!) is the lack of bugs in the code generation, unlike 
> ither commercial compilers I've used. Reasons for not liking it are 
> the usual (limited support, overwhelming documentation etc. etc.). 
> 
> --- In lpc2000@yahoogroups.com, Sten <list@n...> wrote:
>>
>> \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd wrote:
>> >>Alex, 
>> >>
>> >>
>> >>>b> Just one data point, but: I'm a professional developer (30 
>> >>>years s/w 
>> >>>b> development experience from micros to mainframes).  Now 
> working 
>> >>>on 
>> >>>b> third LPC-based commercial product.  Compared Keil, IAR, 
>> >>>and gcc and 
>> >>>b> chose Rowley Crossworks (gcc-based).
>> >>>
>> >>>Oh, I can't hold out from the reply.
>> >>>I tried to use Crossworks in the begining to explore LPC2xxx.
>> >>>It ugly work with the structures. I tried to define T0MCR like
>> >>> struct:
>> >>>{{
>> >>>typedef struct
>> >>>  { 
>> >>>    __REG32 MR0I :1;
>> >>>    __REG32 MR0R :1;
>> >>>    __REG32 MR0S :1;
>> >>>
>> >>>    __REG32 MR1I :1;
>> >>>    __REG32 MR1R :1;
>> >>>    __REG32 MR1S :1;
>> >>>    
>> >>>    __REG32 MR2I :1;
>> >>>    __REG32 MR2R :1;
>> >>>    __REG32 MR2S :1;
>> >>>    
>> >>>    __REG32 MR3I :1;
>> >>>    __REG32 MR3R :1;
>> >>>    __REG32 MR3S :1;    
>> >>>    __REG32      :4;    
>> >>>} __txmcr_bits;
>> >>>
>> >>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>> >>>
>> >>>}}
>> >>>
>> >>>but when I handle to it, Crossworks GCC compile it to this code:
>> >>>
>> >>><<T0MCRbits.MR0I = 1;>>
>> >>>
>> >>>mov r3, #0xE0000000
>> >>>add r3, r3, #0x00004000
>> >>>add r3, r3, #0x00000014
>> >>>ldrb r2, [r3]
>> >>>orr r2, r2, #0x00000001
>> >>>strb r2, [r3]
>> >>>
>> >>>so, I get change in LSB and _in_the_second_byte_!.
>> >>
>> >>And you tell me *why* this is incorrect code generation?  You 
> might 
>> >>not
>> >>like what is generated, but is is *not* incorrect according to the
>> >>standard.  It is only incorrect *if* you think volatile has some 
>> >>extra
>> >>meaning above what it does in the standard.  Or *if* you think an
>> >>"unsigned long" bitfield is somehow "standard".  That is why the
>> >>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>> >>dealing
>> >>with a device" or "Access this data atomically".  Far from it.
>> > 
>> > 
>> > I tried to explain my point of view in other mail.
>> > The generated code works incorrectly because it use BYTE 
> instructions. 
>> > You can compile it, load into the chip and debug. We discuss 
> compiler 
>> > for ARM core, or what? I think IAR, Keil compilers know about 
> data 
>> > access in the ARM core.
>> > 
>> 
>> This behaviour is not bug, it's really a feature. GCC is optimizing 
> the
>> accesss to this bit-field to a minimum. Loading and storing only 
> _one_
>> byte for modifing only _one_ bit is a very good optimization on 
> designs
>> with external memory, which is not 32bit wide, to minimize memory 
> access
>> cycles. GCC doesn't know that a certain register _must_ be accessed 
> with
>> 32bit (with or without "volatile") and C standard does not say that 
> a
>> bit field manipulation is forced to be a 16bit or 32bit access. What
>> should happen, in your opinion, if you declare a bit field with more
>> than 32 bit??? How should it be handled?
>> With other words: Compiler which are using a 32bit access for such 
> a bit
>> field manipulation lacks an optimization feature!!!
>> 
>>   Sten
>> 
>> -- 
>> /************************************************
>>  Do you need a tiny and efficient real time
>>  operating system (RTOS) with a preemtive
>>  multitasking for LPC2000 or AT91SAM7?
>> 
>>    http://nanortos.net-attack.de/
>> 
>>  Or some open-source tools and code for LPC2000?
>> 
>>    http://www.net-attack.de/
>> 
>> ************************************************/
>>
> 
> 
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
>

>>>>Oh, I can't hold out from the reply.
>>>>I tried to use Crossworks in the begining to explore LPC2xxx.
>>>>It ugly work with the structures. I tried to define T0MCR like
>>>> struct:
>>>>{{
>>>>typedef struct
>>>>  { 
>>>>    __REG32 MR0I :1;
>>>>    __REG32 MR0R :1;
>>>>    __REG32 MR0S :1;
>>>>
>>>>    __REG32 MR1I :1;
>>>>    __REG32 MR1R :1;
>>>>    __REG32 MR1S :1;
>>>>    
>>>>    __REG32 MR2I :1;
>>>>    __REG32 MR2R :1;
>>>>    __REG32 MR2S :1;
>>>>    
>>>>    __REG32 MR3I :1;
>>>>    __REG32 MR3R :1;
>>>>    __REG32 MR3S :1;    
>>>>    __REG32      :4;    
>>>>} __txmcr_bits;
>>>>
>>>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
>>>>
>>>>}}
>>>>
>>>>but when I handle to it, Crossworks GCC compile it to this code:
>>>>
>>>><<T0MCRbits.MR0I = 1;>>
>>>>
>>>>mov r3, #0xE0000000
>>>>add r3, r3, #0x00004000
>>>>add r3, r3, #0x00000014
>>>>ldrb r2, [r3]
>>>>orr r2, r2, #0x00000001
>>>>strb r2, [r3]
>>>>
>>>>so, I get change in LSB and _in_the_second_byte_!.
>>>>      
>>>>
>>>And you tell me *why* this is incorrect code generation?  You might 
>>>not
>>>like what is generated, but is is *not* incorrect according to the
>>>standard.  It is only incorrect *if* you think volatile has some 
>>>extra
>>>meaning above what it does in the standard.  Or *if* you think an
>>>"unsigned long" bitfield is somehow "standard".  That is why the
>>>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
>>>dealing
>>>with a device" or "Access this data atomically".  Far from it.
>>>    
>>>
>>
>>I tried to explain my point of view in other mail.
>>The generated code works incorrectly because it use BYTE 
>>instructions. 
>>You can compile it, load into the chip and debug. We discuss compiler 
>>for ARM core, or what? I think IAR, Keil compilers know about data 
>>access in the ARM core.
>>
>>  
>>
> You are very very confused...  You have absolutely no idea what 
>"__REG32 
> MR0I :1" means, do you???  It is obvious that you are operating 
>under 
> some other understanding of just what it is that you wrote.
> 
> Go have someone explain it to you, it would take too long to do 
>here.

#define __REG32 unsigned long

I only declare bit field. I can use uchar, or uint, it does't 
important for bit field declaration
Any questions?

> TomW

Hi, 

> > You are very very confused...  You have absolutely no idea what
> >"__REG32
> > MR0I :1" means, do you???  It is obvious that you are 
> operating under  
> >some other understanding of just what it is that you wrote.
> > 
> > Go have someone explain it to you, it would take too long 
> to do here.
> 
> #define __REG32 unsigned long
> 
> I only declare bit field. I can use uchar, or uint, it does't 
> important for bit field declaration Any questions?

Yes, it *does* matter.  The only *correct* usage when defining a
bitfield is to use int or unsigned int -- if you use unsigned long or
unsigned char when defining a bitfield, all bets are off because ISO C
does not *define* what happens.

Some compilers *do* define what happens when you use these types but
that is an extension of the existing standard.  A useful extension to be
sure, and something that might, one day, even make it into the standard
(though I really do dobt that it will).

There is a technical report (TR) which does not hold as much weight as a
full standard that does define how to access I/O using C-language
constructs.  You're bending the language and your interpretation to fit
the hardware.

That's all I'll say.  GCC doesn't do what you want it to do, you found a
compiler that does, be happy.  :-)

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

>> > You are very very confused...  You have absolutely no idea what
>> >"__REG32
>> > MR0I :1" means, do you???  It is obvious that you are 
>> operating under  
>> >some other understanding of just what it is that you wrote.
>> > 
>> > Go have someone explain it to you, it would take too long 
>> to do here.
>> 
>> #define __REG32 unsigned long
>> 
>> I only declare bit field. I can use uchar, or uint, it does't 
>> important for bit field declaration Any questions?
> 
> Yes, it *does* matter.  The only *correct* usage when defining a
> bitfield is to use int or unsigned int -- if you use unsigned long 
>or
> unsigned char when defining a bitfield, all bets are off because ISO 
>C
> does not *define* what happens.

Thank you for my education

> Some compilers *do* define what happens when you use these types but
> that is an extension of the existing standard.  A useful extension 
>to be
> sure, and something that might, one day, even make it into the 
>standard
> (though I really do dobt that it will).
> 
> There is a technical report (TR) which does not hold as much weight 
>as a
> full standard that does define how to access I/O using C-language
> constructs.  You're bending the language and your interpretation to 
>fit
> the hardware.

Is this open or closed report?
  
> That's all I'll say.  GCC doesn't do what you want it to do, you 
>found a
> compiler that does, be happy.  :-)

I only draw attention on some peculiar properties of Crossworks port 
of gcc.
I reconsider one's views about good style of coding 8=)

> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, AVR and now MAXQ processors
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
>

????????? ??????? wrote:

>On Tue, 08 Nov 2005 04:47:49 -0500
>  Tom Walsh <tom@...> wrote:
>  
>
>>vaneenbergen wrote:
>>
>>    
>>
>>>That the first bit of the second byte also changed is very possible. 
>>>This is de to the processor. The timer register should be handled in 
>>>a 32 bit access. this is what i found out. so instead of these kind 
>>>of structures i just handle them in 32-bit. this way it is also 
>>>quicker, you can change all values at the same time.
>>>
>>>is this really the fault of the compiler?????
>>> 
>>>
>>>      
>>>
>>He didn't understand what it was that he wrote so how can he answer 
>>that 
>>question?
>>
>>
>>TomW
>>
>>    
>>
>
>What you mean? I think it obviously, that it's really fault of 
>compiler. I explain my point of view to Paul
>  
>
Okay, while washing some dishes in the kitchen, I finally realized that 
you skipped ahead to blame the compiler and were convinced that your 
code is correct.  It is not.

I believe, and correct me if I am wrong, that what you were trying to do 
was to describe the T0MCR register so that you could access it and 
change values???

If so, here is what you should have done:

================= packed struct ===================
typedef struct __attribute__ ((packed))
{
__REG32 MR0I :1;
__REG32 MR0R :1;
__REG32 MR0S :1;

__REG32 MR1I :1;
__REG32 MR1R :1;
__REG32 MR1S :1;

__REG32 MR2I :1;
__REG32 MR2R :1;
__REG32 MR2S :1;

__REG32 MR3I :1;
__REG32 MR3R :1;
__REG32 MR3S :1;
__REG32 :4;
} __txmcr_bits;

#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)

===================== snip =======================

The volatile can stay, it is harmless.  What is key is the 
"__attribute__ ((packed))" keyphrase.  What that means is that the 
padding between elements of the structure is to be removed.  If you say 
this:

=============== begin ===============

struct FLESHY {
    long    foo;
    char   bar;
    long   done;
};

struct SMALLER {
    long    foo;
    char   bar;
    long   done;
} __attribute__ ((packed));

struct FLESHY bean;

struct SMALLER soup;

============== snip ================

You will find that "bean" is 12 bytes and "soup" is 9 bytes...  This is 
because the structure has been packed, all the "air" has been removed.  
ok?  Try it, do a printf ("%d\n", sizeof(bean)) and a printf("%d\n", 
sizeof(soup)).

Now, what you said was this:  "MR01 is significant to 1 bit and is 
aligned on a 32 bit boundry".

gcc did not do it "wrong", you just did not read what you told it.  The 
compiler did exactly what you told it to do.

Look at this, this is my definition of the RTCTCR registers of the LPC2138:

=========== begin ================
typedef struct __attribute__ ((packed))
{
    uint    seconds:6;
    uint    reserved:2;
    uint    minutes:6;
    uint    reserved1:2;
    uint    hours:5;
    uint    reserved2:3;
    uint    dayOfWeek:3;
    uint    reserved3:5;
} rtcCTIME0_t;

typedef struct __attribute__ ((packed)) {
    uint    dayOfMonth:5;
    uint    reserved:3;
    uint    month:4;
    uint    reserved1:4;
    uint    year:12;
    uint    reserved2:4;
} rtcCTIME1_t;

typedef struct __attribute__ ((packed)) {
    uint    dayOfYear:12;
    uint    reserved:20;
} rtcCTIME2_t;


typedef struct
{
  REG_8 ilr;            // Interrupt Location Register
  REG_8 _pad0[3];
  REG16 ctc;            // Clock Tick Counter
  REG16 _pad1;
  REG_8 ccr;            // Clock Control Register
  REG_8 _pad2[3];
  REG_8 ciir;            // Counter Increment Interrupt Register
  REG_8 _pad3[3];
  REG_8 amr;            // Alarm Mask Register
  REG_8 _pad4[3];
  rtcCTIME0_t ctime0;            // Consolidated Time Register 0
  rtcCTIME1_t ctime1;            // Consolidated Time Register 1
  rtcCTIME2_t ctime2;            // Consolidated Time Register 2
  REG_8 sec;            // Seconds Register
  REG_8 _pad5[3];
  REG_8 min;            // Minutes Register
  REG_8 _pad6[3];
  REG_8 hour;            // Hours Register
  REG_8 _pad7[3];
  REG_8 dom;            // Day Of Month Register
  REG_8 _pad8[3];
  REG_8 dow;            // Day Of Week Register
  REG_8 _pad9[3];
  REG16 doy;            // Day Of Year Register
  REG16 _pad10;
  REG_8 month;            // Months Register
  REG_8 _pad11[3];
  REG16 year;            // Years Register
  REG32 _pad12[8];
  REG_8 alsec;            // Alarm Seconds Register
  REG_8 _pad13[3];
  REG_8 almin;            // Alarm Minutes Register
  REG_8 _pad14[3];
  REG_8 alhour;        // Alarm Hours Register
  REG_8 _pad15[3];
  REG_8 aldom;            // Alarm Day Of Month Register
  REG_8 _pad16[3];
  REG_8 aldow;            // Alarm Day Of Week Register
  REG_8 _pad17[3];
  REG16 aldoy;            // Alarm Day Of Year Register
  REG16 _pad18;
  REG_8 almon;            // Alarm Months Register
  REG_8 _pad19[3];
  REG16 alyear;        // Alarm Years Register
  REG16 _pad20;
  REG16 preint;        // Prescale Value Register (integer)
  REG16 _pad21;
  REG16 prefrac;        // Prescale Value Register (fraction)
  REG16 _pad22;
} rtcRegs_t;

#define RTC             ((rtcRegs_t *)0xE0024000)
#define RTCTCR                ((rtcTCR_t *)0xe0024020)

============ snip ================

The difference with gcc is that you have to _explicitly_ tell it to pack 
a structure.

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Paul you should know by now that you'll never make Alex happy. he thinks 
the way he expects things to work IS the standard. Anything outside of 
that is a bug. A different user name can't hide his unique style.

Al

Paul Curtis wrote:

>Hi, 
>
>  
>
>>>You are very very confused...  You have absolutely no idea what
>>>"__REG32
>>>MR0I :1" means, do you???  It is obvious that you are 
>>>      
>>>
>>operating under  
>>    
>>
>>>some other understanding of just what it is that you wrote.
>>>
>>>Go have someone explain it to you, it would take too long 
>>>      
>>>
>>to do here.
>>
>>#define __REG32 unsigned long
>>
>>I only declare bit field. I can use uchar, or uint, it does't 
>>important for bit field declaration Any questions?
>>    
>>
>
>Yes, it *does* matter.  The only *correct* usage when defining a
>bitfield is to use int or unsigned int -- if you use unsigned long or
>unsigned char when defining a bitfield, all bets are off because ISO C
>does not *define* what happens.
>
>Some compilers *do* define what happens when you use these types but
>that is an extension of the existing standard.  A useful extension to be
>sure, and something that might, one day, even make it into the standard
>(though I really do dobt that it will).
>
>There is a technical report (TR) which does not hold as much weight as a
>full standard that does define how to access I/O using C-language
>constructs.  You're bending the language and your interpretation to fit
>the hardware.
>
>That's all I'll say.  GCC doesn't do what you want it to do, you found a
>compiler that does, be happy.  :-)
>
>--
>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

Hi,

Just thought I'd ask if anyone has done the following.

FreeRTOS has a demo application for the Keil MCB2100 board, that 
compiles with the Keil compiler in the Keil uVision IDE.

Has anyone created a uVision project file that they would like to share, 
for this demo but with the GCC compiler rather than the Keil compiler?

Cheers,

Peter.

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

You are wrong, I can acknowledge one's mistakes :-)
About user name - please see e-mail, not user name. It's code page 
error of web interface of my mail account.

> Paul you should know by now that you'll never make Alex happy. he 
>thinks 
> the way he expects things to work IS the standard. Anything outside 
>of 
> that is a bug. A different user name can't hide his unique style.
> 
> Al
> 
> Paul Curtis wrote:
> 
>>Hi, 
>>
>>  
>>
>>>>You are very very confused...  You have absolutely no idea what
>>>>"__REG32
>>>>MR0I :1" means, do you???  It is obvious that you are 
>>>>      
>>>>
>>>operating under  
>>>    
>>>
>>>>some other understanding of just what it is that you wrote.
>>>>
>>>>Go have someone explain it to you, it would take too long 
>>>>      
>>>>
>>>to do here.
>>>
>>>#define __REG32 unsigned long
>>>
>>>I only declare bit field. I can use uchar, or uint, it does't 
>>>important for bit field declaration Any questions?
>>>    
>>>
>>
>>Yes, it *does* matter.  The only *correct* usage when defining a
>>bitfield is to use int or unsigned int -- if you use unsigned long or
>>unsigned char when defining a bitfield, all bets are off because ISO 
>>C
>>does not *define* what happens.
>>
>>Some compilers *do* define what happens when you use these types but
>>that is an extension of the existing standard.  A useful extension to 
>>be
>>sure, and something that might, one day, even make it into the 
>>standard
>>(though I really do dobt that it will).
>>
>>There is a technical report (TR) which does not hold as much weight 
>>as a
>>full standard that does define how to access I/O using C-language
>>constructs.  You're bending the language and your interpretation to 
>>fit
>>the hardware.
>>
>>That's all I'll say.  GCC doesn't do what you want it to do, you 
>>found a
>>compiler that does, be happy.  :-)
>>
>>--
>>Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
>>CrossWorks for MSP430, ARM, AVR and now MAXQ processors
>>
>>
>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>
>>  
>>
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
>

Tom,

Are you saying that with the (packed) attribute, the
compiler will treat the number as 16bits where given
the orginal poster's definition the struct would be
32bits?  Now if the register were treated as 32bits,
would this cause a problem? 

--- Tom Walsh <tom@...> wrote:

> ????????? ??????? wrote:
> 
> >On Tue, 08 Nov 2005 04:47:49 -0500
> >  Tom Walsh <tom@...> wrote:
> >  
> >
> >>vaneenbergen wrote:
> >>
> >>    
> >>
> >>>That the first bit of the second byte also
> changed is very possible. 
> >>>This is de to the processor. The timer register
> should be handled in 
> >>>a 32 bit access. this is what i found out. so
> instead of these kind 
> >>>of structures i just handle them in 32-bit. this
> way it is also 
> >>>quicker, you can change all values at the same
> time.
> >>>
> >>>is this really the fault of the compiler?????
> >>> 
> >>>
> >>>      
> >>>
> >>He didn't understand what it was that he wrote so
> how can he answer 
> >>that 
> >>question?
> >>
> >>
> >>TomW
> >>
> >>    
> >>
> >
> >What you mean? I think it obviously, that it's
> really fault of 
> >compiler. I explain my point of view to Paul
> >  
> >
> Okay, while washing some dishes in the kitchen, I
> finally realized that 
> you skipped ahead to blame the compiler and were
> convinced that your 
> code is correct.  It is not.
> 
> I believe, and correct me if I am wrong, that what
> you were trying to do 
> was to describe the T0MCR register so that you could
> access it and 
> change values???
> 
> If so, here is what you should have done:
> 
> ================= packed struct ===================
> typedef struct __attribute__ ((packed))
> {
> __REG32 MR0I :1;
> __REG32 MR0R :1;
> __REG32 MR0S :1;
> 
> __REG32 MR1I :1;
> __REG32 MR1R :1;
> __REG32 MR1S :1;
> 
> __REG32 MR2I :1;
> __REG32 MR2R :1;
> __REG32 MR2S :1;
> 
> __REG32 MR3I :1;
> __REG32 MR3R :1;
> __REG32 MR3S :1;
> __REG32 :4;
> } __txmcr_bits;
> 
> #define T0MCRbits (*(volatile __txmcr_bits
> *)0xE0004014)
> 
> ===================== snip =======================
> 
> The volatile can stay, it is harmless.  What is key
> is the 
> "__attribute__ ((packed))" keyphrase.  What that
> means is that the 
> padding between elements of the structure is to be
> removed.  If you say 
> this:
> 
> =============== begin ===============
> 
> struct FLESHY {
>     long    foo;
>     char   bar;
>     long   done;
> };
> 
> struct SMALLER {
>     long    foo;
>     char   bar;
>     long   done;
> } __attribute__ ((packed));
> 
> struct FLESHY bean;
> 
> struct SMALLER soup;
> 
> ============== snip ================
> 
> You will find that "bean" is 12 bytes and "soup" is
> 9 bytes...  This is 
> because the structure has been packed, all the "air"
> has been removed.  
> ok?  Try it, do a printf ("%d\n", sizeof(bean)) and
> a printf("%d\n", 
> sizeof(soup)).
> 
> Now, what you said was this:  "MR01 is significant
> to 1 bit and is 
> aligned on a 32 bit boundry".
> 
> gcc did not do it "wrong", you just did not read
> what you told it.  The 
> compiler did exactly what you told it to do.
> 
> Look at this, this is my definition of the RTCTCR
> registers of the LPC2138:
> 
> =========== begin ================
> typedef struct __attribute__ ((packed))
> {
>     uint    seconds:6;
>     uint    reserved:2;
>     uint    minutes:6;
>     uint    reserved1:2;
>     uint    hours:5;
>     uint    reserved2:3;
>     uint    dayOfWeek:3;
>     uint    reserved3:5;
> } rtcCTIME0_t;
> 
> typedef struct __attribute__ ((packed)) {
>     uint    dayOfMonth:5;
>     uint    reserved:3;
>     uint    month:4;
>     uint    reserved1:4;
>     uint    year:12;
>     uint    reserved2:4;
> } rtcCTIME1_t;
> 
> typedef struct __attribute__ ((packed)) {
>     uint    dayOfYear:12;
>     uint    reserved:20;
> } rtcCTIME2_t;
> 
> 
> typedef struct
> {
>   REG_8 ilr;            // Interrupt Location
> Register
>   REG_8 _pad0[3];
>   REG16 ctc;            // Clock Tick Counter
>   REG16 _pad1;
>   REG_8 ccr;            // Clock Control Register
>   REG_8 _pad2[3];
>   REG_8 ciir;            // Counter Increment
> Interrupt Register
>   REG_8 _pad3[3];
>   REG_8 amr;            // Alarm Mask Register
>   REG_8 _pad4[3];
>   rtcCTIME0_t ctime0;            // Consolidated
> Time Register 0
>   rtcCTIME1_t ctime1;            // Consolidated
> Time Register 1
>   rtcCTIME2_t ctime2;            // Consolidated
> Time Register 2
>   REG_8 sec;            // Seconds Register
>   REG_8 _pad5[3];
>   REG_8 min;            // Minutes Register
>   REG_8 _pad6[3];
>   REG_8 hour;            // Hours Register
>   REG_8 _pad7[3];
>   REG_8 dom;            // Day Of Month Register
>   REG_8 _pad8[3];
>   REG_8 dow;            // Day Of Week Register
>   REG_8 _pad9[3];
>   REG16 doy;            // Day Of Year Register
>   REG16 _pad10;
>   REG_8 month;            // Months Register
>   REG_8 _pad11[3];
>   REG16 year;            // Years Register
>   REG32 _pad12[8];
>   REG_8 alsec;            // Alarm Seconds Register
>   REG_8 _pad13[3];
>   REG_8 almin;            // Alarm Minutes Register
>   REG_8 _pad14[3];
>   REG_8 alhour;        // Alarm Hours Register
>   REG_8 _pad15[3];
>   REG_8 aldom;            // Alarm Day Of Month
> Register
> 
=== message truncated ===



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

All,

I have been trying to follow the issue of the code generation for 
the typedef.  So, I tried it for setting 3 of the bits; the two 
least significant and the most significant, ignoring the padding:

  27:main.c        **** 	T0MCRbits.MR0I = 1;
  26 000c 0E32A0E3 		mov	r3, #-536870912
  27 0010 013983E2 		add	r3, r3, #16384
  28 0014 143083E2 		add	r3, r3, #20
  29 0018 0020D3E5 		ldrb	r2, [r3, #0]
  30 001c 012082E3 		orr	r2, r2, #1
  31 0020 0020C3E5 		strb	r2, [r3, #0]

  28:main.c        **** 	T0MCRbits.MR0R = 1;
  32              		.loc 1 28 0
  33 0024 0E32A0E3 		mov	r3, #-536870912
  34 0028 013983E2 		add	r3, r3, #16384
  35 002c 143083E2 		add	r3, r3, #20
  36 0030 0020D3E5 		ldrb	r2, [r3, #0]
  37 0034 022082E3 		orr	r2, r2, #2
  38 0038 0020C3E5 		strb	r2, [r3, #0]

  29:main.c        **** 	T0MCRbits.MR3S = 1;
  39              		.loc 1 29 0
  40 003c 0E32A0E3 		mov	r3, #-536870912
  41 0040 013983E2 		add	r3, r3, #16384
  42 0044 143083E2 		add	r3, r3, #20
  43 0048 0120D3E5 		ldrb	r2, [r3, #1]
  44 004c 082082E3 		orr	r2, r2, #8
  45 0050 0120C3E5 		strb	r2, [r3, #1]

Since the typedef describes only 16 bits, setting MR3S results in 
setting the 4th bit of the second byte.  Seems right to me.  It 
doesn't appear, to me anyway, that packing comes into play here.

OK, I think I understand: the problem is that you can't use byte 
access to a 32 bit hardware register even if it is memory mapped.  
But, the compiler can't KNOW that a given address must be handled as 
a 32 bit access, it has to be told.  I suppose if the compiler were 
SPECIFIC to a given piece of hardware it would be possible to impart 
that knowledge but it isn't.

The thing I don't understand is the address calculation.  I am 
using -O0 so I understand it won't do much optimizing but, to me, 
the 3 instructions used to load a register with a constant value 
seems excessive.  It gets a little better with -O3 but still, the 
address is a constant, why calculate it?

Now, since the compiler writers are very bright folks and I am just 
a user who has never read the standard (how come I have to pay for 
it?), I assume they do this calculation for a reason.  Does anyone 
know why?

Thanks
Richard

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>
> All,
> 
> I have been trying to follow the issue of the code generation for 
> the typedef.  So, I tried it for setting 3 of the bits; the two 
> least significant and the most significant, ignoring the padding:
> 
>   27:main.c        **** 	T0MCRbits.MR0I = 1;
>   26 000c 0E32A0E3 		mov	r3, #-536870912
>   27 0010 013983E2 		add	r3, r3, #16384
>   28 0014 143083E2 		add	r3, r3, #20
>   29 0018 0020D3E5 		ldrb	r2, [r3, #0]
>   30 001c 012082E3 		orr	r2, r2, #1
>   31 0020 0020C3E5 		strb	r2, [r3, #0]
> 
>   28:main.c        **** 	T0MCRbits.MR0R = 1;
>   32              		.loc 1 28 0
>   33 0024 0E32A0E3 		mov	r3, #-536870912
>   34 0028 013983E2 		add	r3, r3, #16384
>   35 002c 143083E2 		add	r3, r3, #20
>   36 0030 0020D3E5 		ldrb	r2, [r3, #0]
>   37 0034 022082E3 		orr	r2, r2, #2
>   38 0038 0020C3E5 		strb	r2, [r3, #0]
> 
>   29:main.c        **** 	T0MCRbits.MR3S = 1;
>   39              		.loc 1 29 0
>   40 003c 0E32A0E3 		mov	r3, #-536870912
>   41 0040 013983E2 		add	r3, r3, #16384
>   42 0044 143083E2 		add	r3, r3, #20
>   43 0048 0120D3E5 		ldrb	r2, [r3, #1]
>   44 004c 082082E3 		orr	r2, r2, #8
>   45 0050 0120C3E5 		strb	r2, [r3, #1]
> 
> Since the typedef describes only 16 bits, setting MR3S results in 
> setting the 4th bit of the second byte.  Seems right to me.  It 
> doesn't appear, to me anyway, that packing comes into play here.
> 
> OK, I think I understand: the problem is that you can't use byte 
> access to a 32 bit hardware register even if it is memory mapped.  
> But, the compiler can't KNOW that a given address must be handled as 
> a 32 bit access, it has to be told.  I suppose if the compiler were 
> SPECIFIC to a given piece of hardware it would be possible to impart 
> that knowledge but it isn't.

You can use 8bit access to 32bit memory, but some registers don't like
it. The compiler only sees some memory in which registers are mapped.
The compiler need not to know about certain registers. It should only
"convert" C code to machine code with a maximum of efficiency.

> 
> The thing I don't understand is the address calculation.  I am 
> using -O0 so I understand it won't do much optimizing but, to me, 
> the 3 instructions used to load a register with a constant value 
> seems excessive.  It gets a little better with -O3 but still, the 
> address is a constant, why calculate it?

ARM instructions can only take 12bit of immediate operands with a bit
displacement. So it is not possible to load a full 32bit immediate
value into a core register directly, except that the value can
separated into a single 12bit value and a shift value. If you turn on
optimization GCC may use a trick to minimize cycles. Immediate values
are stored in memory in a location near (< 2^12) to this instruction.
Now GCC can load this "immediate" value out of memory relativ to its
program counter in one cycle for example.

     LDR R0, [PC, #+15]

> 
> Now, since the compiler writers are very bright folks and I am just 
> a user who has never read the standard (how come I have to pay for 
> it?), I assume they do this calculation for a reason.  Does anyone 
> know why?

Compiler guys are totaly crazy! ;-)

> 
> Thanks
> Richard
>


  Sten

bdmlpc wrote:

>--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>  
>
>>The thing I don't understand is the address calculation.  I am 
>>using -O0 so I understand it won't do much optimizing but, to me, 
>>the 3 instructions used to load a register with a constant value 
>>seems excessive.  It gets a little better with -O3 but still, the 
>>address is a constant, why calculate it?
>>    
>>
>
>ARM instructions can only take 12bit of immediate operands with a bit
>displacement. So it is not possible to load a full 32bit immediate
>value into a core register directly, except that the value can
>separated into a single 12bit value and a shift value. If you turn on
>optimization GCC may use a trick to minimize cycles. Immediate values
>are stored in memory in a location near (< 2^12) to this instruction.
>Now GCC can load this "immediate" value out of memory relativ to its
>program counter in one cycle for example.
>
>     LDR R0, [PC, #+15]
>
>  
>
Exactly, ARM instructions _always_ are 32bits long.  That includes the 
operation code and operands.   An X86 or 68K processor uses variable 
lenght instructions.

Having said that, I will say that reading ARM assembler makes my head 
ache.  It may be a simpler set of instructions but it is very rich in 
addressing modes.

What will drive me crazy is attempting to debug fully opimized code: -Os

>>Now, since the compiler writers are very bright folks and I am just 
>>a user who has never read the standard (how come I have to pay for 
>>it?), I assume they do this calculation for a reason.  Does anyone 
>>know why?
>>    
>>
>
>Compiler guys are totaly crazy! ;-)
>  
>
You can download all the information about ARM from their website: 
arm.com.  However, you will pay for printed material (book form vs. PDF).

Actually, do you really want to know? heh.

TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

42Bastian Schick wrote:

>Tom
>
>  
>
>>You may notice the effect that the '--' double dash does to the font of
>>the signature below?  That is also another convention, '--' on a line by
>>itself denotes "signature to follow".
>>    
>>
>
>Slight correction (I've been corrected before myself):
>"-- " openes the signature not "--"
>    ^ SPACE
>
>  
>
:P


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

> You can download all the information about ARM from their website: 
> arm.com.  However, you will pay for printed material (book form 
vs. PDF).
> 
> Actually, do you really want to know? heh.
> 
> TomW
> 
> -- 
> Tom Walsh - WN3L - Embedded Systems Consultant
> http://openhardware.net, http://cyberiansoftware.com
> "Windows? No thanks, I have work to do..."
> ----------------------------------------------------
>

A while back I wanted to download the C standard.  It seems I would 
have to pay for it.  The C++ standard was free (or cheap) so I 
grabbed it with the intent to have it printed and bound.

I have the stuff from ARM and I haven't read it.  I also have not 
fully digested the datasheet and user manual for the 2106.  The way 
I do it is I start a project and, as problems come up, I read just 
enough to solve them.  If I can't find a solution, I ask.

One thing that is absolutely certain: no matter what problem I 
encounter, someone else has already been there and gotten the 
scars.  The information will be out there somewhere...

Richard

I agree, avoid using bit fields.  How bit fields are implemented is
compiler dependent.  Granted many (all?) compilers give the option of
signed/unsigned and such, but I'd prefer to avoid that issue entirely.
 Plus accessing individual bits can be wasteful as far as code size is
concerned, and flat out may not give the results you want.

Last year I had one piece of code that crashed the system when it ran.
 I was setting up the EMC register and GPIO for external RAM by using
bit fields, and the code died a miserable death.  After I replaced it
with simple register assignments it worked. I learned my lesson and
ripped out every bit field definition I had.  Bit fields are in the
grey area of C/C++ standards and are probably best left out of code.


David

--- In lpc2000@yahoogroups.com, "brendanmurphy37"
<brendan.murphy@i...> wrote:

>
> 
> At the risk of adding yet more controversy to what is getting to be a 
> somewhat heated discussion, can I suggest that access to hardware 
> registers is best done using something like:
> 
> 1. Define general MACRO in some hardware-specific include file:
> 
> #define REG(addr) (*(volatile unsigned int *)(addr))
> 
> 1. Define machine registers in some include file:
> 
> /* example is I2C control register */
> 
> #define I2C_I2CONSET  (0xE001C000) /* ctrl set reg */
> 
> 3. Use as follows:
> 
> REG(I2C_I2CONSET) = 0x44;   /* set I2EN and AA */
> 
> As an alternative, you can define extra values as follows:
> 
> #define	I2C_BIT_AA   (0x04)
> #define	I2C_BIT_SI   (0x08)
> #define	I2C_BIT_STO  (0x10)
> #define	I2C_BIT_STA  (0x20)
> #define	I2C_BIT_I2EN (0x40)
> 
> and use as follows:
> 
> REG(I2C_I2CONSET) = I2C_BIT_I2EN | I2C_BIT_AA;
> 
> This has the advantage of:
> 
> - it always works, regardless of compiler, optimisation settings, 
> time of day,....
> - it's easy to follow (or as easy as any other alternative)
> - it's invariably efficiently encoded by the compiler
> 
> Contrast this with the number of questions you see on why particular 
> bit-field constructs mapped to hardware registers don't work, and it 
> might change your mind on how to do this.
> 
> Regards
> Brendan Murphy
> 
> P.S. On the main topic, I've used GCC on and off for maybe ten years 
> now. I find it fine for professional development, PROVIDED someone 
> else has set it up for the development system being used (we use 
> Ashling for LPC2000 developments, which package it nicely with their 
> IDE and ICE). It's not worth the time and effort of doing it 
> yourself, unless you're into that sort of thing (maybe you should get 
> out more if you are?). We don't use any built-in library functions, 
> so library size isn't an issue for us. The reason I like it (apart 
> from the cost!) is the lack of bugs in the code generation, unlike 
> ither commercial compilers I've used. Reasons for not liking it are 
> the usual (limited support, overwhelming documentation etc. etc.). 
> 
> --- In lpc2000@yahoogroups.com, Sten <list@n...> wrote:
> >
> > Àëåêñàíäð Áîðèñîâ wrote:
> > >>Alex, 
> > >>
> > >>
> > >>>b> Just one data point, but: I'm a professional developer (30 
> > >>>years s/w 
> > >>>b> development experience from micros to mainframes).  Now 
> working 
> > >>>on 
> > >>>b> third LPC-based commercial product.  Compared Keil, IAR, 
> > >>>and gcc and 
> > >>>b> chose Rowley Crossworks (gcc-based).
> > >>>
> > >>>Oh, I can't hold out from the reply.
> > >>>I tried to use Crossworks in the begining to explore LPC2xxx.
> > >>>It ugly work with the structures. I tried to define T0MCR like
> > >>> struct:
> > >>>{{
> > >>>typedef struct
> > >>>  { 
> > >>>    __REG32 MR0I :1;
> > >>>    __REG32 MR0R :1;
> > >>>    __REG32 MR0S :1;
> > >>>
> > >>>    __REG32 MR1I :1;
> > >>>    __REG32 MR1R :1;
> > >>>    __REG32 MR1S :1;
> > >>>    
> > >>>    __REG32 MR2I :1;
> > >>>    __REG32 MR2R :1;
> > >>>    __REG32 MR2S :1;
> > >>>    
> > >>>    __REG32 MR3I :1;
> > >>>    __REG32 MR3R :1;
> > >>>    __REG32 MR3S :1;    
> > >>>    __REG32      :4;    
> > >>>} __txmcr_bits;
> > >>>
> > >>>#define T0MCRbits (*(volatile __txmcr_bits *)0xE0004014)
> > >>>
> > >>>}}
> > >>>
> > >>>but when I handle to it, Crossworks GCC compile it to this code:
> > >>>
> > >>><<T0MCRbits.MR0I = 1;>>
> > >>>
> > >>>mov r3, #0xE0000000
> > >>>add r3, r3, #0x00004000
> > >>>add r3, r3, #0x00000014
> > >>>ldrb r2, [r3]
> > >>>orr r2, r2, #0x00000001
> > >>>strb r2, [r3]
> > >>>
> > >>>so, I get change in LSB and _in_the_second_byte_!.
> > >>
> > >>And you tell me *why* this is incorrect code generation?  You 
> might 
> > >>not
> > >>like what is generated, but is is *not* incorrect according to the
> > >>standard.  It is only incorrect *if* you think volatile has some 
> > >>extra
> > >>meaning above what it does in the standard.  Or *if* you think an
> > >>"unsigned long" bitfield is somehow "standard".  That is why the
> > >>Embedded C TR has I/O support.  Volatile does *not* mean "I'm 
> > >>dealing
> > >>with a device" or "Access this data atomically".  Far from it.
> > > 
> > > 
> > > I tried to explain my point of view in other mail.
> > > The generated code works incorrectly because it use BYTE 
> instructions. 
> > > You can compile it, load into the chip and debug. We discuss 
> compiler 
> > > for ARM core, or what? I think IAR, Keil compilers know about 
> data 
> > > access in the ARM core.
> > > 
> > 
> > This behaviour is not bug, it's really a feature. GCC is optimizing 
> the
> > accesss to this bit-field to a minimum. Loading and storing only 
> _one_
> > byte for modifing only _one_ bit is a very good optimization on 
> designs
> > with external memory, which is not 32bit wide, to minimize memory 
> access
> > cycles. GCC doesn't know that a certain register _must_ be accessed 
> with
> > 32bit (with or without "volatile") and C standard does not say that 
> a
> > bit field manipulation is forced to be a 16bit or 32bit access. What
> > should happen, in your opinion, if you declare a bit field with more
> > than 32 bit??? How should it be handled?
> > With other words: Compiler which are using a 32bit access for such 
> a bit
> > field manipulation lacks an optimization feature!!!
> > 
> >   Sten
> > 
> > -- 
> > /************************************************
> >  Do you need a tiny and efficient real time
> >  operating system (RTOS) with a preemtive
> >  multitasking for LPC2000 or AT91SAM7?
> > 
> >    http://nanortos.net-attack.de/
> > 
> >  Or some open-source tools and code for LPC2000?
> > 
> >    http://www.net-attack.de/
> > 
> > ************************************************/
> >
>

On Tuesday 08 November 2005 21:32, ????????? ??????? wrote:
> Yes, I mean exactly this!! Crossworks GCC compiler works with bit
> fields of structures using byte instructions. So if you access to the
> VICIntSelect (if it defined like struct) you can even fall out to the
> Data Abort.
> And it not Philips feature, it's ARM feature (data access), am I
> right?

You are partially right. The behaviour is partially ARM defined, and partially 
Philips defined.

A byte intruction won't give a data abort (except for a bad address) because 
byte instructions can access any address. A 32/16-bit access that is not 
properly aligned  **might** give you a data abort or might just give you 
rubbish.

>
> As against, IAR, Keil work with the bit fields of struct relatively to
> it (struct) absolute size (used byte or word instructions).
>
> > That the first bit of the second byte also changed is very possible.
> > This is de to the processor. The timer register should be handled in
> > a 32 bit access. this is what i found out. so instead of these kind
> > of structures i just handle them in 32-bit. this way it is also
> > quicker, you can change all values at the same time.

It is often quicker for other reasons too. Often peripheral register accesses 
are slow, so it is better to make fewer of them.

> >
> > is this really the fault of the compiler?????

No. Never use bitfields for accessing hardware, peripheral registers etc. You 
can typically (safely) use them for software structures.

Bitfield implementation is compiler dependent. You might say "hey it works for 
me using compiler X and I will never use compiler Y", but compiler X might 
change from version 3.61 to version 3.62.



>

IAR's Embedded Workbench for ARM provides the 
bit field definitions for the Special Function 
Registers for most popular derivatives in C 
header files.  No need to worry about C compiler 
support.

Here is the list of Philips LPC2000 derivatives
supported:

lpc210x
lpc2114
lpc2119
lpc2124
lpc2129
lpc2130
lpc2131
lpc2132
lpc2134
lpc2136
lpc2138
lpc2142
lpc2148
lpc2194
lpc2212
lpc2214
lpc2292
lpc2294

Also, there is debugger register display down to 
the bitfield for all the special function registers 
in the listed derivatives.

--- Alan Strickland <thestricnine@...> wrote:

> I agree, avoid using bit fields.  How bit fields are
> implemented is
> compiler dependent.  Granted many (all?) compilers
> give the option of
> signed/unsigned and such, but I'd prefer to avoid
> that issue entirely.
>  Plus accessing individual bits can be wasteful as
> far as code size is
> concerned, and flat out may not give the results you
> want.
> 
> Last year I had one piece of code that crashed the
> system when it ran.
>  I was setting up the EMC register and GPIO for
> external RAM by using
> bit fields, and the code died a miserable death. 
> After I replaced it
> with simple register assignments it worked. I
> learned my lesson and
> ripped out every bit field definition I had.  Bit
> fields are in the
> grey area of C/C++ standards and are probably best
> left out of code.
> 
> 
> David
> 
> --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> <brendan.murphy@i...> wrote:
> >
> > 
> > At the risk of adding yet more controversy to what
> is getting to be a 
> > somewhat heated discussion, can I suggest that
> access to hardware 
> > registers is best done using something like:
> > 
> > 1. Define general MACRO in some hardware-specific
> include file:
> > 
> > #define REG(addr) (*(volatile unsigned int
> *)(addr))
> > 
> > 1. Define machine registers in some include file:
> > 
> > /* example is I2C control register */
> > 
> > #define I2C_I2CONSET  (0xE001C000) /* ctrl set reg
> */
> > 
> > 3. Use as follows:
> > 
> > REG(I2C_I2CONSET) = 0x44;   /* set I2EN and AA */
> > 
> > As an alternative, you can define extra values as
> follows:
> > 
> > #define	I2C_BIT_AA   (0x04)
> > #define	I2C_BIT_SI   (0x08)
> > #define	I2C_BIT_STO  (0x10)
> > #define	I2C_BIT_STA  (0x20)
> > #define	I2C_BIT_I2EN (0x40)
> > 
> > and use as follows:
> > 
> > REG(I2C_I2CONSET) = I2C_BIT_I2EN | I2C_BIT_AA;
> > 
> > This has the advantage of:
> > 
> > - it always works, regardless of compiler,
> optimisation settings, 
> > time of day,....
> > - it's easy to follow (or as easy as any other
> alternative)
> > - it's invariably efficiently encoded by the
> compiler
> > 
> > Contrast this with the number of questions you see
> on why particular 
> > bit-field constructs mapped to hardware registers
> don't work, and it 
> > might change your mind on how to do this.
> > 
> > Regards
> > Brendan Murphy
> > 
> > P.S. On the main topic, I've used GCC on and off
> for maybe ten years 
> > now. I find it fine for professional development,
> PROVIDED someone 
> > else has set it up for the development system
> being used (we use 
> > Ashling for LPC2000 developments, which package it
> nicely with their 
> > IDE and ICE). It's not worth the time and effort
> of doing it 
> > yourself, unless you're into that sort of thing
> (maybe you should get 
> > out more if you are?). We don't use any built-in
> library functions, 
> > so library size isn't an issue for us. The reason
> I like it (apart 
> > from the cost!) is the lack of bugs in the code
> generation, unlike 
> > ither commercial compilers I've used. Reasons for
> not liking it are 
> > the usual (limited support, overwhelming
> documentation etc. etc.). 
> > 
> > --- In lpc2000@yahoogroups.com, Sten <list@n...>
> wrote:
> > >
> > > \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd \ufffd\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd wrote:
> > > >>Alex, 
> > > >>
> > > >>
> > > >>>b> Just one data point, but: I'm a
> professional developer (30 
> > > >>>years s/w 
> > > >>>b> development experience from micros to
> mainframes).  Now 
> > working 
> > > >>>on 
> > > >>>b> third LPC-based commercial product. 
> Compared Keil, IAR, 
> > > >>>and gcc and 
> > > >>>b> chose Rowley Crossworks (gcc-based).
> > > >>>
> > > >>>Oh, I can't hold out from the reply.
> > > >>>I tried to use Crossworks in the begining to
> explore LPC2xxx.
> > > >>>It ugly work with the structures. I tried to
> define T0MCR like
> > > >>> struct:
> > > >>>{{
> > > >>>typedef struct
> > > >>>  { 
> > > >>>    __REG32 MR0I :1;
> > > >>>    __REG32 MR0R :1;
> > > >>>    __REG32 MR0S :1;
> > > >>>
> > > >>>    __REG32 MR1I :1;
> > > >>>    __REG32 MR1R :1;
> > > >>>    __REG32 MR1S :1;
> > > >>>    
> > > >>>    __REG32 MR2I :1;
> > > >>>    __REG32 MR2R :1;
> > > >>>    __REG32 MR2S :1;
> > > >>>    
> > > >>>    __REG32 MR3I :1;
> > > >>>    __REG32 MR3R :1;
> > > >>>    __REG32 MR3S :1;    
> > > >>>    __REG32      :4;    
> > > >>>} __txmcr_bits;
> > > >>>
> > > >>>#define T0MCRbits (*(volatile __txmcr_bits
> *)0xE0004014)
> > > >>>
> > > >>>}}
> > > >>>
> > > >>>but when I handle to it, Crossworks GCC
> compile it to this code:
> > > >>>
> > > >>><<T0MCRbits.MR0I = 1;>>
> > > >>>
> > > >>>mov r3, #0xE0000000
> > > >>>add r3, r3, #0x00004000
> > > >>>add r3, r3, #0x00000014
> > > >>>ldrb r2, [r3]
> > > >>>orr r2, r2, #0x00000001
> > > >>>strb r2, [r3]
> > > >>>
> > > >>>so, I get change in LSB and
> _in_the_second_byte_!.
> > > >>
> > > >>And you tell me *why* this is incorrect code
> generation?  You 
> > might 
> > > >>not
> > > >>like what is generated, but is is *not*
> incorrect according to the
> > > >>standard.  It is only incorrect *if* you think
> volatile has some 
> > > >>extra
> > > >>meaning above what it does in the standard. 
> Or *if* you think an
> > > >>"unsigned long" bitfield is somehow
> "standard".  That is why the
> > > >>Embedded C TR has I/O support.  Volatile does
> *not* mean "I'm 
> > > >>dealing
> > > >>with a device" or "Access this data
> atomically".  Far from it.
> > > > 
> > > > 
> > > > I tried to explain my point of view in other
> mail.
> > > > The generated code works incorrectly because
> it use BYTE 
> > instructions. 
> > > > You can compile it, load into the chip and
> debug. 
=== message truncated ===



		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

I'm aware of what IAR provides.  I have worked with IAR.  In fact I
had compiled and ran my code under IAR when I got bit.  However, the
code had been originally developed with ARM-ELF-GCC, so I didn't use
the IAR defined registers.  Anyway we aren't using IAR.

I wont use bitfields, mainly because their behavior is not standard. 
What is their endianness?  Are they signed/unsigned?  What code is the
compiler going to emit?  Will the code really work with the peripheral?

IAR and GreenHills (and I believe GCC) give options to define this,
but why use it.  I've moved code from GCC to IAR to GreenHills, and
once I punted bitfields the code ported without issue.  If I had I'd
have to remember to set options with each program I create, or futz
around with pragma's or whatever the vendor's decide to do this
week/version.  

Keeping the code as portable as possible using appropriately sized
data types helps eliminate those issues by avoiding the problem to
begin with.


--- In lpc2000@yahoogroups.com, Mike Nelson <m1k3n3ls0n@y...> wrote:

>
> IAR's Embedded Workbench for ARM provides the 
> bit field definitions for the Special Function 
> Registers for most popular derivatives in C 
> header files.  No need to worry about C compiler 
> support.
> 
> Here is the list of Philips LPC2000 derivatives
> supported:
> 
> lpc210x
> lpc2114
> lpc2119
> lpc2124
> lpc2129
> lpc2130
> lpc2131
> lpc2132
> lpc2134
> lpc2136
> lpc2138
> lpc2142
> lpc2148
> lpc2194
> lpc2212
> lpc2214
> lpc2292
> lpc2294
> 
> Also, there is debugger register display down to 
> the bitfield for all the special function registers 
> in the listed derivatives.
> 
> --- Alan Strickland <thestricnine@y...> wrote:
> 
> > I agree, avoid using bit fields.  How bit fields are
> > implemented is
> > compiler dependent.  Granted many (all?) compilers
> > give the option of
> > signed/unsigned and such, but I'd prefer to avoid
> > that issue entirely.
> >  Plus accessing individual bits can be wasteful as
> > far as code size is
> > concerned, and flat out may not give the results you
> > want.
> > 
> > Last year I had one piece of code that crashed the
> > system when it ran.
> >  I was setting up the EMC register and GPIO for
> > external RAM by using
> > bit fields, and the code died a miserable death. 
> > After I replaced it
> > with simple register assignments it worked. I
> > learned my lesson and
> > ripped out every bit field definition I had.  Bit
> > fields are in the
> > grey area of C/C++ standards and are probably best
> > left out of code.
> > 
> > 
> > David
> > 
> > --- In lpc2000@yahoogroups.com, "brendanmurphy37"
> > <brendan.murphy@i...> wrote:
> > >
> > > 
> > > At the risk of adding yet more controversy to what
> > is getting to be a 
> > > somewhat heated discussion, can I suggest that
> > access to hardware 
> > > registers is best done using something like:
> > > 
> > > 1. Define general MACRO in some hardware-specific
> > include file:
> > > 
> > > #define REG(addr) (*(volatile unsigned int
> > *)(addr))
> > > 
> > > 1. Define machine registers in some include file:
> > > 
> > > /* example is I2C control register */
> > > 
> > > #define I2C_I2CONSET  (0xE001C000) /* ctrl set reg
> > */
> > > 
> > > 3. Use as follows:
> > > 
> > > REG(I2C_I2CONSET) = 0x44;   /* set I2EN and AA */
> > > 
> > > As an alternative, you can define extra values as
> > follows:
> > > 
> > > #define	I2C_BIT_AA   (0x04)
> > > #define	I2C_BIT_SI   (0x08)
> > > #define	I2C_BIT_STO  (0x10)
> > > #define	I2C_BIT_STA  (0x20)
> > > #define	I2C_BIT_I2EN (0x40)
> > > 
> > > and use as follows:
> > > 
> > > REG(I2C_I2CONSET) = I2C_BIT_I2EN | I2C_BIT_AA;
> > > 
> > > This has the advantage of:
> > > 
> > > - it always works, regardless of compiler,
> > optimisation settings, 
> > > time of day,....
> > > - it's easy to follow (or as easy as any other
> > alternative)
> > > - it's invariably efficiently encoded by the
> > compiler
> > > 
> > > Contrast this with the number of questions you see
> > on why particular 
> > > bit-field constructs mapped to hardware registers
> > don't work, and it 
> > > might change your mind on how to do this.
> > > 
> > > Regards
> > > Brendan Murphy
> > > 
> > > P.S. On the main topic, I've used GCC on and off
> > for maybe ten years 
> > > now. I find it fine for professional development,
> > PROVIDED someone 
> > > else has set it up for the development system
> > being used (we use 
> > > Ashling for LPC2000 developments, which package it
> > nicely with their 
> > > IDE and ICE). It's not worth the time and effort
> > of doing it 
> > > yourself, unless you're into that sort of thing
> > (maybe you should get 
> > > out more if you are?). We don't use any built-in
> > library functions, 
> > > so library size isn't an issue for us. The reason
> > I like it (apart 
> > > from the cost!) is the lack of bugs in the code
> > generation, unlike 
> > > ither commercial compilers I've used. Reasons for
> > not liking it are 
> > > the usual (limited support, overwhelming
> > documentation etc. etc.). 
> > > 
> > > --- In lpc2000@yahoogroups.com, Sten <list@n...>
> > wrote:
> > > >
> > > > Àëåêñàíäð Áîðèñîâ wrote:
> > > > >>Alex, 
> > > > >>
> > > > >>
> > > > >>>b> Just one data point, but: I'm a
> > professional developer (30 
> > > > >>>years s/w 
> > > > >>>b> development experience from micros to
> > mainframes).  Now 
> > > working 
> > > > >>>on 
> > > > >>>b> third LPC-based commercial product. 
> > Compared Keil, IAR, 
> > > > >>>and gcc and 
> > > > >>>b> chose Rowley Crossworks (gcc-based).
> > > > >>>
> > > > >>>Oh, I can't hold out from the reply.
> > > > >>>I tried to use Crossworks in the begining to
> > explore LPC2xxx.
> > > > >>>It ugly work with the structures. I tried to
> > define T0MCR like
> > > > >>> struct:
> > > > >>>{{
> > > > >>>typedef struct
> > > > >>>  { 
> > > > >>>    __REG32 MR0I :1;
> > > > >>>    __REG32 MR0R :1;
> > > > >>>    __REG32 MR0S :1;
> > > > >>>
> > > > >>>    __REG32 MR1I :1;
> > > > >>>    __REG32 MR1R :1;
> > > > >>>    __REG32 MR1S :1;
> > > > >>>    
> > > > >>>    __REG32 MR2I :1;
> > > > >>>    __REG32 MR2R :1;
> > > > >>>    __REG32 MR2S :1;
> > > > >>>    
> > > > >>>    __REG32 MR3I :1;
> > > > >>>    __REG32 MR3R :1;
> > > > >>>    __REG32 MR3S :1;    
> > > > >>>    __REG32      :4;    
> > > > >>>} __txmcr_bits;
> > > > >>>
> > > > >>>#define T0MCRbits (*(volatile __txmcr_bits
> > *)0xE0004014)
> > > > >>>
> > > > >>>}}
> > > > >>>
> > > > >>>but when I handle to it, Crossworks GCC
> > compile it to this code:
> > > > >>>
> > > > >>><<T0MCRbits.MR0I = 1;>>
> > > > >>>
> > > > >>>mov r3, #0xE0000000
> > > > >>>add r3, r3, #0x00004000
> > > > >>>add r3, r3, #0x00000014
> > > > >>>ldrb r2, [r3]
> > > > >>>orr r2, r2, #0x00000001
> > > > >>>strb r2, [r3]
> > > > >>>
> > > > >>>so, I get change in LSB and
> > _in_the_second_byte_!.
> > > > >>
> > > > >>And you tell me *why* this is incorrect code
> > generation?  You 
> > > might 
> > > > >>not
> > > > >>like what is generated, but is is *not*
> > incorrect according to the
> > > > >>standard.  It is only incorrect *if* you think
> > volatile has some 
> > > > >>extra
> > > > >>meaning above what it does in the standard. 
> > Or *if* you think an
> > > > >>"unsigned long" bitfield is somehow
> > "standard".  That is why the
> > > > >>Embedded C TR has I/O support.  Volatile does
> > *not* mean "I'm 
> > > > >>dealing
> > > > >>with a device" or "Access this data
> > atomically".  Far from it.
> > > > > 
> > > > > 
> > > > > I tried to explain my point of view in other
> > mail.
> > > > > The generated code works incorrectly because
> > it use BYTE 
> > > instructions. 
> > > > > You can compile it, load into the chip and
> > debug. 
> === message truncated ===
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com
>

Hi,

I am migrating a serial communications interface (Modbus) to a LPC2138 
processor. The Modbus spec defines that an end of message has occurred 
when a period equal to 3.5 characters has passed since the last 
character has been received.

The LPC uart can generate an interrupt if the receive buffer has 
characters in it and no character has been received for a period of 3.5 
- 4.5 characters.

I would like to use this feature for detecting the end of a received 
message. The problem I have is that if I service an interrupt due the 
the buffer being filled, and it also happens that that last character in 
the buffer was the last character for the received message, the receive 
time-out interrupt will not occur, resulting in the end of message not 
being detected.

Is there a solution, other than using a buffer length of 1 and using a 
timer to measure the inter message gap?

Cheers,

Peter.

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Hi,
> 
> I am migrating a serial communications interface (Modbus) to a 
LPC2138 
> processor. The Modbus spec defines that an end of message has 
occurred 
> when a period equal to 3.5 characters has passed since the last 
> character has been received.
> 
> The LPC uart can generate an interrupt if the receive buffer has 
> characters in it and no character has been received for a period of 
3.5 
> - 4.5 characters.
> 
> I would like to use this feature for detecting the end of a received 
> message. The problem I have is that if I service an interrupt due 
the 
> the buffer being filled, and it also happens that that last 
character in 
> the buffer was the last character for the received message, the 
receive 
> time-out interrupt will not occur, resulting in the end of message 
not 
> being detected.
> 
> Is there a solution, other than using a buffer length of 1 and using 
a 
> timer to measure the inter message gap?
> 
> Cheers,
> 
> Peter.
> 
> -- 
> ------------------------------------------------------------------
> Web:   www.homanndesigns.com
> email: homann@h...
> Phone: +61 421 601 665
> www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>
If you are interested in MODBUS slave for LPC213X email me 
and I can send you some code fot it 
Radim design@micronix.ca

Hi,

Thanks for the offer. I'd be interested in learning how to implement 
Modbus on the LPC. Anything you can send will be a big help as I'm new 
to the Arm processor.

Now my LPC2138 processor has locked up and not talking to the Philips 
flash utility. Hopefully I can get it working again.

Cheers,

Peter.



radim100 wrote:
> --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> 
>>Hi,
>>
>>I am migrating a serial communications interface (Modbus) to a 
> 
> LPC2138 
> 
>>processor. The Modbus spec defines that an end of message has 
> 
> occurred 
> 
>>when a period equal to 3.5 characters has passed since the last 
>>character has been received.
>>
>>The LPC uart can generate an interrupt if the receive buffer has 
>>characters in it and no character has been received for a period of 
> 
> 3.5 
> 
>>- 4.5 characters.
>>
>>I would like to use this feature for detecting the end of a received 
>>message. The problem I have is that if I service an interrupt due 
> 
> the 
> 
>>the buffer being filled, and it also happens that that last 
> 
> character in 
> 
>>the buffer was the last character for the received message, the 
> 
> receive 
> 
>>time-out interrupt will not occur, resulting in the end of message 
> 
> not 
> 
>>being detected.
>>
>>Is there a solution, other than using a buffer length of 1 and using 
> 
> a 
> 
>>timer to measure the inter message gap?
>>
>>Cheers,
>>
>>Peter.
>>
>>-- 
>>------------------------------------------------------------------
>>Web:   www.homanndesigns.com
>>email: homann@h...
>>Phone: +61 421 601 665
>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>>
> 
> If you are interested in MODBUS slave for LPC213X email me 
> and I can send you some code fot it 
> Radim design@...
> 
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

Peter Homann wrote:
> Hi,
> 
> I am migrating a serial communications interface (Modbus) to a LPC2138 
> processor. The Modbus spec defines that an end of message has occurred 
> when a period equal to 3.5 characters has passed since the last 
> character has been received.
> 
> The LPC uart can generate an interrupt if the receive buffer has 
> characters in it and no character has been received for a period of 3.5 
> - 4.5 characters.
> 
> I would like to use this feature for detecting the end of a received 
> message. The problem I have is that if I service an interrupt due the 
> the buffer being filled, and it also happens that that last character in 
> the buffer was the last character for the received message, the receive 
> time-out interrupt will not occur, resulting in the end of message not 
> being detected.
> 
> Is there a solution, other than using a buffer length of 1 and using a 
> timer to measure the inter message gap?
> 
> Cheers,
> 
> Peter.
> 

Hello Peter,

this interrupt was not designed for your needs. It should prevent a
communication from being stalled if some characters are trapped in queue
which is not full.
Just an idea: every time you receive a character reset a timer. If a
timer interrupt occure prior a line idle interrupt, you have not
received any characters for a certain time. It's ugly but should solve
your problem.

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/

Hi Sten,

Thanks for your reply. Yes, this is what I'm doing now with the PIC chip 
and was expecting to have to do on the Arm. As I'm new to it, I wasn't 
sure if there was a neater way to do it. I moving (Trying to) to the Arm 
for more Grunt.

Cheers,

peter

Sten wrote:
> Peter Homann wrote:
> 
>>Hi,
>>
>>I am migrating a serial communications interface (Modbus) to a LPC2138 
>>processor. The Modbus spec defines that an end of message has occurred 
>>when a period equal to 3.5 characters has passed since the last 
>>character has been received.
>>
>>The LPC uart can generate an interrupt if the receive buffer has 
>>characters in it and no character has been received for a period of 3.5 
>>- 4.5 characters.
>>
>>I would like to use this feature for detecting the end of a received 
>>message. The problem I have is that if I service an interrupt due the 
>>the buffer being filled, and it also happens that that last character in 
>>the buffer was the last character for the received message, the receive 
>>time-out interrupt will not occur, resulting in the end of message not 
>>being detected.
>>
>>Is there a solution, other than using a buffer length of 1 and using a 
>>timer to measure the inter message gap?
>>
>>Cheers,
>>
>>Peter.
>>
> 
> 
> Hello Peter,
> 
> this interrupt was not designed for your needs. It should prevent a
> communication from being stalled if some characters are trapped in queue
> which is not full.
> Just an idea: every time you receive a character reset a timer. If a
> timer interrupt occure prior a line idle interrupt, you have not
> received any characters for a certain time. It's ugly but should solve
> your problem.
> 
>   Sten
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

Hi, Peter. Have you verified your P0.14 is low during reset? It is 
required to automatically enter ISP if the ROM checksum is good 
(i.e., the ROM is not blank).

Guille

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Hi,
> 
> Thanks for the offer. I'd be interested in learning how to 
implement 
> Modbus on the LPC. Anything you can send will be a big help as I'm 
new 
> to the Arm processor.
> 
> Now my LPC2138 processor has locked up and not talking to the 
Philips 
> flash utility. Hopefully I can get it working again.
> 
> Cheers,
> 
> Peter.
> 
> 
> 
> radim100 wrote:
> > --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> > 
> >>Hi,
> >>
> >>I am migrating a serial communications interface (Modbus) to a 
> > 
> > LPC2138 
> > 
> >>processor. The Modbus spec defines that an end of message has 
> > 
> > occurred 
> > 
> >>when a period equal to 3.5 characters has passed since the last 
> >>character has been received.
> >>
> >>The LPC uart can generate an interrupt if the receive buffer has 
> >>characters in it and no character has been received for a period 
of 
> > 
> > 3.5 
> > 
> >>- 4.5 characters.
> >>
> >>I would like to use this feature for detecting the end of a 
received 
> >>message. The problem I have is that if I service an interrupt due 
> > 
> > the 
> > 
> >>the buffer being filled, and it also happens that that last 
> > 
> > character in 
> > 
> >>the buffer was the last character for the received message, the 
> > 
> > receive 
> > 
> >>time-out interrupt will not occur, resulting in the end of 
message 
> > 
> > not 
> > 
> >>being detected.
> >>
> >>Is there a solution, other than using a buffer length of 1 and 
using 

> > 
> > a 
> > 
> >>timer to measure the inter message gap?
> >>
> >>Cheers,
> >>
> >>Peter.
> >>
> >>-- 
> >>------------------------------------------------------------------
> >>Web:   www.homanndesigns.com
> >>email: homann@h...
> >>Phone: +61 421 601 665
> >>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> >>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> >>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
> >>
> > 
> > If you are interested in MODBUS slave for LPC213X email me 
> > and I can send you some code fot it 
> > Radim design@m...
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> ------------------------------------------------------------------
> Web:   www.homanndesigns.com
> email: homann@h...
> Phone: +61 421 601 665
> www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>

Hi Guille,

 From the schematic, P014 should by pulled low by the Philips utility 
via pin 7 of com port 0?

Cheers,

Peter.

Guillermo Prandi wrote:
> Hi, Peter. Have you verified your P0.14 is low during reset? It is 
> required to automatically enter ISP if the ROM checksum is good 
> (i.e., the ROM is not blank).
> 
> Guille
> 
> --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> 
>>Hi,
>>
>>Thanks for the offer. I'd be interested in learning how to 
> 
> implement 
> 
>>Modbus on the LPC. Anything you can send will be a big help as I'm 
> 
> new 
> 
>>to the Arm processor.
>>
>>Now my LPC2138 processor has locked up and not talking to the 
> 
> Philips 
> 
>>flash utility. Hopefully I can get it working again.
>>
>>Cheers,
>>
>>Peter.
>>
>>
>>
>>radim100 wrote:
>>
>>>--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I am migrating a serial communications interface (Modbus) to a 
>>>
>>>LPC2138 
>>>
>>>
>>>>processor. The Modbus spec defines that an end of message has 
>>>
>>>occurred 
>>>
>>>
>>>>when a period equal to 3.5 characters has passed since the last 
>>>>character has been received.
>>>>
>>>>The LPC uart can generate an interrupt if the receive buffer has 
>>>>characters in it and no character has been received for a period 
> 
> of 
> 
>>>3.5 
>>>
>>>
>>>>- 4.5 characters.
>>>>
>>>>I would like to use this feature for detecting the end of a 
> 
> received 
> 
>>>>message. The problem I have is that if I service an interrupt due 
>>>
>>>the 
>>>
>>>
>>>>the buffer being filled, and it also happens that that last 
>>>
>>>character in 
>>>
>>>
>>>>the buffer was the last character for the received message, the 
>>>
>>>receive 
>>>
>>>
>>>>time-out interrupt will not occur, resulting in the end of 
> 
> message 
> 
>>>not 
>>>
>>>
>>>>being detected.
>>>>
>>>>Is there a solution, other than using a buffer length of 1 and 
> 
> using 
> 
>>>a 
>>>
>>>
>>>>timer to measure the inter message gap?
>>>>
>>>>Cheers,
>>>>
>>>>Peter.
>>>>
>>>>-- 
>>>>------------------------------------------------------------------
>>>>Web:   www.homanndesigns.com
>>>>email: homann@h...
>>>>Phone: +61 421 601 665
>>>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
>>>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
>>>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>>>>
>>>
>>>If you are interested in MODBUS slave for LPC213X email me 
>>>and I can send you some code fot it 
>>>Radim design@m...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>
>>-- 
>>------------------------------------------------------------------
>>Web:   www.homanndesigns.com
>>email: homann@h...
>>Phone: +61 421 601 665
>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>>
> 
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

Alan Strickland wrote:
> I agree, avoid using bit fields.  How bit fields are implemented is
> compiler dependent.  Granted many (all?) compilers give the option of
> signed/unsigned and such, but I'd prefer to avoid that issue entirely.
>  Plus accessing individual bits can be wasteful as far as code size is
> concerned, and flat out may not give the results you want.
> 
> Last year I had one piece of code that crashed the system when it ran.
>  I was setting up the EMC register and GPIO for external RAM by using
> bit fields, and the code died a miserable death.  After I replaced it
> with simple register assignments it worked. I learned my lesson and
> ripped out every bit field definition I had.  Bit fields are in the
> grey area of C/C++ standards and are probably best left out of code.

Just to add to the 'never use bit-fields advice', here's an article
I found a while ago (where the author calls bit-fields brain-dead) ...

A 'C' Test: The 0x10 Best Questions for Would-be Embedded Programmers
by Nigel Jones

http://www.embedded.com/2000/0005/0005feat2.htm

I can relate an experience with bit-fields. I was using a TI DSP and
TI had provided a library that used bitfields. I dutifully wrote
additional code that looked similar. When I went use the code
over the PCI bus - things broke! The reason was that some PCI
devices expect 32-bit accesses, since the hardware (eg. a 32-bit
wide register) ignor the PCI bus byte enables. I took a look
at the assembler code produced by GCC and noticed that the
bit-field code was translated to by assembler commands.
For comparison I took that same code and built with Visual C++,
and it produced code that used 32-bit instructions (x86 host).

So, I never used bit-fields again ...

Cheers
Dave

At 01:23 PM 11/8/05 +0300, ????????? ??????? wrote:
>On Tue, 08 Nov 2005 04:47:49 -0500
>   Tom Walsh <tom@...> wrote:
> > vaneenbergen wrote:
> >
> >>That the first bit of the second byte also changed is very possible.
> >>This is de to the processor. The timer register should be handled in
> >>a 32 bit access. this is what i found out. so instead of these kind
> >>of structures i just handle them in 32-bit. this way it is also
> >>quicker, you can change all values at the same time.
> >>
> >>is this really the fault of the compiler?????
> >>
> >>
> > He didn't understand what it was that he wrote so how can he answer
> >that
> > question?
> >
> >
> > TomW
> >
>
>What you mean? I think it obviously, that it's really fault of
>compiler. I explain my point of view to Paul


The compiler is doing exactly what you told it to.  You've just 
(re)discovered that the behaviour of the construct you've used is 
completely non-portable.  It certainly doesn't port between 
architectures.  It doesn't port between compilers and it's possible that it 
might not port between compiler versions.

Bitfields are very seductive approaches to HW interfacing but after trying 
them several times I've come to the conclusion that they are far more 
effort than they are worth and are questionable even if you stick to the 
same compiler (and version) on the same architecture.

IMO the only thing bitfields are useful for is storing abstract flags and 
sub integer sized values in structure that you want to memory 
optimize.  They then act as a hint to the compiler that you want to use as 
little room as possible at the expense of extra runtime.  They are not even 
useful for binary file structures (they break across compilers/architecture 
there as well)..

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

> Just to add to the 'never use bit-fields advice', here's an article
> I found a while ago (where the author calls bit-fields brain-dead) ...

I would refine this:

Never use them for anything that does hardware accesses or has hardware 
dependencies.

I use them quite a bit for packing data into software structures because this 
allows me to do bit-wise packing without writing a whole bunch of shifter 
code. Being able to bit-pack structures easily can save a lot of space when 
creating large numbers of them.

Charles, I know you have said this before, but I disagree, IF the bit
fields are supplied by the compiler vendor.  Both IAR and KEIL provide
bit field definitions for the Philips parts' registers.

 

While they occasionally use different names, that is rare (e.g. IOSET1
vs. IO1SET) and is easily fixed with a define.  So they take
responsibility for endian-ness and making sure the bits line up.

 

 

Using bit fields makes the code much more readable than constants like
0x00040000.  You can use notation like #define regbit (1<<18), but that
is not as clear as IO0SET_bit.P0.18.  (did I do the shift right - err
left - correctly to get bit 18? Is the constant 0x00040000 correct for
bit 18?).... 

 

We used to hear the same things about writing in c - real programmers
write in assembler.  Now it is real programmers don't use bit fields.  

 

Bit fields are a tool.  Know how to use the tool and it can save time.
Even if I had to redefine the bit field defines to move to another
compiler, I think it is worth it.

 

My two cents.

 

Dan

 

 

  _____  

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf
Of Charles Manning
Sent: Wednesday, November 09, 2005 10:13 AM
To: lpc2000@yahoogroups.com
Subject: Re: [lpc2000] Bit-fields are brain-dead (was Looking to buy
compiler)

 


> Just to add to the 'never use bit-fields advice', here's an article
> I found a while ago (where the author calls bit-fields brain-dead) ...

I would refine this:

Never use them for anything that does hardware accesses or has hardware 
dependencies.

I use them quite a bit for packing data into software structures because
this 
allows me to do bit-wise packing without writing a whole bunch of
shifter 
code. Being able to bit-pack structures easily can save a lot of space
when 
creating large numbers of them.






SPONSORED LINKS 

Microprocessor
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2
=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=9
3&.sig=tsVC-J9hJ5qyXg0WPR0l6g>  

Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&
w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s
=93&.sig=DvJVNqC_pqRTm8Xq01nxwg>  

Pic microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microproces
sor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c
=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ>  

8051 microprocessor
<http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocess
or&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=
4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A>  

 

 

 

  _____  

YAHOO! GROUPS LINKS 

 

*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 

 

  _____  



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

Charles Manning wrote:
> I would refine this:
> 
> Never use them for anything that does hardware accesses or has hardware 
> dependencies.
> 
> I use them quite a bit for packing data into software structures because this 
> allows me to do bit-wise packing without writing a whole bunch of shifter 
> code. Being able to bit-pack structures easily can save a lot of space when 
> creating large numbers of them.
> 

Yeah, I like that refinement.

Dave

David Hawkins wrote:

>Alan Strickland wrote:
>  
>
>>I agree, avoid using bit fields.  How bit fields are implemented is
>>compiler dependent.  Granted many (all?) compilers give the option of
>>signed/unsigned and such, but I'd prefer to avoid that issue entirely.
>> Plus accessing individual bits can be wasteful as far as code size is
>>concerned, and flat out may not give the results you want.
>>
>>Last year I had one piece of code that crashed the system when it ran.
>> I was setting up the EMC register and GPIO for external RAM by using
>>bit fields, and the code died a miserable death.  After I replaced it
>>with simple register assignments it worked. I learned my lesson and
>>ripped out every bit field definition I had.  Bit fields are in the
>>grey area of C/C++ standards and are probably best left out of code.
>>    
>>
>
>Just to add to the 'never use bit-fields advice', here's an article
>I found a while ago (where the author calls bit-fields brain-dead) ...
>
>A 'C' Test: The 0x10 Best Questions for Would-be Embedded Programmers
>by Nigel Jones
>
>http://www.embedded.com/2000/0005/0005feat2.htm
>
>I can relate an experience with bit-fields. I was using a TI DSP and
>TI had provided a library that used bitfields. I dutifully wrote
>additional code that looked similar. When I went use the code
>over the PCI bus - things broke! The reason was that some PCI
>devices expect 32-bit accesses, since the hardware (eg. a 32-bit
>wide register) ignor the PCI bus byte enables. I took a look
>at the assembler code produced by GCC and noticed that the
>bit-field code was translated to by assembler commands.
>For comparison I took that same code and built with Visual C++,
>and it produced code that used 32-bit instructions (x86 host).
>
>So, I never used bit-fields again ...
>
>  
>
"A man should know his limiitations", heh.  Same with using code. 
Bitfields are usefull for tearing apart bit-packed fields within data or 
assembling it.  While you are correct in stating that use of a bitfield 
against a register which expects a finite length operation (32 bit in 
your case), it is not correct to condemn then out of hand just because 
you had a bad experience.  "you burn you learn"...

Take this for example, I access the LPC2138 clock this way:

======= begin regCTIME0_t ==========
typedef struct __attribute__ ((packed))
{
   uint  seconds:6;
   uint  reserved:2;
   uint  minutes:6;
   uint  reserved1:2;
   uint  hours:5;
   uint  reserved2:3;
   uint  dayOfWeek:3;
   uint  reserved3:5;
} rtcCTIME0_t;
========== snip ================

To use that structure against the clock, I do this:

========== readRTC() ============
void readRTC (struct tm *theTime)
{// read clock registers and return tm structure.
#if HAS_CLOCK==TRUE
rtcCTIME0_t ctime0;
rtcCTIME1_t ctime1;
rtcCTIME2_t ctime2;
      // grab time from consolidated.
   ctime0 = RTCCTIME0; ctime1 = RTCCTIME1; ctime2 = RTCCTIME2;
      // leisurely tear the packed time apart into individual time.
   theTime->tm_sec = ctime0.seconds;
   theTime->tm_min = ctime0.minutes;
   theTime->tm_hour = ctime0.hours;
   theTime->tm_mday = ctime1.dayOfMonth;
   theTime->tm_mon = ctime1.month;
   theTime->tm_year = ctime1.year;
   theTime->tm_wday = ctime0.dayOfWeek;
   theTime->tm_yday = ctime2.dayOfYear;
   theTime->tm_isdst = FALSE;
#endif
}
=========== snip ===============

Now, I would prefer to let the compiler figure out how it is going to 
access the bit fields within those long words instead of me ANDing and 
SHIFTing to extract data...  No?  Isn't the code more readable with 
"*theTime->tm_min = ctime0.minutes;*" instead of "*theTime->tm_min = 
(ctime0 & 0xf0) >> 4;*" ???


Regards,


TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------




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

Robert Adsett wrote:

>At 01:23 PM 11/8/05 +0300, ????????? ??????? wrote:
>  
>
>>On Tue, 08 Nov 2005 04:47:49 -0500
>>  Tom Walsh <tom@...> wrote:
>>    
>>
>>>vaneenbergen wrote:
>>>
>>>      
>>>
>>>>That the first bit of the second byte also changed is very possible.
>>>>This is de to the processor. The timer register should be handled in
>>>>a 32 bit access. this is what i found out. so instead of these kind
>>>>of structures i just handle them in 32-bit. this way it is also
>>>>quicker, you can change all values at the same time.
>>>>
>>>>is this really the fault of the compiler?????
>>>>
>>>>
>>>>        
>>>>
>>>He didn't understand what it was that he wrote so how can he answer
>>>that
>>>question?
>>>
>>>
>>>TomW
>>>
>>>      
>>>
>>What you mean? I think it obviously, that it's really fault of
>>compiler. I explain my point of view to Paul
>>    
>>
>
>
>The compiler is doing exactly what you told it to.  You've just 
>(re)discovered that the behaviour of the construct you've used is 
>completely non-portable.  It certainly doesn't port between 
>architectures.  It doesn't port between compilers and it's possible that it 
>might not port between compiler versions.
>
>Bitfields are very seductive approaches to HW interfacing but after trying 
>them several times I've come to the conclusion that they are far more 
>effort than they are worth and are questionable even if you stick to the 
>same compiler (and version) on the same architecture.
>
>IMO the only thing bitfields are useful for is storing abstract flags and 
>sub integer sized values in structure that you want to memory 
>optimize.  They then act as a hint to the compiler that you want to use as 
>little room as possible at the expense of extra runtime.  They are not even 
>useful for binary file structures (they break across compilers/architecture 
>there as well)..
>
>  
>

I agree with you for the most part.  However there are data records that 
other systems send to me in a packed format that I either write a lot of 
code to unmangle, or simply describe it using packed attribute and 
bitfield definitions.

What I don't agree with is your statement about "at the expense of extra 
runtime".   As an assembly programmer for many years, I would be hard 
pressed to come up with some of the code sequences that the compiler 
produces!

For the most part, I try not to be too specific about how I code 
something so that the compiler can take advantage of optimizing my 
code.  The more specific I get about how an operation should proceed, 
the less leeway I'm allowing the optimizer to take.  Todays' code 
optimizers are amazingly efficient!


Regards,

TomW


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
 
>  From the schematic, P014 should by pulled low by the Philips utility 
> via pin 7 of com port 0?
> 

It should be ... but maybe it's not. Check it as Guillermo suggested.
Try to do it manual.

Tom Walsh wrote:

>>So, I never used bit-fields again ...

Ok, So 'I never had a reason to use bit-fields since then' :)

> Bitfields are usefull for tearing apart bit-packed fields within data or 
> assembling it.  While you are correct in stating that use of a bitfield 
> against a register which expects a finite length operation (32 bit in 
> your case), it is not correct to condemn then out of hand just because 
> you had a bad experience.  "you burn you learn"...

Yes, this was definitely a learning experience - one I am sure
others will face - except perhaps for those reading this
thread.

Thanks for the pointers on legitimate uses of bit-fields.

Here's a question for you. What happens on different-endianness
machines regarding bit-fields? Eg. lets say you analyze FAT headers
(which was discussed a few emails back). If I recall correctly,
they used bitfields and packed structures.

Do the layouts of entries match on different endianness machines,
or do you have to be careful there too?


Cheers
Dave

David Hawkins wrote:

>Tom Walsh wrote:
>
>  
>
>>>So, I never used bit-fields again ...
>>>      
>>>
>
>Ok, So 'I never had a reason to use bit-fields since then' :)
>
>  
>
>>Bitfields are usefull for tearing apart bit-packed fields within data or 
>>assembling it.  While you are correct in stating that use of a bitfield 
>>against a register which expects a finite length operation (32 bit in 
>>your case), it is not correct to condemn then out of hand just because 
>>you had a bad experience.  "you burn you learn"...
>>    
>>
>
>Yes, this was definitely a learning experience - one I am sure
>others will face - except perhaps for those reading this
>thread.
>
>Thanks for the pointers on legitimate uses of bit-fields.
>
>Here's a question for you. What happens on different-endianness
>machines regarding bit-fields? Eg. lets say you analyze FAT headers
>(which was discussed a few emails back). If I recall correctly,
>they used bitfields and packed structures.
>
>Do the layouts of entries match on different endianness machines,
>or do you have to be careful there too?
>
>  
>
There has been much written about problems with Big-Endian processors 
and thier data, esp with type conversions.  I'll stick to Little-Endian.


TomW

>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Peter, whether or not the Philips utility turns P0.14 low is entirely 
dependent of your hardware connections!

In LPC2138, P0.14 is pin 41. For the LPC2138 to talk to the Philips 
utility, one of three things must happen:

1) You boot with a blank or invalid ROM.
2) You boot with P0.14 low (less than 0.8 volts on pin 41 during 
boot).
3) You intentionally call the Phillips boot loader from your LPC code.

In order to turn pin P0.14 low, you must get to know what is that pin 
connected to. For example, in the New Micros' Tini213/38 controller 
interface board, there's a jumper (J11) to set P0.14 to low/high. If 
you have the Tini2138 module alone, then it's pin 19 of the module 
that must be connected to GND. I know nothing about other development 
kits (or your hardware), but there's normally some mechanism allowing 
this kind of set up. I'm not aware of the RS-232 signal management of 
the Philips utility, but anyway in order to produce any effect on the 
P0.14 pin of the chip from the utility, some RS-232 signal (most 
likely RTS or DTR) must be connected through proper interfacing to 
pin P0.14 of the LPC.

Guille

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Hi Guille,
> 
>  From the schematic, P014 should by pulled low by the Philips 
utility 
> via pin 7 of com port 0?
> 
> Cheers,
> 
> Peter.
> 
> Guillermo Prandi wrote:
> > Hi, Peter. Have you verified your P0.14 is low during reset? It 
is 
> > required to automatically enter ISP if the ROM checksum is good 
> > (i.e., the ROM is not blank).
> > 
> > Guille
> > 
> > --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> > 
> >>Hi,
> >>
> >>Thanks for the offer. I'd be interested in learning how to 
> > 
> > implement 
> > 
> >>Modbus on the LPC. Anything you can send will be a big help as 
I'm 
> > 
> > new 
> > 
> >>to the Arm processor.
> >>
> >>Now my LPC2138 processor has locked up and not talking to the 
> > 
> > Philips 
> > 
> >>flash utility. Hopefully I can get it working again.
> >>
> >>Cheers,
> >>
> >>Peter.
> >>
> >>
> >>
> >>radim100 wrote:
> >>
> >>>--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>I am migrating a serial communications interface (Modbus) to a 
> >>>
> >>>LPC2138 
> >>>
> >>>
> >>>>processor. The Modbus spec defines that an end of message has 
> >>>
> >>>occurred 
> >>>
> >>>
> >>>>when a period equal to 3.5 characters has passed since the last 
> >>>>character has been received.
> >>>>
> >>>>The LPC uart can generate an interrupt if the receive buffer 
has 
> >>>>characters in it and no character has been received for a 
period 
> > 
> > of 
> > 
> >>>3.5 
> >>>
> >>>
> >>>>- 4.5 characters.
> >>>>
> >>>>I would like to use this feature for detecting the end of a 
> > 
> > received 
> > 
> >>>>message. The problem I have is that if I service an interrupt 
due 
> >>>
> >>>the 
> >>>
> >>>
> >>>>the buffer being filled, and it also happens that that last 
> >>>
> >>>character in 
> >>>
> >>>
> >>>>the buffer was the last character for the received message, the 
> >>>
> >>>receive 
> >>>
> >>>
> >>>>time-out interrupt will not occur, resulting in the end of 
> > 
> > message 
> > 
> >>>not 
> >>>
> >>>
> >>>>being detected.
> >>>>
> >>>>Is there a solution, other than using a buffer length of 1 and 
> > 
> > using 
> > 
> >>>a 
> >>>
> >>>
> >>>>timer to measure the inter message gap?
> >>>>
> >>>>Cheers,
> >>>>
> >>>>Peter.
> >>>>
> >>>>-- 
> >>>>----------------------------------------------------------------
--
> >>>>Web:   www.homanndesigns.com
> >>>>email: homann@h...
> >>>>Phone: +61 421 601 665
> >>>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> >>>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> >>>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade 
board

> >>>>
> >>>
> >>>If you are interested in MODBUS slave for LPC213X email me 
> >>>and I can send you some code fot it 
> >>>Radim design@m...
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>> 
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>-- 
> >>------------------------------------------------------------------
> >>Web:   www.homanndesigns.com
> >>email: homann@h...
> >>Phone: +61 421 601 665
> >>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> >>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> >>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
> >>
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> ------------------------------------------------------------------
> Web:   www.homanndesigns.com
> email: homann@h...
> Phone: +61 421 601 665
> www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>

Hi Guillermo,

THanks for the reply.  As P0.14 is connected to the serial port, I am 
assuming it is controlled by the Philips utility. I will verify that, 
but also control it manually.

Is it possible to erase the bootloader? Also, is the bootloader serial 
protocol documented somewhere?

Cheers,

Peter.

Guillermo Prandi wrote:
> Peter, whether or not the Philips utility turns P0.14 low is entirely 
> dependent of your hardware connections!
> 
> In LPC2138, P0.14 is pin 41. For the LPC2138 to talk to the Philips 
> utility, one of three things must happen:
> 
> 1) You boot with a blank or invalid ROM.
> 2) You boot with P0.14 low (less than 0.8 volts on pin 41 during 
> boot).
> 3) You intentionally call the Phillips boot loader from your LPC code.
> 
> In order to turn pin P0.14 low, you must get to know what is that pin 
> connected to. For example, in the New Micros' Tini213/38 controller 
> interface board, there's a jumper (J11) to set P0.14 to low/high. If 
> you have the Tini2138 module alone, then it's pin 19 of the module 
> that must be connected to GND. I know nothing about other development 
> kits (or your hardware), but there's normally some mechanism allowing 
> this kind of set up. I'm not aware of the RS-232 signal management of 
> the Philips utility, but anyway in order to produce any effect on the 
> P0.14 pin of the chip from the utility, some RS-232 signal (most 
> likely RTS or DTR) must be connected through proper interfacing to 
> pin P0.14 of the LPC.
> 
> Guille
> 
> --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> 
>>Hi Guille,
>>
>> From the schematic, P014 should by pulled low by the Philips 
> 
> utility 
> 
>>via pin 7 of com port 0?
>>
>>Cheers,
>>
>>Peter.
>>
>>Guillermo Prandi wrote:
>>
>>>Hi, Peter. Have you verified your P0.14 is low during reset? It 
> 
> is 
> 
>>>required to automatically enter ISP if the ROM checksum is good 
>>>(i.e., the ROM is not blank).
>>>
>>>Guille
>>>
>>>--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>Thanks for the offer. I'd be interested in learning how to 
>>>
>>>implement 
>>>
>>>
>>>>Modbus on the LPC. Anything you can send will be a big help as 
> 
> I'm 
> 
>>>new 
>>>
>>>
>>>>to the Arm processor.
>>>>
>>>>Now my LPC2138 processor has locked up and not talking to the 
>>>
>>>Philips 
>>>
>>>
>>>>flash utility. Hopefully I can get it working again.
>>>>
>>>>Cheers,
>>>>
>>>>Peter.
>>>>
>>>>
>>>>
>>>>radim100 wrote:
>>>>
>>>>
>>>>>--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I am migrating a serial communications interface (Modbus) to a 
>>>>>
>>>>>LPC2138 
>>>>>
>>>>>
>>>>>
>>>>>>processor. The Modbus spec defines that an end of message has 
>>>>>
>>>>>occurred 
>>>>>
>>>>>
>>>>>
>>>>>>when a period equal to 3.5 characters has passed since the last 
>>>>>>character has been received.
>>>>>>
>>>>>>The LPC uart can generate an interrupt if the receive buffer 
> 
> has 
> 
>>>>>>characters in it and no character has been received for a 
> 
> period 
> 
>>>of 
>>>
>>>
>>>>>3.5 
>>>>>
>>>>>
>>>>>
>>>>>>- 4.5 characters.
>>>>>>
>>>>>>I would like to use this feature for detecting the end of a 
>>>
>>>received 
>>>
>>>
>>>>>>message. The problem I have is that if I service an interrupt 
> 
> due 
> 
>>>>>the 
>>>>>
>>>>>
>>>>>
>>>>>>the buffer being filled, and it also happens that that last 
>>>>>
>>>>>character in 
>>>>>
>>>>>
>>>>>
>>>>>>the buffer was the last character for the received message, the 
>>>>>
>>>>>receive 
>>>>>
>>>>>
>>>>>
>>>>>>time-out interrupt will not occur, resulting in the end of 
>>>
>>>message 
>>>
>>>
>>>>>not 
>>>>>
>>>>>
>>>>>
>>>>>>being detected.
>>>>>>
>>>>>>Is there a solution, other than using a buffer length of 1 and 
>>>
>>>using 
>>>
>>>
>>>>>a 
>>>>>
>>>>>
>>>>>
>>>>>>timer to measure the inter message gap?
>>>>>>
>>>>>>Cheers,
>>>>>>
>>>>>>Peter.
>>>>>>
>>>>>>-- 
>>>>>>----------------------------------------------------------------
> 
> --
> 
>>>>>>Web:   www.homanndesigns.com
>>>>>>email: homann@h...
>>>>>>Phone: +61 421 601 665
>>>>>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
>>>>>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
>>>>>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade 
> 
> board
> 
>>>>>If you are interested in MODBUS slave for LPC213X email me 
>>>>>and I can send you some code fot it 
>>>>>Radim design@m...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>-- 
>>>>------------------------------------------------------------------
>>>>Web:   www.homanndesigns.com
>>>>email: homann@h...
>>>>Phone: +61 421 601 665
>>>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
>>>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
>>>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>> 
>>>
>>>
>>>
>>>
>>>
>>
>>-- 
>>------------------------------------------------------------------
>>Web:   www.homanndesigns.com
>>email: homann@h...
>>Phone: +61 421 601 665
>>www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
>>www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
>>www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>>
> 
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Hi Guillermo,
> 
> THanks for the reply.  As P0.14 is connected to the serial port, I 
am 
> assuming it is controlled by the Philips utility. I will verify 
that, 
> but also control it manually.

Please post your results re: the Philips utility controlling P0.14.  
The Olimex LPC2106 board doesn't make that assumption - there is a 
jumper.  Put it in place, hit reset, program the device, remove the 
jumper and hit reset; the program is running.

Richard

> 
> Is it possible to erase the bootloader? Also, is the bootloader 
serial 

> protocol documented somewhere?
> 
> Cheers,
> 
> Peter.

Richard,

Will do.

The schematic for the board and how P0.14 is controlled via the serial 
port 0 is posted on their website at;

http://www.keil.com/mcb2130/mcb2130-schematics.pdf

Cheers,

Peter.

rtstofer wrote:
> --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> 
>>Hi Guillermo,
>>
>>THanks for the reply.  As P0.14 is connected to the serial port, I 
> 
> am 
> 
>>assuming it is controlled by the Philips utility. I will verify 
> 
> that, 
> 
>>but also control it manually.
> 
> 
> Please post your results re: the Philips utility controlling P0.14.  
> The Olimex LPC2106 board doesn't make that assumption - there is a 
> jumper.  Put it in place, hit reset, program the device, remove the 
> jumper and hit reset; the program is running.
> 
> Richard
> 
> 
>>Is it possible to erase the bootloader? Also, is the bootloader 
> 
> serial 
> 
>>protocol documented somewhere?
>>
>>Cheers,
>>
>>Peter.
> 
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> .
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Richard,
> 
> Will do.
> 
> The schematic for the board and how P0.14 is controlled via the 
serial 
> port 0 is posted on their website at;
> 
> http://www.keil.com/mcb2130/mcb2130-schematics.pdf
> 
> Cheers,
> 
> Peter.

It might be a pretty dumb question on my part.  It must have worked 
or at least that was the intent.  That is a very nice design.  No 
jumpers to move, no buttons to press.  I like it!

Richard

Richard,

Yes, it had been working. I think I downloaded a Hex file for a 
processor other than the LPC2138 and then it seemed to stop working.

I don't think it is a hardware problem.

For the third time, is it possible to erase the boot loader or screw it up?

Cheers,

Peter.

rtstofer wrote:
> --- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
> 
>>Richard,
>>
>>Will do.
>>
>>The schematic for the board and how P0.14 is controlled via the 
> 
> serial 
> 
>>port 0 is posted on their website at;
>>
>>http://www.keil.com/mcb2130/mcb2130-schematics.pdf
>>
>>Cheers,
>>
>>Peter.
> 
> 
> It might be a pretty dumb question on my part.  It must have worked 
> or at least that was the intent.  That is a very nice design.  No 
> jumpers to move, no buttons to press.  I like it!
> 
> Richard
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> .
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Richard,
> 
> Yes, it had been working. I think I downloaded a Hex file for a 
> processor other than the LPC2138 and then it seemed to stop 
working.
> 
> I don't think it is a hardware problem.
> 
> For the third time, is it possible to erase the boot loader or 
screw it up?
> 
> Cheers,
> 
> Peter.

We need Philips to weigh in on this.  I noticed from the User Manual 
that IAP is prevented from overwriting the boot loader and I would 
expect the loader to protect itself when doing ISP.

Anything is possible but I would look around a little more before I 
worried about the loader.  For example, are you certain that P0.14 
is actally pulled low during reset?  I would look at it with a scope 
or logic probe (LED if I had to) just to be certain something else 
wasn't happening.

I would certainly look at the check box in the lower right corner of 
the Flash Utility window and make sure it was checked - Use DTR/RTS 
for Reset and Boot Loader Selection.  Certainly answers my dumb 
question!  I'll incorporate this concept when I design my board.

Richard

Peter Homann wrote:

>Richard,
>
>Yes, it had been working. I think I downloaded a Hex file for a 
>processor other than the LPC2138 and then it seemed to stop working.
>
>I don't think it is a hardware problem.
>
>For the third time, is it possible to erase the boot loader or screw it up?
>
>  
>
No, you cannot.  According to the Philips doc that 8K sector is 
protected from erasure.

Please refer to the Philips manual: "LPC213x User Manual" #UM10120, top 
of page 221.


TomW

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> Peter Homann wrote:
> 
> >Richard,
> >
> >Yes, it had been working. I think I downloaded a Hex file for a 
> >processor other than the LPC2138 and then it seemed to stop 
working.
> >
> >I don't think it is a hardware problem.
> >
> >For the third time, is it possible to erase the boot loader or 
screw it up?
> >
> >  
> >
> No, you cannot.  According to the Philips doc that 8K sector is 
> protected from erasure.
> 
> Please refer to the Philips manual: "LPC213x User Manual" 
#UM10120, top 
> of page 221.
> 
> 
> TomW

I read all around that paragraph.  But that's the word - it can't be 
overwritten.

Richard

Hi,

Thanks guys. I'll break out the test gear tonight.

 From what is being said, it is either a hardware problem, or the LPC is 
not entering boot mode.

I can hold P0.14 lo, then use a terminal program to issue '?' and see if 
there is  a response.

Do you know what the rest of the command set is?, or will the '?' 
character cause the boot loader to spit it out at me?

Cheers,

Peter.

rtstofer wrote:

> --- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> 
>>Peter Homann wrote:
>>
>>
>>>Richard,
>>>
>>>Yes, it had been working. I think I downloaded a Hex file for a 
>>>processor other than the LPC2138 and then it seemed to stop 
> 
> working.
> 
>>>I don't think it is a hardware problem.
>>>
>>>For the third time, is it possible to erase the boot loader or 
> 
> screw it up?
> 
>>> 
>>>
>>
>>No, you cannot.  According to the Philips doc that 8K sector is 
>>protected from erasure.
>>
>>Please refer to the Philips manual: "LPC213x User Manual" 
> 
> #UM10120, top 
> 
>>of page 221.
>>
>>
>>TomW
> 
> 
> I read all around that paragraph.  But that's the word - it can't be 
> overwritten.
> 
> Richard
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

At 04:13 PM 11/9/05 -0500, Tom Walsh wrote:
>Robert Adsett wrote:
> >
> >Bitfields are very seductive approaches to HW interfacing but after trying
> >them several times I've come to the conclusion that they are far more
> >effort than they are worth and are questionable even if you stick to the
> >same compiler (and version) on the same architecture.
> >
> >IMO the only thing bitfields are useful for is storing abstract flags and
> >sub integer sized values in structure that you want to memory
> >optimize.  They then act as a hint to the compiler that you want to use as
> >little room as possible at the expense of extra runtime.  They are not even
> >useful for binary file structures (they break across compilers/architecture
> >there as well)..
> >
> >
> >
>
>I agree with you for the most part.  However there are data records that
>other systems send to me in a packed format that I either write a lot of
>code to unmangle, or simply describe it using packed attribute and
>bitfield definitions.

Fair enough.  That works (until it doesn't).

>What I don't agree with is your statement about "at the expense of extra
>runtime".   As an assembly programmer for many years, I would be hard
>pressed to come up with some of the code sequences that the compiler
>produces!

Um, I think what I was writing about and what you read are two different 
things.  I was referring to the difference in time between accessing field 
a in the two following structures.

struct AA {
         int a : 1;
         int b : !:
         };

struct BB {
          int a;
         int b;
           };

Barring bit instructions access to the BB structure will be faster and take 
less code.  As I said abstract flags.

For hardware access I've found I can wrap up access in macros or functions 
nearly as quickly as I can create a structure with bitfield in it to 
provide the same access.  And since the bitfield form usually needs some 
form of information hiding anyway to provide a 'clean ' interface and I 
don't have to worry about how the compiler has defined items like bit order 
allocation and bitfields crossing boundaries (documentation that always 
seems to be hidden away no matter the compiler)  I've given up on bitfields 
having any use for hardware access.  YMMV


>For the most part, I try not to be too specific about how I code
>something so that the compiler can take advantage of optimizing my
>code.  The more specific I get about how an operation should proceed,
>the less leeway I'm allowing the optimizer to take.  Todays' code
>optimizers are amazingly efficient!

Yep, code clearly comment well and test.  Then consider optimizing IF there 
is a performance issue after considering alternate algorithms.  To quote 
Knuth "Premature optimization is the root of all evil".

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

--- In lpc2000@yahoogroups.com, Peter Homann <groups@h...> wrote:
>
> Hi,
> 
> Thanks guys. I'll break out the test gear tonight.
> 
>  From what is being said, it is either a hardware problem, or the 
LPC is 
> not entering boot mode.
> 
> I can hold P0.14 lo, then use a terminal program to issue '?' and 
see if 
> there is  a response.
> 
> Do you know what the rest of the command set is?, or will the '?' 
> character cause the boot loader to spit it out at me?

There's a bit of a discussion in the User Manual - in fact, I 
thought it was quite complete although I haven't tried to use it to 
implement a downloader.

Hi all,

Well I've got the MCB2130 talking to the Philips flash utility. Now I'm 
not sure why?

The only thing I can thing of is that I've rebooted the PC? how frustrating.

Regardless, thanks for all the help.

Now on to the real problem.

I'm trying to get FreeRTOS running on the LPC2138.

I can use the Keil demo compiler to compile the Keil demo to work.

I've managed to get the 2016 GCC demo compiled and downloaded to the 
board. Of course it doesn't work. :-)

I'm new to the ARM LPC2138, GCC and FreeRTOS, so it is a steep learning 
curve.

The LPC2016 GCC FreeRTOS demo is targeted at the Olimex board.

Can anyone point me to a demo targeted at the LPC2138 or at least point 
me in the right direction to configure RTOS for the LPC2138.

Once again that for the help with the flashing problem.

Cheers,

Peter.




Peter Homann wrote:
> Hi,
> 
> Thanks guys. I'll break out the test gear tonight.
> 
>  From what is being said, it is either a hardware problem, or the LPC is 
> not entering boot mode.
> 
> I can hold P0.14 lo, then use a terminal program to issue '?' and see if 
> there is  a response.
> 
> Do you know what the rest of the command set is?, or will the '?' 
> character cause the boot loader to spit it out at me?
> 
> Cheers,
> 
> Peter.
> 
> rtstofer wrote:
> 
> 
>>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>>
>>
>>>Peter Homann wrote:
>>>
>>>
>>>
>>>>Richard,
>>>>
>>>>Yes, it had been working. I think I downloaded a Hex file for a 
>>>>processor other than the LPC2138 and then it seemed to stop 
>>
>>working.
>>
>>
>>>>I don't think it is a hardware problem.
>>>>
>>>>For the third time, is it possible to erase the boot loader or 
>>
>>screw it up?
>>
>>
>>>>
>>>No, you cannot.  According to the Philips doc that 8K sector is 
>>>protected from erasure.
>>>
>>>Please refer to the Philips manual: "LPC213x User Manual" 
>>
>>#UM10120, top 
>>
>>
>>>of page 221.
>>>
>>>
>>>TomW
>>
>>
>>I read all around that paragraph.  But that's the word - it can't be 
>>overwritten.
>>
>>Richard
>>
>>
>>
>>
>>
>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>
>>
> 
> 

-- 
------------------------------------------------------------------
Web:   www.homanndesigns.com
email: homann@...
Phone: +61 421 601 665
www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board

I have ported some samples for the MBC2130 and GCC that I can send you 
if you like. No FreeRTOS yet I'm affraid.

The samples I ported is the

blink_switch
blink_switch_irq
ds18s20 (some bugs fixed also in the 1-wire code which is now more stable.)
uart0
uart0_irq

Cheers
/Ake

Peter Homann wrote:

> Hi all,
>
> Well I've got the MCB2130 talking to the Philips flash utility. Now I'm
> not sure why?
>
> The only thing I can thing of is that I've rebooted the PC? how 
> frustrating.
>
> Regardless, thanks for all the help.
>
> Now on to the real problem.
>
> I'm trying to get FreeRTOS running on the LPC2138.
>
> I can use the Keil demo compiler to compile the Keil demo to work.
>
> I've managed to get the 2016 GCC demo compiled and downloaded to the
> board. Of course it doesn't work. :-)
>
> I'm new to the ARM LPC2138, GCC and FreeRTOS, so it is a steep learning
> curve.
>
> The LPC2016 GCC FreeRTOS demo is targeted at the Olimex board.
>
> Can anyone point me to a demo targeted at the LPC2138 or at least point
> me in the right direction to configure RTOS for the LPC2138.
>
> Once again that for the help with the flashing problem.
>
> Cheers,
>
> Peter.
>
>
>
>
> Peter Homann wrote:
> > Hi,
> >
> > Thanks guys. I'll break out the test gear tonight.
> >
> >  From what is being said, it is either a hardware problem, or the 
> LPC is
> > not entering boot mode.
> >
> > I can hold P0.14 lo, then use a terminal program to issue '?' and 
> see if
> > there is  a response.
> >
> > Do you know what the rest of the command set is?, or will the '?'
> > character cause the boot loader to spit it out at me?
> >
> > Cheers,
> >
> > Peter.
> >
> > rtstofer wrote:
> >
> >
> >>--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
> >>
> >>
> >>>Peter Homann wrote:
> >>>
> >>>
> >>>
> >>>>Richard,
> >>>>
> >>>>Yes, it had been working. I think I downloaded a Hex file for a
> >>>>processor other than the LPC2138 and then it seemed to stop
> >>
> >>working.
> >>
> >>
> >>>>I don't think it is a hardware problem.
> >>>>
> >>>>For the third time, is it possible to erase the boot loader or
> >>
> >>screw it up?
> >>
> >>
> >>>>
> >>>No, you cannot.  According to the Philips doc that 8K sector is
> >>>protected from erasure.
> >>>
> >>>Please refer to the Philips manual: "LPC213x User Manual"
> >>
> >>#UM10120, top
> >>
> >>
> >>>of page 221.
> >>>
> >>>
> >>>TomW
> >>
> >>
> >>I read all around that paragraph.  But that's the word - it can't be
> >>overwritten.
> >>
> >>Richard
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
> -- 
> ------------------------------------------------------------------
> Web:   www.homanndesigns.com
> email: homann@...
> Phone: +61 421 601 665
> www.homanndesigns.com/ModIO.html         - Modbus Interface Unit
> www.homanndesigns.com/DigiSpeedDeal.html - DC Spindle control
> www.homanndesigns.com/TurboTaig.html     - Taig Mill Upgrade board
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>


-- 
 ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      
Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org



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

Tom,

I think you hit the nail on the head on both the "pro" and "anti" case 
for using bit-fields for accessing hardware, with your statement:

> 
> Now, I would prefer to let the compiler figure out how it is going to 
> access the bit fields within those long words instead of me ANDing 
and 
> SHIFTing to extract data...  No?  Isn't the code more readable with 
> "*theTime->tm_min = ctime0.minutes;*" instead of "*theTime->tm_min = 
> (ctime0 & 0xf0) >> 4;*" ???
> 

Pro bit-field: "the code is more readable"
Anti bit-field: "let the compiler figure it out"

The point on the "anti" side is, the compiler WILL figure it out, in 
any way it chooses. Yes, I've no doubt the code sample you gave works, 
but will it work with a different compiler? a new revision of the same 
compiler? a new set of optimisation flags? I don't know, and I can't 
see how anyone would. There's just too much flexibility available for 
the compiler to generate whatever it wants, whilst still conforming to 
ANSI 'C', to guarantee it will place stuff where you want it, and with 
the access restrictions required (always using 32-bit access for h/w 
registers for example).

I remain to be convinced: the only argument I've seen on the "pro" side 
is your one on readability. However, if you're that upset about "ctime0 
& 0xf0) >> 4;" (and I can see why!), the pre-processor can be used. 
It's not ideal, but it can certainly get you closer to where we'd all 
want to be (easy to read code that is guaranteed to always work).

I just don't see the effort and risks involved in using bit-fields as 
you suggest is worth it. The effort involved in verifying the compiler 
generates exactly what you want, every time you change a compiler flag, 
or version, or compiler, just isn't worth it. Of course, you could 
always skip the verification stage, cross your fingers and hope nothing 
bad happens.....

By the way, I think readability is extremely important: in other cases, 
it is way more important to use language features appropriately to 
clarify intent. Just that in this case, it is just asking for trouble.

I remain to be convinced otherwise!

Brendan

Dan,

I take your point: if a compiler vendor has taken the trouble to 
provide an easy-to-use and readable mechanism to access h/w 
registers, then why not use it? Good point.

If you're happy to stick with one vendor, that's fine. However, be 
very aware that if you ever have to move the code to a different 
compiler for whatever reason, you will be faced with a **lot** of 
verification with an existing or modified set of bit-fields - see 
another reply of mine on this topic.

I don't think it accidental that commercial compiler vendors 
implement this stuff in the way that do. It enables them to 
claim "easy support of target hardware". Don't get be wrong: this 
claim is true, and it will save you time and effort. It also happens 
to be extremely non-portable (to another compiler). Just be aware....

By the way, I don't buy the "h/w access is always non-portable" 
argument for this one: it is perfectly possible to write pure 
ANSI 'C' code hardware drivers that are both correct and readable and 
will compile on any compiler. Using bit-fields is not the way I'd 
choose to do it however.

Brendan

--- In lpc2000@yahoogroups.com, "Dan Beadle" <dan.beadle@i...> wrote:
>
> Charles, I know you have said this before, but I disagree, IF the 
bit
> fields are supplied by the compiler vendor.  Both IAR and KEIL 
provide
> bit field definitions for the Philips parts' registers.
> 
>  
> 
> While they occasionally use different names, that is rare (e.g. 
IOSET1
> vs. IO1SET) and is easily fixed with a define.  So they take
> responsibility for endian-ness and making sure the bits line up.
> 
>  
> 
>  
> 
> Using bit fields makes the code much more readable than constants 
like
> 0x00040000.  You can use notation like #define regbit (1<<18), but 
that
> is not as clear as IO0SET_bit.P0.18.  (did I do the shift right - 
err
> left - correctly to get bit 18? Is the constant 0x00040000 correct 
for
> bit 18?).... 
> 
>  
> 
> We used to hear the same things about writing in c - real 
programmers
> write in assembler.  Now it is real programmers don't use bit 
fields.  
> 
>  
> 
> Bit fields are a tool.  Know how to use the tool and it can save 
time.
> Even if I had to redefine the bit field defines to move to another
> compiler, I think it is worth it.
> 
>  
> 
> My two cents.
> 
>  
> 
> Dan
> 
>  
> 
>  
> 
>   _____  
> 
> From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On 
Behalf
> Of Charles Manning
> Sent: Wednesday, November 09, 2005 10:13 AM
> To: lpc2000@yahoogroups.com
> Subject: Re: [lpc2000] Bit-fields are brain-dead (was Looking to buy
> compiler)
> 
>  
> 
> 
> > Just to add to the 'never use bit-fields advice', here's an 
article
> > I found a while ago (where the author calls bit-fields brain-
dead) ...
> 
> I would refine this:
> 
> Never use them for anything that does hardware accesses or has 
hardware 
> dependencies.
> 
> I use them quite a bit for packing data into software structures 
because
> this 
> allows me to do bit-wise packing without writing a whole bunch of
> shifter 
> code. Being able to bit-pack structures easily can save a lot of 
space
> when 
> creating large numbers of them.
> 
> 
> 
> 
> 
> 
> SPONSORED LINKS 
> 
> Microprocessor
> <http://groups.yahoo.com/gads?
t=ms&k=Microprocessor&w1=Microprocessor&w2
> 
=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s
=9
> 3&.sig=tsVC-J9hJ5qyXg0WPR0l6g>  
> 
> Microcontrollers
> <http://groups.yahoo.com/gads?
t=ms&k=Microcontrollers&w1=Microprocessor&
> 
w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4
&s
> =93&.sig=DvJVNqC_pqRTm8Xq01nxwg>  
> 
> Pic microcontrollers
> <http://groups.yahoo.com/gads?
t=ms&k=Pic+microcontrollers&w1=Microproces
> 
sor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor
&c
> =4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ>  
> 
> 8051 microprocessor
> <http://groups.yahoo.com/gads?
t=ms&k=8051+microprocessor&w1=Microprocess
> 
or&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&
c=

> 4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A>  
> 
>  
> 
>  
> 
>  
> 
>   _____  
> 
> YAHOO! GROUPS LINKS 
> 
>  
> 
> *	 Visit your group "lpc2000
> <http://groups.yahoo.com/group/lpc2000> " on the web.
> 	  
> *	 To unsubscribe from this group, send an email to:
> 	 lpc2000-unsubscribe@yahoogroups.com
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
> 	  
> *	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <http://docs.yahoo.com/info/terms/> . 
> 
>  
> 
>   _____  
> 
> 
> 
> [Non-text portions of this message have been removed]
>