We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
doc.nit.ac.ir/.../3-Mazidi-8051.pdf
step1: Read "K. Ayala" - to understand architecture step2: Read "Mazidi" - to understand programming 8051 in asm & C
Mazidi is a good book. You can find it in the local book store. But dont be totally dependent on it as there are few (not so bothering to a newbie) mistakes in the book. You may realize those mistakes once you have gained some expertize in 8051.
Mazidi is a good book. You can find it in the local book store. But dont be totally dependent on it as there are few (not so bothering to a newbie) mistakes in the book. If you use, virtually, any processor still made Mazdi has no info on the plethora of improvements to the I/O of modern '51s.
I recall some Mazdi believer who wanted to bit-bang I²C using a processor that had it in hardware.
Is that some plural for Mazda?
I suspect the real problem is the lack of any competence in those teaching from the books, instead of having any real world, or current, experience.
It was not me who said that, but I have done it.
Why? What a terrible thing to do you probably shout.
Unfortunately, some I²C hardware implementations are not as good as they should be. So doing it the hard way is sometimes the only sensible way out of a tricky situation.
It was not me who said that, but I have done it. Unfortunately, some I²C hardware implementations are not as good as they should be.
Isn't that the truth, there seem to be plenty of cases where the IC designer clearly has little grasp about the implementation of the bus in a practical sense.
SPI and CRC implementation are also prone to lackluster design.
The key is to recognize when the hardware implementation is flawed or inflexible, and when a software solution could be appropriate. Keep an open mind.
Unfortunately, some I²C hardware implementations are not as good as they should be. So doing it the hard way is sometimes the only sensible way out of a tricky situation. Everybody can state anything, but it would be valuable o know which.
I have two cases from fora and one from experience where "I²C hardware implementations are not as good as they should be" was not true, it was "the implementer of code for the I²C hardware implementations that was not as good as he should be"