EmbeddedRelated.com
Forums
Memfault Beyond the Launch

New to PIC

Started by 2Penny November 30, 2004


Meindert Sprang wrote:
> "2Penny" <lw_rogers@sbcglobal.net> wrote in message > news:DIzrd.37248$6q2.17910@newssvr14.news.prodigy.com... > >>Mr Falconer: >> >>I top post because I've developed a dislike for wading through >>all the garbage from other posts in other threads, in other >>newsgroups one more time when I've read most of the post in any >>one thread 3 times already. I thought to extend the courtesy >>of getting to any points I hope to make quickly for sake of anyone >>who cares to read any part of my posts. > > > Just my 2 cents: if you toppost because you don't like wading through the > 'garbage', it implies that you leave the garbage at the end of the message > where it is less noticed. This implies that the garbage is resent all the > time through 10 thousands of newsservers, eating up bandwith and costing > people money who download over a phone line (yes they still exist in large > numbers). > > If you bottom post and leave all the garbage, there is a bigger chance that > someone sensible will cut the irrelevant excess before replying (something > you should have done too) and keep the message short and clear to anyone who > chimes in at the middle of a thread. > > If you toppost, someone who enters the discussion halfway, he or she has to > read the entire 'garbage' backwards (from bottom to top) to learn what the > discussion was about and how it developed. Does that sound logical to you? > > So, my opinion is: if you enter a community with a question, it is no more > than polite to adhere to (unwritten) standards that are common in that > community. You get far more cooperation than if you just say: "hell, I do it > my way because I like it that way, I don't care what others think about it." > > And now to your question: if your assembly code accesses registers throug > definitions in a header- or include file, changing the reference to that > include file from one to another processor is basically all that needs to be > done. If the code then assembles without errors, there is hardly any problem > to be expected. You will certainly not burn something. > > The only way to be absolutely shure is to read the datasheet and find out > where the differences are. > > Meindert > >
Mr Sprang: Your note about the community's unwritten "standards" was coherent and well put. I'm not a PhD in Electrical Engineering, but I get to work with a lot of 'em and most of 'em don't like the PIC. I suppose I've come to expect direct answers because direct answers are expected of me. So far yours was about as good as I've gotten. Your answer, where you actually restated my question before answering, framed your answer well, but if I understand it, still gets down to "if it assembles, in all probability, it'll work". I've already poured over the handbook on the 18Cxx2 series of processors and they look pretty similar to the 18Fxx2 processor data sheets, but from my quick look I didn't see any definite places where all the registers and sizes are tallied up in either location so it seems the "burn & crash" method gets tried one more time. Thanks for your integrity. 2Penny
2Penny wrote:
> Meindert Sprang wrote: >> "2Penny" <lw_rogers@sbcglobal.net> wrote in message >>> >>> I top post because I've developed a dislike for wading through >>> all the garbage from other posts in other threads, in other >>> newsgroups one more time when I've read most of the post in any >>> one thread 3 times already. I thought to extend the courtesy >>> of getting to any points I hope to make quickly for sake of anyone >>> who cares to read any part of my posts. >> >> Just my 2 cents: if you toppost because you don't like wading >> through the 'garbage', it implies that you leave the garbage at the >> end of the message where it is less noticed. This implies that the >> garbage is resent all the time through 10 thousands of newsservers, >> eating up bandwith and costing people money who download over a >> phone line (yes they still exist in large numbers). >>
... snip ...
> > I've already poured over the handbook on the 18Cxx2 series of > processors and they look pretty similar to the 18Fxx2 processor > data sheets, but from my quick look I didn't see any definite > places where all the registers and sizes are tallied up in either > location so it seems the "burn & crash" method gets tried one > more time.
If you go back to the message where I originally criticized you for top-posting, you will see I recommended getting the MPLAB system, which is free. This includes an assembler, and means of setting the default chip used. It also includes a simulator, on which you can do a great deal of testing and debugging. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net> USE worldnet address!
"2Penny" <lw_rogers@sbcglobal.net> wrote in message
news:44Rrd.27839$zx1.13141@newssvr13.news.prodigy.com...
> Mr Sprang: > > Your note about the community's unwritten "standards" was coherent > and well put.
Thanks. And thank you for "adopting the standard" :-) Many times, this just starts a flame-war of top- and bottomposters....
> I'm not a PhD in Electrical Engineering, but I get to work with a > lot of 'em and most of 'em don't like the PIC. > > I suppose I've come to expect direct answers because direct > answers are expected of me. So far yours was about as good > as I've gotten. Your answer, where you actually restated > my question before answering, framed your answer well, but > if I understand it, still gets down to "if it assembles, in > all probability, it'll work".
What I meant was that unles you have some sort of hardware hooked up that could be driven to destruction, there is no hardly a chance of destroying a processor just by setting it's internal registers wrong.
> I've already poured over the handbook on the 18Cxx2 series of > processors and they look pretty similar to the 18Fxx2 processor > data sheets, but from my quick look I didn't see any definite > places where all the registers and sizes are tallied up in either > location so it seems the "burn & crash" method gets tried one > more time.
Mmm, my experience is that register sets are *always* documented fully in datasheets. The more common things like instructionsets are mostly covered in what is called a "programming manual" of a certain family of micro's. Meindert
> Mmm, my experience is that register sets are *always* documented fully in > datasheets. The more common things like instructionsets are mostly covered
Oh boy, which particular heaven are you living in? I vividly remember several parts where the only way of finding out correct (VITAL) values to put in the undocumented registers was to load someone else's working binary onto the system, let it initialize the hardware, and make some intelligent guesses about how to unlock and read those registers. (e.g. undocumented CRTC and Sequencer registers in a VGA chip). Not so often in microcontrollers, but in some PC peripheral type parts... common.
"Lewin A.R.W. Edwards" <larwe@larwe.com> wrote in message
news:608b6569.0412030741.14a8eae7@posting.google.com...
> > Mmm, my experience is that register sets are *always* documented fully
in
> > datasheets. The more common things like instructionsets are mostly
covered
> > Oh boy, which particular heaven are you living in?
Z80/Z8/8051/ADSP210x/DSP56300/AVR heaven??
> several parts where the only way of finding out correct (VITAL) values > to put in the undocumented registers was to load someone else's > working binary onto the system, let it initialize the hardware, and > make some intelligent guesses about how to unlock and read those > registers. (e.g. undocumented CRTC and Sequencer registers in a VGA > chip).
Nah, I never dealt with that.... Meindert

Memfault Beyond the Launch