Agreed; linear mapping ends up being useless in most cases, since physically mapping makes the memory space non-continuous anyway. It does confuse more people, from what I've seen (fortunately to me, but let's face it: Memory banks are confusing enough. Overflowing the "window" means running into an entirely different ppage location which may or may not be in Flash, and is confusing. Either one, in my opinion, is not a more harmful confusion, and is easy to overcome by learning.
It's too bad I didn't see this early 2003, or I could have influenced the author of GCC (gnu-m68hc11 toolchain) to base memory mapping on something more updated. The Motorola S-record document thew me off and I thought linear S-records were preferred and would give advantage. Still, since linear is more compatible with db12's "fload", GCC and db12 go together well.
I do, however, wish someone was working on remaking GCC so it runs with the banking scheme because of the confusion. Anyone interrested to help me? (Oh sorry, won't be many GCC buffs in this forum)
What's wrong with students using RAM
before they learn to use Flash? It worked great for me, especially since DP256 has 12K RAM. I've never even used more than 8K Flash or 2K RAM yet in my commercial applications, so why would I need so much Flash just to learn? And I use db12's bootloader to load flash. Neither part allowes accidental erasure, but the bootloader can easily erase and reload the serial monitor part of db12. I erase the monitor part and load my final application to show it fully working in ROM. The bootloader can easily re-load the monitor part when ready to debug more. Of course that's when I moved on to a BDM pod since it's so cheap now days [especially evbplus.com]. I'm not saying db12 is as good as AN2548 when not using BDM. It's just that db12 BDM instead of AN2548 was definately worth it for real environment. I actually should design my own BDM pod like TBDML but using S08. It could be easy to build as TBDML but have near-db12-compatible serial interface.
I guess you are mixing up your terminology. Is your "sermon" a specific serial monitor? I'm confused because you talk as if there is only one "serial monitor", also suggesting that db12 is not??
You suggest that your "sermon" is just as good as a BDM POD, but it is not. Why would you think no app will need to actually use the same resources (i.e. serial port) that the sermon is using? I think your whole argument is only circumstantial, only going by what you need. My whole point is that D-Bug12 gives enough of everything (except maybe speed of loading Flash)... making it good for
everyone! It's good with or without a support application like NoICE.
When students "go the DBUG-12 route", They tend to learn more (that's my experience). That's more important than
Yester morning I was just finally daring to try to
evaluate CW 4.6, having given up on CW 4.5 (I've posted about the night mares with that). Now you say that
CW has made the unintelligent decision to no longer support the "popular" D-Bug12 [That's right, Freescale
themselves acknowledged that db12 is very popular].
So then,forget CW again. Too bad I went through all the trouble to download and install it. I should have guessed that FSL would drop their most stable and versatile debugger, most valuable to the smarter users.
You are right: evbplus.com (Wytec) is excellent, and Wayne is very good. That's why I support him as much as possible. I am confused because, why are you bringing up him while trying to argue that D-Bug12 is out? It is a small detail that has improved support for the AN2548 sermon (of course it was supported a little even before Dragon12-Plus). It's just that his product collection is the primary thing I am trying to preserve! What did you think those products are based on? What do you think is pre-installed in the Dragon12-Plus? Did you think it was even
possible to use AN2548 or
anything else on the excellent DragonBDM, except D-Bug12 ? So WRONG, all his boards do not support it. Besides, how do you expect to get AN2548 on there without a BDM pod?
I think you just don't realize how valuable it is to have option of debugging with this hardware-only solution, in an environment where you have nothing more than a dumb terminal.
SAVE THE TERMINAL DEBUGGER! --I say.
Well I hope Freescale gets this message, but then never seem to get it. And it is us small customers (BTW there are many thousand more small customers than there are huge Automotive customers). :smileysad: