Hi, Using at89c51 i want some data to copy from program memory to external Data memory.. without using memcopy()... any idea ?
For a single byte:
code unsigned char code_var _at_ 0x1234; xdata unsigned char xdata_var _at_ 0x4321; xdata_var = code_var;
Hint: If you make the two variables structs, you can simply do the assignment, and the compiler will implement the copy in an effiecient manner! You will find that C51 uses memcpy() to implement the assignment leaving you no better off. I can think of few reasons to aviod using memcpy() other than avoiding the significant memory space that memcpy() takes up. However, almost all non-trivial programs will have memcpy() in them already.
That statement is not self-evident, its incorrect. On the contrary, the only way "inc P2" can safely be used IS with a shadow register technique Now it is getting ridiculous. Enough said Erik
Enough said Gosh...miracles DO happen.
Gosh...miracles DO happen. If you realized how ridiculous your statemet above is, now, THAT would be a miracle. Erik
If you realized how ridiculous your statemet above is, now, THAT would be a miracle. And where would we go from there? Why would it matter? To a stereotypicle forum alpha-nerd such as yourself, the goal is simply a daily victory. One doesn't have to read too many of these threads to realize this. BTW, the spelling error is intentional. I figured if nothing else, you could pick the reply apart based on that. (wait for it... wait for it...)
the goal is simply a daily victory I could not care less about a "victory". HOWEVER I do care about someone leading the novices astray with blatantly incorrect statements. Erik
I could not care less about a "victory". HOWEVER I do care about someone leading the novices astray with blatantly incorrect statements. Really? And what do you call this: should have read "inc P2" can not be used when a shadow register is in use and that statement is self-evident. The only thing "evident" about that is that you simply don't get the big picture...yet you're concerned about the novice. Unless you (pre)shadow P2 at ALL TIMES, you can't safely manipulate it and expect any other portion of the program to use it(namely interrupts), then restore it after said use is complete. I admit when I'm wrong. I did that earlier in the thread and have since tried to correct it, at your request to elaborate on the topic. Your problem is you're an incessant know-it-all and you've appointed yourself the role of forum warden. Heck, look at the recent thread directed BY NAME to someone else, yet who's the first person to chime in and pontificating their wisdom? You. If you're really concerned about the novices, you'd consider how many of them you drive away with your pompous attitude.
Unless you (pre)shadow P2 at ALL TIMES, you can't safely manipulate it and expect any other portion of the program to use it(namely interrupts), then restore it after said use is complete. absolutely correct. BUT THAT IS INO THE POINT The issue you brought up was INC P2. Which, as opposed to your statements can NOT be used when you shadow (the increment will be lost at next shadow to port copy). I wish you would discuss THIS instead of the relative merit of my posts, where I could not care less about your opinion. Erik
As stated earlier, PUSH P2 is unreliable. It is not "unreliable" it is completely reliable, it does what the book says. "PUSH P2" doesn't necessarily push the value that's presently in the P2 output latch. NOT "doesn't necessarily" It never does. It is clearly documented that a READ operation reads the port pins. and a PUSh is READ operand, then write to stack. Erik
By this point in this thread, it should be clear what I'm trying to convey, yet here you go again nitt-picking at semantics and details. And you expect me or anyone else to believe this isn't about your victory? Right. LOL.
semantics and details Never, always accuracy. Erik
accuracy is good, but when one insist on it to the point where you lose focus of the original point, then its nothing but anal-retentiveness.
Who lost focus and started attacking ? Not me. Who kicked in a discussion about INC p2 with incorrect statements such as "INC P2 is a read/modify/write instruction. Just because you last wrote a 0x2F (for example) to P2, doesn't mean that's necessarily what its going to read on the next read cycle of the read/modify/write of "INC P2"." Not me. Of course, you may consider it "losing focus" that I do not sit back and let it ride when you attack my integrity, that is your problem. A proverb come to mind : Thief think everyone steal Erik
And once again you fail to acknowlege I admitted I was confused and attempted to correct it. Its pretty obvious the reason you keep ignoring this is that if you would acknowlege it, it renders the majority of what you've said as frivolous drivel. Because of that, I don't consider later statements I made "attacks", rather their just observations about the way you operate. You don't care to discuss the point I was trying to convey, you simply get your jollies by picking at details. Every technical forum has one of you.
Since Robert Wey has stopped addressing technical issues, and resorted to attacking me in order to get his way, I will end this by saying: Please ignore all entries from Robert Wey, they have no technical merit, they only express that he can not accept his mistakes being corrected This will, of course result in another attack from Robert, which i shall choose to ignore. Erik
Kiddies... Let's not let this decline into a personal standards slanging match... It *is* supposed to be the "season to be jolly" and all... 8)
Kiddies... Let's not let this decline into a personal standards slanging match... It *is* supposed to be the "season to be jolly" and all... Oh...he's probably having as much fun as I am :)
View all questions in Keil forum