From: Dave B. <da...@em...> - 2007-09-26 11:14:37
|
Cheers Robert. Had tried that, but unloaded, re-loaded etc just in case, no change. Still says no processor selected, I sort of suspect it hasn't got to ooking at the source files yet. Dave B. =20 > -----Original Message----- > From: sdc...@li...=20 > [mailto:sdc...@li...] On Behalf Of=20 > Robert Bergfors > Sent: Wednesday, September 26, 2007 11:54 AM > To: sdc...@li... > Subject: Re: [Sdcc-user] How to specify chip type (PIC's) ? >=20 > Lainaus Dave Baxter <da...@em...>: >=20 > > > > When I try a build (existing code from another environment) I get a=20 > > message to the extent that a processor has not been defined, and to=20 > > use -pPROCESSOR_NAME etc, to set it, and a long list of supported=20 > > types, including the one I want (16F877) >=20 > Personally I don't know of any other way than to specify it=20 > on the command line. > The "-mpic14" seems to have been chosen though...? > For example: >=20 > sdcc -mpic14 -p16f690 target.c >=20 > ...and then of cource #include the proper header files, like=20 > pic16f877.h or something like that. >=20 >=20 >=20 > BR, Robert > -- > sd...@ro... = This mail has been scanned by Palmer Cook Computer Services Limited. w= ww.palmercook.co.uk= |
From: Dave B. <da...@em...> - 2007-09-26 11:43:00
|
Hi Ken... Sort of agree that the problem may be caused by the way C::B builds the command line, but it's SDCC's output that shows the use of the -p option, not C::B's. The C::B forum's and web pages I've found so far (including that not very welcoming one) have not been of any help. Lot's of people seem to think that as even as a newbie C::B user, I should know all about it before using it. It's inbuilt help is not of much use either, sadly. Looks nice though!... OK, step back in time, a couple of decades or two to a DOS screen (XP's cmd box) .... Ah... SDCC has now seen the .c file, looks like I need to fully specify *All* the file paths needed on the command line. Wonderful, *not*..... (Where's me batchfile reference book gone this time!) Anyone know why sdcc doesn't work with dos's "| more" one-page-at-a-time option? "| more" seems to work OK with other dos like tools here, but not sdcc? :-( Dave B. > -----Original Message----- > From: sdc...@li...=20 > [mailto:sdc...@li...] On Behalf Of=20 > Ken Jackson > Sent: Wednesday, September 26, 2007 12:15 PM > To: sdc...@li... > Subject: [Sdcc-user] How to specify chip type (PIC's) ? >=20 > The command line shown does not have any -p switch on it. =20 >=20 > This shoulds like a Code::Blocks problem, not an SDCC problem. =20 > There is a forum site where you could post the question and=20 > you might get more helpful answers: <http://forums.codeblocks.org/> >=20 > As an experiment, you could just issue the correct command=20 > from the command prompt in a shell (a 'DOS box') and see if it works. >=20 > -Ken Jackson = This mail has been scanned by Palmer Cook Computer Services Limited. w= ww.palmercook.co.uk= |
From: Dave B. <da...@em...> - 2007-09-26 11:55:58
|
Related to all this.... What is SDCC's support of windows long file names? It's burping now on C:\Program Files\SDCC etc etc, showing the path as "Files\SDCC etc etc" So, it's now not even finding the source files. ..\source\etc.c doesn't work now either, it did 5 minutes ago! Confused.... As to the "| More" "feature". I also find that you can't redirect it's output to a file, as in... Aplication.exe > tmp.txt SDCC talking to the bios directly, or what? Dave B. =20 > -----Original Message----- > From: sdc...@li...=20 > [mailto:sdc...@li...] On Behalf Of=20 > Ken Jackson > Sent: Wednesday, September 26, 2007 12:15 PM > To: sdc...@li... > Subject: [Sdcc-user] How to specify chip type (PIC's) ? >=20 > The command line shown does not have any -p switch on it. =20 >=20 > This shoulds like a Code::Blocks problem, not an SDCC problem. =20 > There is a forum site where you could post the question and=20 > you might get more helpful answers: <http://forums.codeblocks.org/> >=20 > As an experiment, you could just issue the correct command=20 > from the command prompt in a shell (a 'DOS box') and see if it works. >=20 > -Ken Jackson >=20 > Dave Baxter writes: > ... > > However, try as I might, I can't seem to get the system to=20 > accept > "-p16f877" where and however I put it, so what's=20 > the *Exact* selection > procedure please... Can I reference=20 > it in the source? Or, will it only > be accepted on a=20 > command line parameter created mystically by > Code::Blocks? > > > > I have spent hours looking for help, but the various=20 > websites are of > next to zero help with this, either SDCC=20 > or Code::Blocks that is. > ... > > -------- > > Switching to target: default > > sdcc.exe -mpic14 -mpic14 -mpic14 -I"C:\Program=20 > Files\SDCC\include" > > -c kiss.c -o .objs\kiss.rel > > No processor has been specified (use -pPROCESSOR_NAME) >=20 > PIC14 processors and their characteristics: > ... >=20 >=20 > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user >=20 = This mail has been scanned by Palmer Cook Computer Services Limited. w= ww.palmercook.co.uk= |
From: Jean-Paul <tch...@fr...> - 2007-09-26 12:03:06
|
You are talking of problems I encounter when using Windows, be it with othe= r=20 applications: it is sometimes unpredictable. Are you sure you want to continue with Windows? Regards JP Le Mercredi 26 Septembre 2007 13:56, Dave Baxter a =E9crit=A0: > Related to all this.... > > What is SDCC's support of windows long file names? It's burping now on > C:\Program Files\SDCC etc etc, showing the path as "Files\SDCC etc etc" > So, it's now not even finding the source files. > > ..\source\etc.c doesn't work now either, it did 5 minutes ago! > > Confused.... > > > As to the "| More" "feature". I also find that you can't redirect it's > output to a file, as in... > > Aplication.exe > tmp.txt > > > SDCC talking to the bios directly, or what? > > > Dave B. > > > -----Original Message----- > > From: sdc...@li... > > [mailto:sdc...@li...] On Behalf Of > > Ken Jackson > > Sent: Wednesday, September 26, 2007 12:15 PM > > To: sdc...@li... > > Subject: [Sdcc-user] How to specify chip type (PIC's) ? > > > > The command line shown does not have any -p switch on it. > > > > This shoulds like a Code::Blocks problem, not an SDCC problem. > > There is a forum site where you could post the question and > > you might get more helpful answers: <http://forums.codeblocks.org/> > > > > As an experiment, you could just issue the correct command > > from the command prompt in a shell (a 'DOS box') and see if it works. > > > > -Ken Jackson > > > > Dave Baxter writes: > > ... > > > > > However, try as I might, I can't seem to get the system to > > > > accept > "-p16f877" where and however I put it, so what's > > the *Exact* selection > procedure please... Can I reference > > it in the source? Or, will it only > be accepted on a > > command line parameter created mystically by > Code::Blocks? > > > > > I have spent hours looking for help, but the various > > > > websites are of > next to zero help with this, either SDCC > > or Code::Blocks that is. > > ... > > > > > -------- > > > Switching to target: default > > > sdcc.exe -mpic14 -mpic14 -mpic14 -I"C:\Program > > > > Files\SDCC\include" > > > > > -c kiss.c -o .objs\kiss.rel > > > No processor has been specified (use -pPROCESSOR_NAME) > > > > > PIC14 processors and their characteristics: > > ... > > > > > > -------------------------------------------------------------- > > ----------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > This mail has been scanned by Palmer Cook Computer Services Limited.=20 > www.palmercook.co.uk > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user =2D-=20 Never jump into a loop! |
From: Raphael N. <rn...@we...> - 2007-09-26 12:23:34
|
Hello Dave, > What is SDCC's support of windows long file names? It's burping now > on C:\Program Files\SDCC etc etc, showing the path as "Files\SDCC etc > etc" So, it's now not even finding the source files. You will have to quote them (i.e., use sdcc -mpic14 -p16f877 "C:\Program Files\SDCC\whatever"). If you installed SDCC into a path including spaces, I suppose you need to add proper -I and -L directives to tell SDCC the Include and Library search paths in a quoted manner like sdcc -pic14 -p16f877 -I "C:\Program Files\SDCC\include\pic16" -I "C:\Program Files\SDCC\include" -L "C:\Program Files\SDCC\lib\pic16" -L "C:\Program Files\SDCC\lib" "C:\Program Files\myself\test\etc.c" You might also try to use POSIXish path names using a forward slash as separator instead of a backslash---quotes are still required to mask the space. Specifying paths for source files should only be required if they do not reside in the current directory (use "cd NAME" to change the current directory, e.g. via a relative path NAME). For these include directories and library search paths there should be nice dialog boxes around to set them up, along with arguments (such as -p16f877) to the compiler... But even if all this does go well, there is still the problem of telling gputils/gplink to find its .inc/.lkr files... and of course calling gpasm and gplink in the first place... I'd recommend to reinstall SDCC and gputils into a path with no spaces in them, such as "C:\sdcc". Good luck. > As to the "| More" "feature". I also find that you can't redirect > it's output to a file, as in... > > Aplication.exe > tmp.txt > > SDCC talking to the bios directly, or what? Nope, but as its output is errors and warnings, these go into a different output stream: there's a standard output stream (stdout), which can be redirected and piped through more using the | and > operators, but which receives hardly any output from SDCC, and then there's the standard ERROR output stream (stderr), which cannot easily be redirected using | or >. However, on Linux systems you can redirect the stderr stream via the construct 2>&1 to go to stdout, so maybe sdcc [options here] 2>&1 | more works even on Windows... As I do no (longer) use Windows, I cannot test any of these proposals. Regards, Raphael |
From: Ken J. <Ken...@ie...> - 2007-09-26 13:42:17
|
I saw your last message, that you reinstalled in C:\SDCC. That's a good choice, but the 'subst' command still works. E.g.: subst S: "C:\Program Files\SDCC" That creates a drive S: that is really a subdirectory, but works just like a drive partition. (To remove it: subst /D S: ) <http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/subst.mspx> Also, If switching to GNU/Linux is too frustrating (as you indicated in another message), I would recommend installing the Cygwin environment: <http://cygwin.com/> That's how I made the leap from Win98 to GNU/Linux five years ago. I installed Cygwin and started slowly learning the incredible power of the Bash shell and numerous GNU tools. (I never got any X applications to work under Cygwin on my under-powered PC--YMMV). Now I use only GNU/Linux and shudder at the thought of going back to Windows. Also, with Cygwin installed, your PC is still 100% Windows, so everything else still works the same. Trying to pipe output to 'more' in a Windows command shell is hit or miss. But with Cygwin installed, you can have a bash shell open along with your other Windows windows. Type the same command in it and it will most likely work. -Ken Jackson Dave Baxter writes: > Related to all this.... > > What is SDCC's support of windows long file names? It's burping now on > C:\Program Files\SDCC etc etc, showing the path as "Files\SDCC etc etc" > So, it's now not even finding the source files. > > ..\source\etc.c doesn't work now either, it did 5 minutes ago! > > Confused.... > > > As to the "| More" "feature". I also find that you can't redirect it's > output to a file, as in... > > Aplication.exe > tmp.txt > > > SDCC talking to the bios directly, or what? > > > Dave B. > > > > -----Original Message----- > > From: sdc...@li... > > [mailto:sdc...@li...] On Behalf Of > > Ken Jackson > > Sent: Wednesday, September 26, 2007 12:15 PM > > To: sdc...@li... > > Subject: [Sdcc-user] How to specify chip type (PIC's) ? > > > > The command line shown does not have any -p switch on it. > > > > This sounds like a Code::Blocks problem, not an SDCC problem. > > There is a forum site where you could post the question and > > you might get more helpful answers: <http://forums.codeblocks.org/> > > > > As an experiment, you could just issue the correct command > > from the command prompt in a shell (a 'DOS box') and see if it works. > > > > -Ken Jackson > > > > Dave Baxter writes: > > ... > > > However, try as I might, I can't seem to get the system to > > accept > "-p16f877" where and however I put it, so what's > > the *Exact* selection > procedure please... Can I reference > > it in the source? Or, will it only > be accepted on a > > command line parameter created mystically by > Code::Blocks? > > > > > > I have spent hours looking for help, but the various > > websites are of > next to zero help with this, either SDCC > > or Code::Blocks that is. > > ... > > > -------- > > > Switching to target: default > > > sdcc.exe -mpic14 -mpic14 -mpic14 -I"C:\Program Files\SDCC\include" > > > -c kiss.c -o .objs\kiss.rel > > > No processor has been specified (use -pPROCESSOR_NAME) > > > PIC14 processors and their characteristics: > > ... |
From: Dave B. <da...@em...> - 2007-09-26 12:18:30
|
No choice, I have to continue with windowz. I have linux too (mandrake 9.2) I don't know enough of that for it to be = useful, it just p's me off most of the time, but I did make it host a = VoIP proxy! Even if you have to load it by hand each time. About the best 'nix distro I ever found, fast, lightweight, etc is = "Puppy Linux", but I digress, for now it's WinXP and no choice about it. I re-installed sdcc away from the default "Program Files" path, and = found some documentation was installed this time. Seems sdcc does not = use stdout for it's default screen output, so you cant re-direct it = anywhere. However if you do.... sdcc --use-stdout | more Then you get all the guff, one page at a time! Some sort of progress at = least. :-) Dave B. =20 > -----Original Message----- > From: sdc...@li...=20 > [mailto:sdc...@li...] On Behalf Of=20 > Jean-Paul > Sent: Wednesday, September 26, 2007 12:55 PM > To: sdc...@li... > Subject: Re: [Sdcc-user] How to specify chip type (PIC's) ? >=20 >=20 > You are talking of problems I encounter when using Windows,=20 > be it with other > applications: it is sometimes unpredictable. > Are you sure you want to continue with Windows? >=20 > Regards >=20 > JP >=20 > Le Mercredi 26 Septembre 2007 13:56, Dave Baxter a =E9crit=A0: > > Related to all this.... > > > > What is SDCC's support of windows long file names? It's=20 > burping now on > > C:\Program Files\SDCC etc etc, showing the path as=20 > "Files\SDCC etc etc" > > So, it's now not even finding the source files. > > > > ..\source\etc.c doesn't work now either, it did 5 minutes ago! > > > > Confused.... > > > > > > As to the "| More" "feature". I also find that you can't redirect=20 > > it's output to a file, as in... > > > > Aplication.exe > tmp.txt > > > > > > SDCC talking to the bios directly, or what? > > > > > > Dave B. > > > > > -----Original Message----- > > > From: sdc...@li... > > > [mailto:sdc...@li...] On Behalf Of Ken=20 > > > Jackson > > > Sent: Wednesday, September 26, 2007 12:15 PM > > > To: sdc...@li... > > > Subject: [Sdcc-user] How to specify chip type (PIC's) ? > > > > > > The command line shown does not have any -p switch on it. > > > > > > This shoulds like a Code::Blocks problem, not an SDCC problem. > > > There is a forum site where you could post the question and you=20 > > > might get more helpful answers: <http://forums.codeblocks.org/> > > > > > > As an experiment, you could just issue the correct=20 > command from the=20 > > > command prompt in a shell (a 'DOS box') and see if it works. > > > > > > -Ken Jackson > > > > > > Dave Baxter writes: > > > ... > > > > > > > However, try as I might, I can't seem to get the system to > > > > > > accept > "-p16f877" where and however I put it, so what's the=20 > > > *Exact* selection > procedure please... Can I reference=20 > it in the=20 > > > source? Or, will it only > be accepted on a command=20 > line parameter=20 > > > created mystically by > Code::Blocks? > > > > > > > I have spent hours looking for help, but the various > > > > > > websites are of > next to zero help with this, either SDCC or=20 > > > Code::Blocks that is. > > > ... > > > > > > > -------- > > > > Switching to target: default > > > > sdcc.exe -mpic14 -mpic14 -mpic14 -I"C:\Program > > > > > > Files\SDCC\include" > > > > > > > -c kiss.c -o .objs\kiss.rel > > > > No processor has been specified (use -pPROCESSOR_NAME) > > > > > > > PIC14 processors and their characteristics: > > > ... > > > > > > > > > -------------------------------------------------------------- > > > ----------- > > > This SF.net email is sponsored by: Microsoft Defy all challenges.=20 > > > Microsoft(R) Visual Studio 2005. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > _______________________________________________ > > > Sdcc-user mailing list > > > Sdc...@li... > > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > This mail has been scanned by Palmer Cook Computer Services=20 > Limited.=20 > > www.palmercook.co.uk > >=20 > ---------------------------------------------------------------------- > > --- This SF.net email is sponsored by: Microsoft Defy all=20 > challenges.=20 > > Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Sdcc-user mailing list > > Sdc...@li... > > https://lists.sourceforge.net/lists/listinfo/sdcc-user >=20 > -- > Never jump into a loop! >=20 > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by: Microsoft Defy all=20 > challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user >=20 = This mail has been scanned by Palmer Cook Computer Services Limited. w= ww.palmercook.co.uk= |
From: Dave B. <da...@em...> - 2007-09-26 13:09:25
|
Thanks for all that Raphael... I sort of pre-empted you with the re-install, to C:\SDCC as you suggested... I'll work through the rest as I go, probably doing all the donkey work with a batch file, as I normally try to keep all my project files in their unique directories, so I will need to specify paths etc. The linker, no doubt I'll be muttering about that later, at least I now have some documentation to go through, and I'll make a copy of it's default (help) output as a cross reference. I used to do all this sort of thing as a matter of course years ago, but these days I find I don't have the time or patience to fight the system if it doesn't easily do what I want it to do. In this instance (the PIC based project) I'm doing this as a hobby, however, I often do much the same as a job, why I sometimes wonder... Oh well, back to collecting the sources etc... If I ever figure out what C::B was trying to do, I'll see if that can be altered too, as I've been spolt with flashy syntax highlighted code editors and integrated IDE's etc. Cheers. Dave B. > -----Original Message----- > From: sdc...@li...=20 > [mailto:sdc...@li...] On Behalf Of=20 > Raphael Neider > Sent: Wednesday, September 26, 2007 1:23 PM > To: sdc...@li... > Subject: Re: [Sdcc-user] How to specify chip type (PIC's) ? >=20 > Hello Dave, >=20 > > What is SDCC's support of windows long file names? It's=20 > burping now > > on C:\Program Files\SDCC etc etc, showing the path as=20 > "Files\SDCC etc=20 > > etc" So, it's now not even finding the source files. >=20 > You will have to quote them (i.e., use sdcc -mpic14 -p16f877=20 > "C:\Program Files\SDCC\whatever"). If you installed SDCC into=20 > a path including spaces, I suppose you need to add proper -I=20 > and -L directives to tell SDCC the Include and Library search=20 > paths in a quoted manner like >=20 > sdcc -pic14 -p16f877 -I "C:\Program Files\SDCC\include\pic16"=20 > -I "C:\Program Files\SDCC\include" -L "C:\Program=20 > Files\SDCC\lib\pic16" -L "C:\Program Files\SDCC\lib"=20 > "C:\Program Files\myself\test\etc.c" >=20 > You might also try to use POSIXish path names using a forward=20 > slash as separator instead of a backslash---quotes are still=20 > required to mask the space. >=20 > Specifying paths for source files should only be required if=20 > they do not reside in the current directory (use "cd NAME" to=20 > change the current directory, e.g. via a relative path NAME). > For these include directories and library search paths there=20 > should be nice dialog boxes around to set them up, along with=20 > arguments (such as > -p16f877) to the compiler... >=20 > But even if all this does go well, there is still the problem=20 > of telling gputils/gplink to find its .inc/.lkr files... and=20 > of course calling gpasm and gplink in the first place... >=20 > I'd recommend to reinstall SDCC and gputils into a path with=20 > no spaces in them, such as "C:\sdcc". Good luck. >=20 > > As to the "| More" "feature". I also find that you can't redirect=20 > > it's output to a file, as in... > >=20 > > Aplication.exe > tmp.txt > >=20 > > SDCC talking to the bios directly, or what? >=20 > Nope, but as its output is errors and warnings, these go into=20 > a different output stream: there's a standard output stream=20 > (stdout), which can be redirected and piped through more=20 > using the | and > operators, but which receives hardly any=20 > output from SDCC, and then there's the standard ERROR output=20 > stream (stderr), which cannot easily be redirected using | or=20 > >. However, on Linux systems you can redirect the stderr=20 > stream via the construct 2>&1 to go to stdout, so maybe sdcc=20 > [options here] 2>&1 | more works even on Windows... As I do=20 > no (longer) use Windows, I cannot test any of these proposals. >=20 > Regards, > Raphael = This mail has been scanned by Palmer Cook Computer Services Limited. w= ww.palmercook.co.uk= |
From: Dave B. <da...@em...> - 2007-09-26 14:59:05
|
Hi... Yes, I have Cygwin too, not on this PC though. I got it for the sshd facility a couple of years ago, a very good robust fallback VPN whenever I need it. Mind you, installing that was not painless either, needing several downloads and builds to get all the bits needed working correctly. I dred to think if I ever need to re-install it, the original website with the instrucitons on, has long gone, and quite where my notes about it all are, goodness knows. The only "package" I have successfully installed on the Linux machine, was funnily enough Sun's Java RTE, as what came with the linux distribution didn't work very well, if at all. Sun's instructions were on the nail, and it went on first go, and then worked "out of the box" as it were. I tried a few other things, but there are "holes" in the instructions, and no help forthcoming from the "experts" either. It's been a while since I built anything (software wise that is) for PIC's, then using a much earlier MPLAB, and working in assembler. Not painless, but so many fewer ways to screw up (in the IDE anyway) I used to have the HiTech PICC Lite package, that worked realy well, but it didn't take kindly to being installed on XP, so I have left that on an old W98 machine, for any needed changes to that project. What I'm learning at the moment, is it seems that there is no such thing as *Standard* C code any more. OK, the basic C stuff is still much the same, and much of it ANSI compatible, notwithstanding C++ (or C#) of course. (I've spent some years working with Pascal and Delphi, but the only formal trainig I ever had in coding, was ANSI C based.) However, there seems to be little to no standardisation in the way the various compilers are invoked, or how the build time parameters are set, not least from within the source code, let alone via any third party IDE via a command line shell. (Code::Blocks, or the MPLAB IDE) The result, is to make what is otherwise an "Open" source project, very much "Closed" if you don't have the particular compiler/environment the original author had, and also don't have the detailed in-depth knowledge of that, and the tools you happen to have found and placed in front of you. I have just found that this project references an include file that is native to the original compiler, that I don't have. The ubiquitous "string.h" Googling shows so many variations and just the references, not the file. Not that I even know the version of ccs compiler the original author used, and anyway, I'm not likely to shell out what ccs want for a compiler suite, for a one time build, purely for my own use. Yes I know they do a demo, guess what, it loads OK, but wont run saying that the demo period has passed, not that I ever had it installed before. I have mailed (several times) CCS, only automated messages in return with a reference number, no help at all. Showstopper time for now sadly, if just because I've run out of available time to mess with all this, I obviously spent too much time trying to figure it out myself, before coming here... Teach me to build the hardware before getting the code working. Thanks for the hints and help so far, I'll go back to lurking. Cheers. Dave B. = This mail has been scanned by Palmer Cook Computer Services Limited. w= ww.palmercook.co.uk= |
From: John J. M. <wb...@ar...> - 2007-09-26 15:54:13
|
----- Original Message ----- From: "Dave Baxter" <da...@em...> Subject: Re: [Sdcc-user] How to specify chip type (PIC's) ? > correctly. I dred to think if I ever need to re-install it, the > original website with the instrucitons on, has long gone, and quite > where my notes about it all are, goodness knows. Cygwin has become much more automatic to install, although it can be quite slow to install. Pretty good update scheme, though. And the number of packages has exploded so it is useful for more than just ssh, although I will admit that probably 90% of my use is ssh, too. > It's been a while since I built anything (software wise that is) for > PIC's, then using a much earlier MPLAB, and working in assembler. Not > painless, but so many fewer ways to screw up (in the IDE anyway) When you are doing embedded stuff, there's a lot to be said for assembler. > What I'm learning at the moment, is it seems that there is no such thing > as *Standard* C code any more. OK, the basic C stuff is still much the > same, and much of it ANSI compatible, notwithstanding C++ (or C#) of > course. (I've spent some years working with Pascal and Delphi, but the > only formal trainig I ever had in coding, was ANSI C based.) Well, the PIC is a pretty unusual architecture, and most of the compilers don't really compile C, but a language kinda sorta like C. ANSI has made it worse. The ANSI standard even specifies some implementation details that are really stupid for an embedded application. The ANSI developers were really thinking big iron, and the standard evolved at a time when we were getting our head around the idea of programmers being more expensive than computers. That approach of using compute cycles to offset programmer hours doesn't always play well in embedded applications, although sometimes it does. Heck, if that weren't part of the equation, you wouldn't be considering C. > The result, is to make what is otherwise an "Open" source project, very > much "Closed" if you don't have the particular compiler/environment the > original author had, and also don't have the detailed in-depth knowledge > of that, and the tools you happen to have found and placed in front of > you. You will find that the heftier the part you choose, the more the code can look like actual C. The PIC18, especially PIC18's with large file register space, start to look something like C. If you have plenty of memory you'll find you don't have to mess with a lot of the strange stuff. When you go to the PIC24 and dsPIC30, the language is almost real C. (not SDCC, however). A lot of the extensions have to do with working around issues in the PIC that you simply wouldn't deal with in a non-embedded environment. > I have just found that this project references an include file that is > native to the original compiler, that I don't have. The ubiquitous > "string.h" Googling shows so many variations and just the references, > not the file. Not that I even know the version of ccs compiler the > original author used, and anyway, I'm not likely to shell out what ccs > want for a compiler suite, for a one time build, purely for my own use. The good news is that the common C packages like string.h tend to be pretty simple, and the interface is pretty consistent. Odds are you could come close enough grokking your own using any old string.h as a reference. Heck, most projects use only a tiny fraction of the functions, and for a one-off, you might write your own routines. Many of the routines have quite good source in K&R. In fact, the first SDCC project I did I had some trouble finding the right libraries for my PIC (I think it was a 16F88), so the few routines I needed I just copied out of K&R and avoided having to think about them. Probably more flexible or more efficient routines might have been possible, but for my purposes, that hack worked just fine. > Showstopper time for now sadly, if just because I've run out of > available time to mess with all this, I obviously spent too much time > trying to figure it out myself, before coming here... Teach me to build > the hardware before getting the code working. Generally it's a better plan to develop both together. Pity you are out of time, because SDCC is kinda cool, although at least for me, it doesn't replace assembler. There are places, though, where it can be a huge time saver. But like any compiler for an embedded processor, if you aren't pretty intimate with it, it can be a huge time waster, too. --McD |
From: Ken J. <Ken...@ie...> - 2007-09-26 15:55:06
|
I think the main problem is the PIC architecture. It's actually somewhat shocking how well SDCC has done to make C actually work on an architecture that was clearly intended to run only assembly code. As for standards, I have come to view GCC as the center of the universe. Anything that differs is nonstandard. That's why I so thoroughly appreciate the Atmel AVR processors, for which GCC is ported. -Ken Jackson Dave Baxter writes: ... > What I'm learning at the moment, is it seems that there is no such thing > as *Standard* C code any more. OK, the basic C stuff is still much the > same, and much of it ANSI compatible, notwithstanding C++ (or C#) of > course. (I've spent some years working with Pascal and Delphi, but the > only formal trainig I ever had in coding, was ANSI C based.) > > However, there seems to be little to no standardisation in the way the > various compilers are invoked, or how the build time parameters are set, > not least from within the source code, let alone via any third party IDE > via a command line shell. (Code::Blocks, or the MPLAB IDE) ... |
From: Xiaofan C. <xia...@gm...> - 2007-09-26 23:45:39
|
On 9/26/07, Ken Jackson <Ken...@ie...> wrote: > I think the main problem is the PIC architecture. It's actually > somewhat shocking how well SDCC has done to make C actually work > on an architecture that was clearly intended to run only assembly > code. Firstly now there are different PIC architectures: the old 12bit and 14bit instruction width PIC12/PIC16, PIC18F and even 16bit PICs like PIC24/dsPIC30/dsPIC33. For the 16bit PICs, the C30 compiler is based on GCC. SDCC is quite good for 8051 but it has a long way to go for PICs. There are decent compilers for the low end PIC12/PIC16, Hitech PICC is one. And PIC18 is certainly much more C friendly. MPLAB C18 and Hitech PICC18 are both quite decent. MPLAB C18 comes with the free student version with no code size limit (only optimization limit). I remember there is a past discussion that Scott mentioned GCC might be possible for PIC18. Xiaofan http://mcuee.blogspot.com |