From: <mat...@ph...> - 2004-05-23 21:03:55
|
Hello, I am new to the list. I am trying to get the Pic16 port of sdcc working with my 18f452. Actually, the current compiler works but it needs a picxxx.lib. I found the lib in the cvs and the source-package, but no binary file is included in the binary package. I tried to compile the file with sdcc pic18f452.c -c after this i got an .o file. I tried to convert this file with gplib to pic18f452.lib. It worked but sdcc still says: sdcc -mpic16 -p18f452 test.c Processor: 18f452 message: using default linker script "C:\Programme\gputils\lkr\18f452.lkr" error: missing definition for symbol "_INDF1" error: missing definition for symbol "_PRODL" error: missing definition for symbol "_STATUS" error: missing definition for symbol "_FSR0L" error: missing definition for symbol "_FSR1L" error: missing definition for symbol "_FSR2L" error: missing definition for symbol "_INDF2" error: missing definition for symbol "_POSTINC0" error: missing definition for symbol "_POSTDEC0" error: missing definition for symbol "_PCLATH" error: missing definition for symbol "_POSTINC1" error: missing definition for symbol "_POSTDEC1" error: missing definition for symbol "_POSTINC2" error: missing definition for symbol "_POSTDEC2" error: missing definition for symbol "_PRODH" error: missing definition for symbol "_FSR0H" error: missing definition for symbol "_FSR1H" error: missing definition for symbol "_FSR2H" error: missing definition for symbol "_PREINC0" error: missing definition for symbol "_PLUSW0" error: missing definition for symbol "_PCL" error: missing definition for symbol "_INTCON" error: missing definition for symbol "_PREINC1" error: missing definition for symbol "_WREG" error: missing definition for symbol "_PLUSW1" error: missing definition for symbol "_PREINC2" error: missing definition for symbol "_INDF0" error: missing definition for symbol "_PLUSW2" Do you know what i am doing wrong? It sounds like a decoration error. I am using winxp, the nightly build from 19.5 and 20.5.2004 and sdcc 2.4.0. yours Matthias |
From: Vangelis R. <vr...@ot...> - 2004-05-23 21:33:36
|
On Sun, 23 May 2004, [ISO-8859-15] Matthias H=E4nel wrote: > Hello, > > I am new to the list. I am trying to get the Pic16 port of sdcc > working with my 18f452. Actually, the current compiler works but it > needs a picxxx.lib. I found the lib in the cvs and the > source-package, but no binary file is included in the binary package. > I tried to compile the file with > > sdcc pic18f452.c -c > > after this i got an .o file. > I tried to convert this file with gplib to pic18f452.lib. > It worked but sdcc still says: > > sdcc -mpic16 -p18f452 test.c > Processor: 18f452 > message: using default linker script "C:\Programme\gputils\lkr\18f452.lkr= " > error: missing definition for symbol "_INDF1" > error: missing definition for symbol "_PRODL" > error: missing definition for symbol "_STATUS" > error: missing definition for symbol "_FSR0L" > error: missing definition for symbol "_FSR1L" > > Do you know what i am doing wrong? It sounds like a decoration error. =09Nothing wrong until here, you are just missing something... =09SDCC tries to find the pic18f452.lib in the standard directory, but obviously in the binary package these files are not created. If you have the .lib file in your current directory try adding a command line argument like, '-L.' when issuing SDCC. Another solution would be to place the pic18f452.lib file in the following directory: Find the directory where libraries are installed, in linux would be something like, /usr/local/share/sdcc/lib Then create a directory pic16 and put the pic18f452.lib there. Now every time you compile a file with SDCC the .lib file will be automatically found and linked with your object. Library files are not included in the binary package because they need gplib to be created, an executable which is part of the gputils package. The only way to create them is (in linux) : =091. issue a `./configure` and then `make` command in the device/lib/pic16 directory which will build the libraries =092. issue the command: 'make model-pic16' in the directory device/lib/ =093. then as root, issue 'make install' so all libraries are placed in their correct place. A bit tricky but necessery under current conditions! Regards, Vangelis |
From: <mat...@ph...> - 2004-05-24 20:18:27
|
Hi Vangelis, Thank you for your prompt answer. Actually, I don't understand how I can create the .lib file with gcc. I thought the lib-file is used by sdcc to compile for a specified target therefore the lib should be compiled with sdcc and assembled with gpasm or am I wrong? When I get the sdcc running on my system I will try to build a rs232 usb bridge and I expect some bugs in the sdcc ;) I have some experiences with compiler theories and build a scheme compiler on my own. I would love to provide patches (if i find any bugs :). Do you have some additional documentation on the internal structures of the sdcc-system (espacially the pic16-port)? I saw it's based on a bison .yy parser, the compiler itself and the port-dependend backend. best regards Matthias PS.: Years ago I was looking for a project like this and finally I found one :) Good job! >> "C:\Programme\gputils\lkr\18f452.lkr" >> error: missing definition for symbol "_INDF1" >> error: missing definition for symbol "_PRODL" >> error: missing definition for symbol "_STATUS" >> error: missing definition for symbol "_FSR0L" >> error: missing definition for symbol "_FSR1L" >> >> Do you know what i am doing wrong? It sounds like a decoration error. > Nothing wrong until here, you are just missing something... > SDCC tries to find the pic18f452.lib in the standard directory, > but obviously in the binary package these files are not created. > If you have the .lib file in your current directory try adding a command > line argument like, '-L.' when issuing SDCC. > Another solution would be to place the pic18f452.lib file in the following > directory: > Find the directory where libraries are installed, in linux would be > something like, /usr/local/share/sdcc/lib > Then create a directory pic16 and put the pic18f452.lib there. > Now every time you compile a file with SDCC the .lib file will be > automatically found and linked with your object. > Library files are not included in the binary package because they need > gplib to be created, an executable which is part of the gputils package. > The only way to create them is (in linux) : > 1. issue a `./configure` and then `make` command > in the device/lib/pic16 directory which will build the libraries > 2. issue the command: 'make model-pic16' in the directory > device/lib/ > 3. then as root, issue 'make install' so all libraries are placed > in their correct place. > A bit tricky but necessery under current conditions! > Regards, > Vangelis |
From: Vangelis R. <vr...@ot...> - 2004-05-24 20:48:12
|
----- Original Message ----- From: "Matthias H=E4nel" <matthias at php-site.de To: "Vangelis Rokas" <sdcc-user at lists.sourceforge.net> Subject: [Sdcc-user] Re: pic16 > Thank you for your prompt answer. Actually, I don't understand how I ca= n > create the .lib file with gcc. I thought the lib-file is used by sdcc t= o You will create the .lib file with gplib not with gcc! > compile for a specified target therefore the lib should be compiled wit= h > sdcc and assembled with gpasm or am I wrong? That's correct. But, if you run sdcc you won't be needing to use gpas= m to assemble the generated .asm file. SDCC is called with -c argument by the makefile so it creates an object file, which in turn is used directly by gplib to create the .lib archive. > When I get the sdcc running on my system I will try to build a rs232 us= b > bridge and I expect some bugs in the sdcc ;) I have some experiences wi= th What do you mean RS232-USB bridge? Which part are you going to use? I have been preparing a set of libraries (similar to the ADC,SPI,USART libraries Microchip provides with MPLAB), to be used with SDCC and pic16 port. Currently, only the ADC module is finished, and I am working now on the USART sources. Could you test them when they are finished? > compiler theories and build a scheme compiler on my own. I would love t= o > provide patches (if i find any bugs :). Do you have some additional Please do so. > documentation on the internal structures of the sdcc-system (espacially the > pic16-port)? I saw it's based on a bison .yy parser, the compiler itsel= f and > the port-dependend backend. Well, nothing else really except the sources themselves! I can provid= e you information for the pic16 port related structures (those found in the pic= 16 port headers, I guess). As far as the compiler-related structures it would be better to ask someone more experienced than I am. Regards. Vangelis |
From: <mat...@ph...> - 2004-05-24 20:22:24
|
Hello again, Today I tried to compile sdcc on my linux with installed gputils. Everything works except the pic - libs. When I run make in the pic16 directory the sdcc runs over all these .c files and .asm, rel .... are created but no .o file therefore gplib doesn't work properly :( I am not sure what I am doing wrong since I am on my windoze box and on my linux PC it doesn't compile :( best regards Matthias > Nothing wrong until here, you are just missing something... > SDCC tries to find the pic18f452.lib in the standard directory, > but obviously in the binary package these files are not created. > If you have the .lib file in your current directory try adding a command > line argument like, '-L.' when issuing SDCC. > Another solution would be to place the pic18f452.lib file in the following > directory: > Find the directory where libraries are installed, in linux would be > something like, /usr/local/share/sdcc/lib > Then create a directory pic16 and put the pic18f452.lib there. > Now every time you compile a file with SDCC the .lib file will be > automatically found and linked with your object. > Library files are not included in the binary package because they need > gplib to be created, an executable which is part of the gputils package. > The only way to create them is (in linux) : > 1. issue a `./configure` and then `make` command > in the device/lib/pic16 directory which will build the libraries > 2. issue the command: 'make model-pic16' in the directory > device/lib/ > 3. then as root, issue 'make install' so all libraries are placed > in their correct place. > A bit tricky but necessery under current conditions! > Regards, > Vangelis |
From: Paul B. <pau...@su...> - 2004-05-24 20:33:30
|
Hello again, This is a serious contribution. Anybody using PICs really should be thinking of assembler. sdcc is a superb product but I *really* don't believe that c is appropria= te for such small devices. May the debate continue. Paul :-) ----- Original Message ----- From: "Matthias H=E4nel" <mat...@ph...> To: "Vangelis Rokas" <sdc...@li...> Sent: Monday, May 24, 2004 9:24 PM Subject: [Sdcc-user] Re: pic16 > Hello again, > > Today I tried to compile sdcc on my linux with installed gputils. > Everything works except the pic - libs. When I run make in the pic16 > directory the sdcc runs over all these .c files and .asm, rel .... > are created but no .o file therefore gplib doesn't work properly :( > > I am not sure what I am doing wrong since I am on my windoze box and > on my linux PC it doesn't compile :( > > best regards > Matthias > > > > Nothing wrong until here, you are just missing something... > > > SDCC tries to find the pic18f452.lib in the standard directory, > > but obviously in the binary package these files are not created. > > If you have the .lib file in your current directory try adding a comm= and > > line argument like, '-L.' when issuing SDCC. > > > Another solution would be to place the pic18f452.lib file in the following > > directory: > > Find the directory where libraries are installed, in linux would be > > something like, /usr/local/share/sdcc/lib > > Then create a directory pic16 and put the pic18f452.lib there. > > Now every time you compile a file with SDCC the .lib file will be > > automatically found and linked with your object. > > > Library files are not included in the binary package because they nee= d > > gplib to be created, an executable which is part of the gputils packa= ge. > > The only way to create them is (in linux) : > > 1. issue a `./configure` and then `make` command > > in the device/lib/pic16 directory which will build the libraries > > 2. issue the command: 'make model-pic16' in the directory > > device/lib/ > > 3. then as root, issue 'make install' so all libraries are placed > > in their correct place. > > > A bit tricky but necessery under current conditions! > > > Regards, > > Vangelis > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: <mat...@ph...> - 2004-05-24 20:49:35
|
Hi Paul, > This is a serious contribution. Are you serious :) > Anybody using PICs really should be thinking of assembler. > sdcc is a superb product but I *really* don't believe that c is appropriate > for such small devices. I am sure assembly is useful but in most of the cases it is much more efficient to have greater overview of what you are doing than to have the best performance --> 90% of all cases I think. That's the same debate as it has taken place about 10 years in the field of personal computers. I think these day the "time to market" principle is much more important than to save some ticks :) Actually, I will not use the PIC for a commercial product, it's just for my personal studies on the PIC architecture and compiler building. > May the debate continue. may it? cheers Matthias |
From: Vangelis R. <vr...@ot...> - 2004-05-24 20:54:08
|
Surely assembly is strong and more suitable for such devices, but why writing so difficult to read/write/debug/improve code if it can be done in C? or even Pascal? In addition, you don't have to learn a specific assembler, just learn C that's enough. Its enough for the users that don't want a higly sophisticated firmware, but something that will work and the job they want. Vangelis ----- Original Message ----- From: "Paul Bartlett" <paul.bartlett at superh.com> To: <sdcc-user at lists.sourceforge.net> Subject: Re: [Sdcc-user] Re: pic16 > This is a serious contribution. > Anybody using PICs really should be thinking of assembler. > > sdcc is a superb product but I *really* don't believe that c is appropriate > for such small devices. > > May the debate continue. |
From: D H. <ill...@sl...> - 2004-05-24 23:22:27
|
As Matthias mentioned -- that debate was settled a decade ago with larger machines and is pretty easy to trend that way for these smaller machines. I started with PIC programming by using assembly to get an understanding of the machine and developed a few projects that way. Then I moved to PICC for C programming. I was impressed with it's code efficiency -- I MIGHT be able to hand code .asm that efficiently, but I couldn't begin to maintain it! SDCC doesn't produce code that efficient, but with enough users/contributors, I expect we'll get there! But time-to-market, long-term maintenance, and the growing size of available program memory make the efficiency less urgent, anyway. Doug |
From: Adam W. <awo...@re...> - 2004-05-25 17:11:59
|
On Mon, 24 May 2004, Vangelis Rokas wrote: > Surely assembly is strong and more suitable for such > devices, but why writing so difficult to read/write/debug/improve code > if it can be done in C? or even Pascal? Can this debate go somewhere else, please? This list is for the discussion of SDCC. SDCC stands for "small device C compiler". Debates about whether or not C should be used at all for this class of devices simply don't belong here. -- Adam Wozniak Remtrol Inc. Firmware Engineer 141 Suburban Rd. Suite A3 San Luis Obispo, CA 93401 |
From: Paul B. <pau...@su...> - 2004-05-25 18:00:35
|
Sorry, Adam, I have to disagree. This is the perfect forum for such discussions. I think it's entirely on-topic to question whether targetting PICs with high-level languages is appropriate. Ok, you can make it work but is it worthwhile? The PICs are capable beasts but crippling them by enforcing an inappropriate programming model does nobody any favours. I still think that part of any 'computer science' course should be the requirement to build a simple four function calculator around a microprocessor of the student's choice and write it in *assembler*. I despair when presented with a job candidate who is completely at sea unless presented with an IDE and source level debug. The day job involves doing silicon bringup where you can assume *nothing*. Sometimes I have had to resort to a single LED. Flash quickly for yes and slowly for no. It must flash or it's dead. I'm 47 now and am increasingly saddened that much of the art seems to be disappearing. Too few people now actually have a feeling for what's going on under the bonnet (hood). Paul :-( ----- Original Message ----- From: "Adam Wozniak" <awo...@re...> To: <sdc...@li...> Sent: Tuesday, May 25, 2004 6:11 PM Subject: Re: [Sdcc-user] Re: pic16 > On Mon, 24 May 2004, Vangelis Rokas wrote: > > Surely assembly is strong and more suitable for such > > devices, but why writing so difficult to read/write/debug/improve code > > if it can be done in C? or even Pascal? > > Can this debate go somewhere else, please? > > This list is for the discussion of SDCC. > SDCC stands for "small device C compiler". > > Debates about whether or not C should be used at all for this class > of devices simply don't belong here. > > -- > Adam Wozniak Remtrol Inc. > Firmware Engineer 141 Suburban Rd. Suite A3 > San Luis Obispo, CA 93401 > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Jean-Paul <tch...@fr...> - 2004-05-25 21:20:17
|
On Tue, 25 May 2004 19:02:17 +0100, Paul Bartlett =20 <pau...@su...> wrote: > Sorry, Adam, I have to disagree. > Sorry, Adam, I have to disagree too. Paul, I am 57 and much more saddened, and for a longer time, than you are= , =20 for the same reasons. Nearly twenty years ago, a customer was telling me: "all these young =20 people we hire now are comfortable with a keyboard, but no one knows how = =20 to polarize a transistor". Today, no one even knows what a transistor is :-( Since you write "bonnet" (hood) I suppose you live on the other side of =20 the Channel, and you also write disc (disk) and programme (program) as I = =20 learned at school ;-) Jean-Paul > The PICs are capable beasts but crippling them by enforcing an =20 > inappropriate > programming model does nobody any favours. > > I still think that part of any 'computer science' course should be the > requirement to build a simple four function calculator around a > microprocessor of the student's choice and write it in *assembler*. > > I despair when presented with a job candidate who is completely at sea > unless presented with an IDE and source level debug. > > The day job involves doing silicon bringup where you can assume =20 > *nothing*. > Sometimes I have had to resort to a single LED. Flash quickly for yes a= nd > slowly for no. It must flash or it's dead. > > I'm 47 now and am increasingly saddened that much of the art seems to b= e > disappearing. Too few people now actually have a feeling for what's =20 > going on > under the bonnet (hood). > > Paul :-( --=20 NEVER jump into a LOOP! |
From: Dave M. <mc...@ne...> - 2004-05-25 23:17:53
|
On May 25, 2004, at 5:24 PM, Jean-Paul wrote: >> Sorry, Adam, I have to disagree. >> > Sorry, Adam, I have to disagree too. > > Paul, I am 57 and much more saddened, and for a longer time, than you > are, for the same reasons. > Nearly twenty years ago, a customer was telling me: "all these young > people we hire now are comfortable with a keyboard, but no one knows > how to polarize a transistor". > Today, no one even knows what a transistor is :-( I know it's off-topic, but I have to join this rant. Guys, I'm only 35, and I'm with you 100% on this. My personal pet peeve this week has been people using email as a file transfer medium and not understanding why emailing a 35MB AutoCAD file is a bad idea, but the concepts are the same. They notice that it doesn't work very well, but the thought never occurs to them that it doesn't work well because they're *doing it the wrong way*. An acquaintance of mine just bought a brand-new Windows machine because her "old" one ("only" 2GHz!) "took too long to email long AutoCAD drawings". Her new computer (which ALSO has a 56Kbps modem) takes just as long...and she's angry about it. (!) Nobody feels the need to understand how anything works, even a little, and they don't get the fact that they'll be able to work more effectively and efficiently if they learn just a little bit about their tools. These days, peoples' general attitude seems to be "I don't care how or why it works...Just tell me where to click to make <xxx> happen!" ...it is sickening. Truly sickening. -Dave -- Dave McGuire "PC users only know two 'solutions'... Cape Coral, FL reboot and upgrade." -Jonathan Patschke |
From: Shehryar S. <she...@ul...> - 2004-05-26 08:52:57
|
----- Original Message ----- From: "Dave McGuire" <mc...@ne...> To: <sdc...@li...> Sent: Wednesday, May 26, 2004 12:17 AM Subject: Re: [Sdcc-user] Re: pic16 > On May 25, 2004, at 5:24 PM, Jean-Paul wrote: > >> Sorry, Adam, I have to disagree. > >> > > Sorry, Adam, I have to disagree too. > > > > Paul, I am 57 and much more saddened, and for a longer time, than you > > are, for the same reasons. > > Nearly twenty years ago, a customer was telling me: "all these young > > people we hire now are comfortable with a keyboard, but no one knows > > how to polarize a transistor". > > Today, no one even knows what a transistor is :-( > > I know it's off-topic, but I have to join this rant. > > Guys, I'm only 35, and I'm with you 100% on this. My personal pet > peeve this week has been people using email as a file transfer medium > and not understanding why emailing a 35MB AutoCAD file is a bad idea, > but the concepts are the same. They notice that it doesn't work very > well, but the thought never occurs to them that it doesn't work well > because they're *doing it the wrong way*. > > An acquaintance of mine just bought a brand-new Windows machine > because her "old" one ("only" 2GHz!) "took too long to email long > AutoCAD drawings". Her new computer (which ALSO has a 56Kbps modem) > takes just as long...and she's angry about it. (!) HAHA..LOL Chicks are stupid :P > > Nobody feels the need to understand how anything works, even a > little, and they don't get the fact that they'll be able to work more > effectively and efficiently if they learn just a little bit about their > tools. These days, peoples' general attitude seems to be "I don't care > how or why it works...Just tell me where to click to make <xxx> > happen!" ...it is sickening. Truly sickening. > > -Dave > > -- > Dave McGuire "PC users only know two 'solutions'... > Cape Coral, FL reboot and upgrade." -Jonathan Patschke > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Dave M. <mc...@ne...> - 2004-05-26 16:56:14
|
On May 26, 2004, at 4:58 AM, Shehryar Shaheen wrote: >> Guys, I'm only 35, and I'm with you 100% on this. My personal pet >> peeve this week has been people using email as a file transfer medium >> and not understanding why emailing a 35MB AutoCAD file is a bad idea, >> but the concepts are the same. They notice that it doesn't work very >> well, but the thought never occurs to them that it doesn't work well >> because they're *doing it the wrong way*. >> >> An acquaintance of mine just bought a brand-new Windows machine >> because her "old" one ("only" 2GHz!) "took too long to email long >> AutoCAD drawings". Her new computer (which ALSO has a 56Kbps modem) >> takes just as long...and she's angry about it. (!) > > HAHA..LOL > > Chicks are stupid :P This particular chick is likely smarter than you are. -Dave -- Dave McGuire "PC users only know two 'solutions'... Cape Coral, FL reboot and upgrade." -Jonathan Patschke |
From: Shehryar S. <she...@ul...> - 2004-05-26 19:07:08
|
----- Original Message ----- From: "Dave McGuire" <mc...@ne...> To: <sdc...@li...> Sent: Wednesday, May 26, 2004 5:56 PM Subject: Re: [Sdcc-user] Re: pic16 > On May 26, 2004, at 4:58 AM, Shehryar Shaheen wrote: > >> Guys, I'm only 35, and I'm with you 100% on this. My personal pet > >> peeve this week has been people using email as a file transfer medium > >> and not understanding why emailing a 35MB AutoCAD file is a bad idea, > >> but the concepts are the same. They notice that it doesn't work very > >> well, but the thought never occurs to them that it doesn't work well > >> because they're *doing it the wrong way*. > >> > >> An acquaintance of mine just bought a brand-new Windows machine > >> because her "old" one ("only" 2GHz!) "took too long to email long > >> AutoCAD drawings". Her new computer (which ALSO has a 56Kbps modem) > >> takes just as long...and she's angry about it. (!) > > > > HAHA..LOL > > > > Chicks are stupid :P > > This particular chick is likely smarter than you are. Don't get too excited over it it was just a commet and anyway it wasn't me who bought a new PC for emails that take too long > > -Dave > > -- > Dave McGuire "PC users only know two 'solutions'... > Cape Coral, FL reboot and upgrade." -Jonathan Patschke > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: Oracle 10g > Get certified on the hottest thing ever to hit the market... Oracle 10g. > Take an Oracle 10g class now, and we'll give you the exam FREE. > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: Dave M. <mc...@ne...> - 2004-05-26 19:50:16
|
On May 26, 2004, at 3:12 PM, Shehryar Shaheen wrote: >>>> Guys, I'm only 35, and I'm with you 100% on this. My personal >>>> pet >>>> peeve this week has been people using email as a file transfer >>>> medium >>>> and not understanding why emailing a 35MB AutoCAD file is a bad >>>> idea, >>>> but the concepts are the same. They notice that it doesn't work >>>> very >>>> well, but the thought never occurs to them that it doesn't work well >>>> because they're *doing it the wrong way*. >>>> >>>> An acquaintance of mine just bought a brand-new Windows machine >>>> because her "old" one ("only" 2GHz!) "took too long to email long >>>> AutoCAD drawings". Her new computer (which ALSO has a 56Kbps modem) >>>> takes just as long...and she's angry about it. (!) >>> >>> HAHA..LOL >>> >>> Chicks are stupid :P >> >> This particular chick is likely smarter than you are. > > Don't get too excited over it it was just a commet > > and anyway it wasn't me who bought a new PC for > emails that take too long True. This person is an architect who designs very large buildings. She (and everyone else in her line of work) just doesn't seem to think it's important to learn anything about the tools on which her work depends. -Dave -- Dave McGuire "PC users only know two 'solutions'... Cape Coral, FL reboot and upgrade." -Jonathan Patschke |
From: Adam W. <awo...@re...> - 2004-05-25 21:43:32
|
On Tue, 25 May 2004, Paul Bartlett wrote: > Sorry, Adam, I have to disagree. > > This is the perfect forum for such discussions. > > I think it's entirely on-topic to question whether targetting PICs with > high-level languages is appropriate. Ok, you can make it work but is it > worthwhile? > > The PICs are capable beasts but crippling them by enforcing an inappropriate > programming model does nobody any favours. > > I still think that part of any 'computer science' course should be the > requirement to build a simple four function calculator around a > microprocessor of the student's choice and write it in *assembler*. > > I despair when presented with a job candidate who is completely at sea > unless presented with an IDE and source level debug. > > The day job involves doing silicon bringup where you can assume *nothing*. > Sometimes I have had to resort to a single LED. Flash quickly for yes and > slowly for no. It must flash or it's dead. > > I'm 47 now and am increasingly saddened that much of the art seems to be > disappearing. Too few people now actually have a feeling for what's going on > under the bonnet (hood). I have written assembly. I have written microcode. I have a degree in Computer Engineering, and my day job is writing code for microcontrollers. Respectfully, there are people who don't care what you think, and many of them are intelligent and capable, and they will try until they make it work. Having people like you stand on the sidelines saying "you shouldn't do that" only slows those capable people down, and deprives the world of a useful tool. If you don't believe people should program C on small devices, why are you on the SDCC mailing list? "The art" is not disappearing. It is changing. There's a reason you don't hand assemble machine code a byte at a time and input it with toggle switches on the front of your home built Altair 8800 any more. There's a reason you use an assembler and a keyboard now. That same reason is why I prefer programming micros in C. It's not that I don't know HOW to program in assembly, it's that assembly is tedious and error prone. Just like toggling in bytes on the Altair 8800. Any tool that takes away the tedium and reduces the errors, making me more productive, is a good tool, and I'm not about to be a doubting thomas for someone who thinks they might want to spend their time making just such a tool. -- Adam Wozniak Remtrol Inc. Firmware Engineer 141 Suburban Rd. Suite A3 San Luis Obispo, CA 93401 |
From: Dave M. <mc...@ne...> - 2004-05-25 23:24:13
|
On May 25, 2004, at 5:43 PM, Adam Wozniak wrote: > "The art" is not disappearing. It is changing. I'm sorry Adam, but in my opinion, what's changing isn't "the art" (computer processors have been largely the same at the functional level for 35 years)...What's changing is the extent to which people are willing to sacrifice efficiency and clean design in order to make a quick buck. > There's a reason you > don't hand assemble machine code a byte at a time and input it with > toggle switches on the front of your home built Altair 8800 any more. > There's a reason you use an assembler and a keyboard now. That same > reason is why I prefer programming micros in C. It's not that I don't > know HOW to program in assembly, it's that assembly is tedious and > error prone. Just like toggling in bytes on the Altair 8800. This is the attitude that causes a major commercial operating system to require half a gigabyte of memory and a processor clocked at 1+GHz just to boot. I may be a curmudgeon, but personally, I don't care if efficiency has gone out of style. The fastest way isn't always the right way. -Dave -- Dave McGuire "PC users only know two 'solutions'... Cape Coral, FL reboot and upgrade." -Jonathan Patschke |
From: Bert D. <dri...@pl...> - 2004-05-25 00:35:37
|
On Mon, 24 May 2004, Paul Bartlett wrote: > This is a serious contribution. Yeah, but you would probably have done well to change the subject line. :-) It had become a bit tangential to the topic. > Anybody using PICs really should be thinking of assembler. > > sdcc is a superb product but I *really* don't believe that c is appropriate > for such small devices. I'm not personally familiar with the pic16, but the pic14 compiler in sdcc 2.4.0 miscompiled the first test program I threw at it. My laptop died on me (again!) so I've not been able to finish the test cases, let alone see if I could identify where to fix it... Currently, I think that without a solid understanding of pic14 assembly one should not attempt to use sdcc for the pic14 architecture. But I've got a tip for people who want to learn pic14 assembly: write your code in C, compile it with sdcc, then massage it into maintainable assembly. In the process, you will automatically clean up RAM allocations etcetera. Unlike other compilers I've seen, sdcc generates readable assembly. Both Matthias and Vangelis mentioned performance and ease of coding. If sdcc -mpic16 compiles complex code directly into a working .hex file, then indeed it is irrelevant that perhaps you waste a few bytes of RAM or Flash. However, the code I've seen from the -mpic14 suffered an avalanche effect: it wasted a few bytes, then had to generate bank switch code, then misoptimized it, and the net result is that the bank selection bits may be set incorrectly. If you have to debug miscompiled code, you'll quickly wish you started your project in assembler. In the commercial arena, one of sdcc -mpic14's alternatives is HiTech C. I've yet to see it miscompile any code I threw at it, but the assembly it generates is ugly as sin, and it doesn't support my target CPU unless I plonk down $750, and it won't run under the FreeBSD 4.7 linuxulator. Paul does have a point: C does not match the PIC architecture very well. It's not just the Harvard architecture with its incompatible address spaces that throws a spanner in the works; it's also in subtleties like the absence of true bit operators (BCF and BSF are byte operators, weird as it sounds), banking in both RAM and Flash with processor dependant aliasing in RAM, and complicated assembly to implement things like pointer dereferences. Besides, the advantage of high level languages quickly fades if you can't trust the generated code. Then again, the PIC16 appears to be a less messy design compared with the PIC14, and hey: if the generated code works I'll pick C any day over assembly. Cheers, -- Bert -- Bert Driehuis -- dri...@pl... -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! |
From: Vangelis R. <vr...@ot...> - 2004-05-24 20:37:06
|
----- Original Message ----- From: "Matthias H=E4nel" <mat...@ph...> To: "Vangelis Rokas" <sdc...@li...> Subject: [Sdcc-user] Re: pic16 > Today I tried to compile sdcc on my linux with installed gputils. > Everything works except the pic - libs. When I run make in the pic16 > directory the sdcc runs over all these .c files and .asm, rel .... > are created but no .o file therefore gplib doesn't work properly :( Did you run './configure' in the device/lib/pic16 directory? If you can't run configure, edit Makefile.common.in and replace all the @...@ references to their respective executables, i.e. @GPASM@ to gpasm Then it should work with a make in the device/lib/pic16 directory. Vangelis |
From: <mat...@ph...> - 2004-05-24 20:51:28
|
Hi Vangelis, Attachments: <none> Monday, May 24, 2004, 10:41:13 PM, you wrote: >> Today I tried to compile sdcc on my linux with installed gputils. >> Everything works except the pic - libs. When I run make in the pic16 >> directory the sdcc runs over all these .c files and .asm, rel .... >> are created but no .o file therefore gplib doesn't work properly :( > Did you run './configure' in the device/lib/pic16 directory? > If you can't run configure, edit Makefile.common.in and replace all > the @...@ references to their respective executables, > i.e. @GPASM@ to gpasm Yes, i did and it did recognize the gpasm and the gplib on my system. > Then it should work with a make in the device/lib/pic16 directory. That's what I did. I tried the snapshot from 19.05.2004 and the 2.4.0 release. best regards Matthias |
From: James C. <j.e...@st...> - 2004-05-24 23:55:24
|
Hi Matthias, I had similar problems (I think) generating .lib files on Win XP a few months back. Not really being a Linux user or understanding make files etc I wrote a little DOS batch file to do the job. I was also having problems with GPASM at the time so used MPASM instead. Here's the batch file, its a little crude and can only produce one library at a time: :: Generate library for SDCC PIC16 port :: James Chadd :: usage: make.bat <device> :: ie make.bat pic18F425 sdcc --pomit-config-words -mpic16 --pomit-ivt --no-peep --nostdinc -Ic:\sdcc\include\pic16 -S %1\%1.c "C:\Program Files\MPLAB IDE\MCHIP_Tools\MPASMWIN.exe" /q /w2 /o %1.asm gplib -c %1.lib %1.o move %1.lib c:\sdcc\lib\pic16 del %1.asm del %1.o del %1.err del %1.lst Cut & paste the above into a file called make.bat It must be located in the directory were the LIB files are, in my case this is: c:\sdcc\device\lib\pic16 usage is then: make.bat <device> i.e. make.bat pic18f452 which will compile the .c file in the pic18f452 director, assemble it and create a .lib file using gplink. The .lib file is then moved to c:\sdcc\lib\pic16 and the intermediate files deleted You will need to change the paths of SDCC and MPASM if they are in different places on you machine. GPLIB et al also need to be in the PATH variable. I've just tried this using SDCC 2.4.0 and GPLIB 0.12.0 alpha and it seems to produce the lib files. Hope this helps James At 22:53 24/05/2004 +0200, you wrote: >Hi Vangelis, > >Attachments: <none> >Monday, May 24, 2004, 10:41:13 PM, you wrote: > > >> Today I tried to compile sdcc on my linux with installed gputils. > >> Everything works except the pic - libs. When I run make in the pic16 > >> directory the sdcc runs over all these .c files and .asm, rel .... > >> are created but no .o file therefore gplib doesn't work properly :( > > > Did you run './configure' in the device/lib/pic16 directory? > > If you can't run configure, edit Makefile.common.in and replace all > > the @...@ references to their respective executables, > > i.e. @GPASM@ to gpasm > >Yes, i did and it did recognize the gpasm and the gplib on my system. > > > Then it should work with a make in the device/lib/pic16 directory. >That's what I did. > >I tried the snapshot from 19.05.2004 and the 2.4.0 release. > >best regards >Matthias > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: Oracle 10g >Get certified on the hottest thing ever to hit the market... Oracle 10g. >Take an Oracle 10g class now, and we'll give you the exam FREE. >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click >_______________________________________________ >Sdcc-user mailing list >Sdc...@li... >https://lists.sourceforge.net/lists/listinfo/sdcc-user |
From: <mat...@ph...> - 2004-05-25 20:04:57
|
Hello James, Attachments: <none> Tuesday, May 25, 2004, 1:59:40 AM, you wrote: > :: Generate library for SDCC PIC16 port > :: James Chadd > :: usage: make.bat <device> > :: ie make.bat pic18F425 > sdcc --pomit-config-words -mpic16 --pomit-ivt --no-peep --nostdinc > -Ic:\sdcc\include\pic16 -S %1\%1.c > "C:\Program Files\MPLAB IDE\MCHIP_Tools\MPASMWIN.exe" /q /w2 /o %1.asm > gplib -c %1.lib %1.o > move %1.lib c:\sdcc\lib\pic16 > del %1.asm > del %1.o > del %1.err > del %1.lst Thank you for the script. I realised it worked with the latest snapshot from 20.05.2004 and only with MPLAB-Assembler. Unfortunately, it doesn't work with the gpasm :( I tried this procedure by hand on my linux-box and it didn't work. But I copied the lib from my windows-system and now it works on both ;) @Vangelis: Did you know there is no -mpic16 switch in the makefile? I can't belive that the makefile works like it is. Actually, I tried all this by hand and the problem seems to be a gpasm - problem. It is still weird that everything works except the library compilation ;) I will try to find this bug or buglet on the upcoming weekend. best regards Matthias |
From: James C. <j.e...@st...> - 2004-05-27 23:13:38
|
Hi Vangelis, Feel free to add the script to the source distribution. Adding an option to SDCC to select assembler etc would be great, especially as GPutils is still in development, as it would allow bugs to be traced more easily. I'm not really using SDCC much at the moment. However I started developing code for my final year project (MP3 player using 18F452 , VS1001 & HDD) and was using SDCC very regulary (ie every day) for 1-1.5 months around Christmas last year. Unfortunately I ran into a serious SDCC bug, to do with passing pointers to functions and had to change to the CCSC PCH compiler, as I was getting near the project deadline. I didn't get round to reporting the bug at the time but it still appears in the 2.4.0 win32 build. The following code causes SDCC to terminate with the message: Caught signal 11: SIGSEGV #include <pic18F452.h> void foo(int *buff) { *buff=0; } void main(void) { int temp[1]; foo(temp); } I also had problems setting up references to single bits when the library system changed, however I can't remember the details except that all of my old code to do this stopped working so I jumped ship ;-) Hope this helps, James At 03:23 25/05/2004 +0300, you wrote: > Nice script. I think I should add it in the pic16 directory >to allow Windows users to build the libraries. > >Also, would it be of any use to allow the user to specify the >assembler and linker at run-time? (via a command line argument >for example) > > >Also James, >do you use pic16 port regularly? any problems/bugs? > >Vangelis |