On Fri, Jan 07, 2005 at 12:20:16PM -0500, Nathanial Hendler wrote: > On Fri, Jan 07, 2005 at 08:27:29AM -0500, Olin Lathrop wrote: > > Nathanial Hendler wrote: > > >You've mentioned your preprocessor in other posts as well. It seems > > >very nice, but I'm using the gpasm and linux for my development and > > >your system appears to require windows/dos. > > > > Oh, well. I have to get work done and don't have time for attitude > > problems against Microsoft. > > Whoa. ? I'm only saying that the reason I am unable to explore your > preprocessor is because it runs on windows/dos, and that's not what I use. > I also don't use a ice cube trays, but I have nothing against them. Perhaps > you were talking about some one else's attitude problem, and I have just > misunderstood? Well put. But Olin does have a point. Windows is the virtual standard for PC based computing. Using anything else, which puts you decidedly out of the mainstream, requires making a choice. And since Windows is the virtual standard, that choice usually has some underlaying reason for it. To extend your analogy (metaphor?) it's like you deciding to use ice cube trays when every fridge comes with an ice maker. It's probably that he's seen enough raving Linux lunatics, such as myself ;-), to make that snap assessment. OTOH Olin is well on his way to being an open community guy. He publishes much of is code, and the protocols for his line of programmers are openly documented. > > Then you need to read the MPASM/MPLINK manual. > > Will do. Then go and read Craig Franklin's GPLINK manual which comes with the gputils that you are using. You have a linker, you just have to learn to use it. > >> If I remember right the '873 is a downsized '876, which doesn't have the >> global RAM in the last 16 locations of each bank. I would use the 16F876 >> instead. It is definitely a full architecture PIC 16 and will force you >> to pay attention to banking and paging. > > Ok. And what do you think about the suggestion that I look into the 18F > architecture? It's always a good suggestion as the memory architecture is greatly simplified. While it still has forms of banking, the extended instruction set does have instructions for accessing any memory location directly. Take a read of chapter 7 of the 18C reference manual for a complete description. But Olin's point still stands: the tools have a linker which will manage both program and data memory allocation. We should all be using it. Every other system up the chain that we use does this as an underlaying foundation so that it's transparant to us. However when you get to bare metal you have to make linking an explicit activity. In short it requires some forethought and some work to setup. And the inertial combination of limited information, tons of absolute code floating around, and early success with absolute code deters most folks from progressing beyond its use. Olin and most other professionals have enough projects that they need to build a library of core routines to give a scaffolding (sp) to each project. Most hobbyist won't take the time to build that infrastructure. So they simply never get around tuit ;-) Olin, on the flip side most newbies and hobbyist just want early project success. That's why tutorials are important to them because it leads them to early success without having to decypher the entire Rosetta Stone first. As an example I present Craig Franklin's GPLINK tutorial: http://gputils.sourceforge.net/reloc_howto.html Note that Craig points out the same thing that Olin does: there's no substitute for the complete manual. But a document like this gives the opportunity to get your feet wet, have early success, and then follow up with a complete dissection of full manual. > > > >Can you recommend any code to me to look at? > > > > I did, but you apparently haven't looked at it. > > Are you easily frustrated by all newbies, or is it just me? ;) It's not just you. Of course Olin's code is negated by the need for his preprocessor. OTOH you didn't bring to the table that you were using Linux and gputils. So call it even and move on. Craig's tutorial has what you need to get started. > Anyway, I'll read the > datasheets and MPASM/MPLINK manuals, and give everyone here a rest. There is one last point to be made. The use of relocatable objects is choice. While it is Olin's strong opinion, it is an opinion. If absolute code using the 16F of your choice works for you, then use it. Just be aware that the linker is designed to lay out code and variables for you, and to make it easier for you to reuse modules of code. But it isn't an ABOSLUTE ;-) requirement. I would also suggest that you take up any gplink inquires up on the gputils list. You can find that information at http://gputils.sf.net And don't let Olin scare you away. No matter what the presentation, everyone here does want to help. BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist