----- Original Message ----- From: "Dave Baxter" <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- 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 Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
