Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Messages

Browse messages

Page 34 of 329 · 16407 messages matched

Re: [lpc2000] Re: For C novices

2006-03-31 by Clyde Stubbs

... Indeed. I d love to have a dollar for every time someone wrote such code, then complained when the code doesn t port unchanged to a different architecture

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by Thiadmer Riemersma (ITB CompuPhase)

This is what The C Programming Language 2nd edition (Kernighan & Ritchie) says (page 199): A pointer to one type may be converted to a pointer to another

Thread view Attachments: 0

RE: [lpc2000] Re: For C Experts

2006-03-31 by Paul Curtis

Hi, ... Bloody hell no. Insanity. -- Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3

Thread view Attachments: 0

RE: [lpc2000] Re: For C Experts

2006-03-31 by Paul Curtis

Hi, ... Are you just lucky, too, that the byte order of multi-byte items works? ;-) If you were porting from, say, a 68HC11 then you d be royally screwed with

Thread view Attachments: 0

RE: [lpc2000] Re: For C Experts

2006-03-31 by Paul Curtis

Hi, ... C90 has been a standard for 16 years which is more than long enough for engineering firms to understand that if they want to move up to 32 bits then

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by brendanmurphy37

This is also non-portable. Brendan ... problem, because the union is ... you ... compilers, ... objects. ... two

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by brendanmurphy37

Dave, Sorry to be blunt, but you are incorrect when you state the left and right are not the same types. This might explain why you think the compiler is in

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by Sten

Hello, Another solution I had last night which should fix the alignment-problem, because the union is compiler will align this union to its biggest member:

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by brendanmurphy37

Dave, ... should doesn t come into it! You have explicitley told the compiler exectly how you want it treated (the (int *) ). Now if you had one of those

Thread view Attachments: 0

Re: [lpc2000] DSP

2006-03-31 by David Hawkins

... I have the following book at home; ARM System Developer s Guide, First Edition : Designing and Optimizing System Software (The Morgan Kaufmann Series in

Thread view Attachments: 0

DSP

2006-03-31 by heedaf

Does anyone have a sample of C code for implementing a bandpass filter for the LPC21xx? Thanks, Dewayne

Thread view Attachments: 0

Re: Flashless LPC2210, flash download?

2006-03-31 by volunteer_sysu

Hello, Dominic I wonder whether I can use the schema of the JTAG in your document Open On-chip Debugger to make a JTAG interface. Then I can use it to debug

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by jayasooriah

Hi Dave, I see the problem you raise, but I am not sure if there is a clean solution. While all arrays may be packed, this does not mean that objects are not

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by Robert Adsett

... Another approach that makes a lot of sense its if this is going to/coming from a communications interface is to leave the structures alone (ie use the same

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by Robert Adsett

... I used a number that don t. Most notably the one for a CRAY XMP (64 bit alignment, except for character pointers) Robert Freedom has no meaning of

Thread view Attachments: 0

Re: Speech Recognition Software

2006-03-31 by dsidlauskas1

Thanks Leon. Unfortunately I need speaker independent recognition. Just the numbers one to 9 would be useful. Dave S. ... of using ... software, ... for the

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by Robert Adsett

... Sure they are the same type, you told the compiler they were the same type. It went away assuming that you knew what you were talking about. Silly

Thread view Attachments: 0

Re: [lpc2000] For C Experts

2006-03-31 by Robert Adsett

... As I said earlier I was curious as to what lint (in may case PC-Lint) would make of this. So I added the following to one of my files void check( void) {

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by dsidlauskas1

Jaya, The vanilla cast is only to be treated as a byte packed cast if the object that is being cast is itself byte packed. In thinking about my original

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by Robert Adsett

... ... It s more than weasel room it s an intimate and integral part of the language and has been for over 20 years. IE it s a PRE-ANSI requirement.

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by Robert Adsett

... Only if the compiler understands pragma packed(1) to mean byte alignment in the following structure. Far from a sure thing. The compiler is quite allowed

Thread view Attachments: 0

Re: [lpc2000] Re: For C Experts

2006-03-31 by David Hawkins

Here s a another couple of comments to provide you some context for this type of problem, i.e., of interpreting the contents of a binary data stream; Machine

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by garycordelli

Dave, Just a postscript: this is not an academic notion to which I allude, but a common error in just the kind of code I am paid to fix every day. The

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by jayasooriah

Dave, If I understand you (now more correctly): because byte packing is default, you want a vanilla cast (without __packed prefix) to be treated as byte packed

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by sonny945852001

Dave, x[4] = *ip; I thought array index in C starts at zero so valid index for x is only 0,1,2,3 ? Sonny

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by dsidlauskas1

Jaya, I don t think I m asking it to connect the two statements. What I m expecting it to do is to recognize that buf is a byte packed object (the defalt for

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by dsidlauskas1

Cordeg, Thanks for taking the time to comment. You ve presented a though case, but I m not going to let my compiler off so easily :-). In your case I think the

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by dsidlauskas1

Richard, The best Fortran programs are written after you spill the box of cards; rewriting the code may be faster and better. Been there. Done that. Thanks

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by jayasooriah

Dave, I think what you are asking of the compiler is to connect the two statements in the for() loop. Compilers do not have this capability. Even if it did,

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by garycordelli

Dave: While what you said may sound reasonable to humans, it is demonstrably not so certain in software. :-) To be specific, what you have in your original

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by Guillermo Prandi

This is indeed a strange piece of code: char buf[]={1,2,3,4,5,6,7,8}; int *ip, x[10]; for (i=0; i

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by rtstofer

... I guess I don t see why the compiler should do anything. You asked it to cast the ADDRESS of a byte in memory to an int * which is an address (by

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by dsidlauskas1

Jaya, Since the compiler knows that buf is a byte aligned object, woutldn t it be resonable for the compiler to treat (int *)&buf[i] as (__packed int *)&buf[i]

Thread view Attachments: 0

Re: For C Experts

2006-03-31 by dsidlauskas1

Brendan, You make a good case in your second paragraph. The exampe I ve presented is just a toy problem. The real case is porting a lot of old Z80 code where

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by dsidlauskas1

Jaya, Thanks. The x[4] was a blunder on my part when I wrote the message. Make it x[10]. Your second point is the key issue. Why can t the compiler understand

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by dsidlauskas1

ints are not always word aligned. For example: #pragma packed(1) struct eg { char x; int y; char z; int w; }test; One of the integers in this structure is not

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by jayasooriah

Dave, The satement x[4] = ... trashes memory where the the fifth element of the array x[] would normally exist, because you have declared it as x[4]

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by dsidlauskas1

Ed, Yes, __packed works, but I m porting a bunch of old 8 bit code that doesn t have this sort of problems and its hard to find all of the places where its

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by dsidlauskas1

OK. To the intent. I ve got a lot of code written for an 8 bit Z80 controller to port. It does a lot of parsing of data out of communications buffers, thus

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by jayasooriah

Dave, To us the unaligned pointer assignment is obvious when we look at it in context. To the compiler, that line alone is not enough to say that assignment is

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by brendanmurphy37

Dave, O.K. but your explicit type cast is effectively saying to the compiler I know what I m doing . I don t have any good C reference to hand, so I can t

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by dsidlauskas1

Brendan, The information to the compiler is in the line: ip = (int *)&buf[i]; Where it should be clear that the pointer is to an unaligned int. Dave S.

Thread view Attachments: 0

Re: For C Experts

2006-03-30 by jayasooriah

Hello Dave, I see two errors in the program that the KEIL compiler (justifiably IMHO) does not pick up. The first error, assignment #1 in for loop, explicitly

Thread view Attachments: 0

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.