From 63d0944063b6f240fe0c68ef9b61d4dd906d9fc1 Mon Sep 17 00:00:00 2001 From: Andreas Baumann Date: Tue, 17 Nov 2020 19:12:00 +0100 Subject: initial checkin --- doc/6502_org_source_general_clockfreq.txt | 201 +++++++++++++++ doc/www.ganssle.com_articles_anmi.txt | 409 ++++++++++++++++++++++++++++++ 2 files changed, 610 insertions(+) create mode 100644 doc/6502_org_source_general_clockfreq.txt create mode 100644 doc/www.ganssle.com_articles_anmi.txt (limited to 'doc') diff --git a/doc/6502_org_source_general_clockfreq.txt b/doc/6502_org_source_general_clockfreq.txt new file mode 100644 index 0000000..389d8a3 --- /dev/null +++ b/doc/6502_org_source_general_clockfreq.txt @@ -0,0 +1,201 @@ + [1][Return to Main Page] + + Calculation of Clock Frequency by Leo Nechaev + [2][Up to Source Code Repository] + __________________________________________________________________ + + This program calculates the clock frequency of 6502-based system. The + result is stored in location 'Ticks' to 'Ticks+3' in BCD representation + ('Ticks' - 2 symbols before decimal point, 'Ticks+1' to 'Ticks+3' - 6 + symbols after point), then result is sent via UART to the host (usually + PC with some kind of terminal programm). + + With minimal modifications (deleting 'SED' and 'CLD' instructions, + changing ticks constants [from BCD to binary format], deleting + 'terminal' subroutines) it may be used to determine real speed of + processor. +rgConfig = $6000 ; write: D6=1 - NMI is off, D6=0 - NMI is on +rgStatus = $6000 ; read: D6=0 - UART is busy +rgTxD = $5000 ; write: data to send via UART + +vcNMI = $FFFA + +Refresh = 450 ; NMI rate in Hz + + ldx #NMI + stx vcNMI + sty vcNMI+1 + lda #$40 ; on start NMI is off + sta InUse + +Again + lda #0 + sta Flag + sta Ticks ; initializing counter + sta Ticks+1 + sta Ticks+2 + sta Ticks+3 + lda #$FE ; initializing NMI counter (zeropoint minus 2 ti +cks) + sta Timer + lda #$FF + sta Timer+1 + lda InUse ; turn on NMI + and #$BF + sta rgConfig + sta InUse + +- bit Flag ; waiting for zeropoint minus 1 tick + bpl - + lda #0 + sta Flag + +- bit Flag ; waiting for true zeropoint + bpl - + lda #0 + sta Flag + +Main ; main counting cycle +;number of ticks per command sum of ticks +; v v + lda Ticks ;4 + clc ;2 6 + sed ;2 8 + adc #$53 ;2 10 + sta Ticks ;4 14 + lda Ticks+1 ;4 18 + adc #0 ;2 20 + sta Ticks+1 ;4 24 + lda Ticks+2 ;4 28 + adc #0 ;2 30 + sta Ticks+2 ;4 34 + lda Ticks+3 ;4 38 + adc #0 ;2 40 + sta Ticks+3 ;4 44 + cld ;2 46 + bit Flag ;4 50 + bpl Main ;3 53 + + lda #0 ;2 + sta Flag ;4 6 + lda Ticks ;4 10 + clc ;2 12 + sed ;2 14 + adc #$95 ;2 16 + sta Ticks ;4 20 + lda Ticks+1 ;4 24 + adc #0 ;2 26 + sta Ticks+1 ;4 30 + lda Ticks+2 ;4 34 + adc #0 ;2 36 + sta Ticks+2 ;4 40 + lda Ticks+3 ;4 44 + adc #0 ;2 46 + sta Ticks+3 ;4 50 + cld ;2 52 + lda Timer ;4 56 + cmp #Refresh ; 2 + bne Main ; 3 + + lda InUse ; turn off NMI + ora #$40 + sta rgConfig + sta InUse + + ldx #0 ; send first string to the host +- lda Mes1,x + beq + + jsr Send + inx + jmp - + ++ lda Ticks+3 + pha + lsr + lsr + lsr + lsr + beq + ; delete non-significant zero (clock < 10MHz) + jsr PrintDigit ++ pla + and #15 + jsr PrintDigit + lda #"." ; decimal point + jsr Send + lda Ticks+2 + jsr PrintTwoDigits + lda Ticks+1 + jsr PrintTwoDigits + lda Ticks + jsr PrintTwoDigits + + ldx #0 ; send second string to the host +- lda Mes2,x + beq + + jsr Send + inx + jmp - ++ jmp Again ; repeat process + +PrintTwoDigits + pha + lsr + lsr + lsr + lsr + jsr PrintDigit + pla + and #15 + jsr PrintDigit + rts + +PrintDigit + ora #$30 + jsr Send + rts + +Send + bit rgStatus + bvc Send + sta rgTxD + rts + +Mes1 + .db 13 + .tx "Current clock frequency is " + .db 0 + +Mes2 + .tx " MHz" + .db 0 + +Ticks .br 4,0 +Timer .br 2,0 +InUse .db 0 +Flag .db 0 + +NMI ;6 + pha ;3 9 + inc Timer ;6 15 + bne + ;3 18 + inc Timer+1 ; 5 ++ lda #$80 ;2 20 + sta Flag ;4 24 + pla ;4 28 + rti ;6 34 + + Test results: + * with chip oscillator "1.8432" the result is '1.843266 MHz' + * with chip oscillator "20.000000M" and divider by 10 the result is + '2.000040 MHz' + + Last page update: December 27, 2000. + +References + + 1. http://6502.org/ + 2. http://6502.org/source diff --git a/doc/www.ganssle.com_articles_anmi.txt b/doc/www.ganssle.com_articles_anmi.txt new file mode 100644 index 0000000..034ffdf --- /dev/null +++ b/doc/www.ganssle.com_articles_anmi.txt @@ -0,0 +1,409 @@ + [1]The Ganssle Group logo + [2]The Ganssle Group logo + * [3]Click here for a navigation menu + + * [4]Firmware + Classes + + [5]Public Training + + [6]On-Site Training + * [7]Newsletter + + [8]Subscribe + + [9]Back Issues + * [10]Expert + Witness + * [11]Blog + * [12]Videos + * [13]Tool & Book + Reviews + + [14]Tool Reviews + + [15]Jack's Books + + [16]Other Embedded Books + * [17]Special + Reports + + [18]Designing Ultra-Low Power Systems + + [19]Surprising Scope Probe Issues + + [20]2020 Salary Survey + + [21]Debouncing Contacts + + [22]Watchdog Timers + + [23]Microprocessor History + + [24]Being a Consultant + + [25]Write-only Memory + + [26]Process Improvement for the Boss + + [27]Commenting Code + + [28]Testing RAM + + [29]Getting Into Embedded Work + + [30]Code Inspections + + [31]Automatic Bug-Finding + + [32]eXtreme Instrumenting + + [33]Math Approximations - Trig + + [34]Math Approximations - Other Functions + + [35]Better Resumes + * [36]Articles + + [37]All Articles + + [38]Analog, Filtering, etc + + [39]Communications + + [40]Debugging + + [41]Fun Embedded Stuff + + [42]Hardware + + [43]Historical + + [44]Managing Projects + + [45]Math in Computers + + [46]Memory + + [47]Philosophical and Career + + [48]Real Time + + [49]Software & Firmware + + [50]Tools for Embedded Developers + + [51]Sailing! + * [52]Random + Rants + + [53]Electronics + + [54]Business Issues + + [55]Software Engineering + + [56]Products and Reviews + + [57]Philosophy of Engineering + + [58]Miscellaneous + + [59]History of Electronics and Embedded + + [60]Software + + [61]Random Thoughts + + [62]Fun Stuff + + [63]Real-Time Issues + * [64]Humor + * [65]Contact/Search + + [66]Contact Info + + [67]Advertise With Us + + [68]Search This Site + + [69]Jack's Bio + + [70]Expert Witness + + [71]Our Privacy Policy + +The Perils of NMI + + NMI is a critical resource, yet all too often it's misused. + + Published in Embedded Systems Programming, April 1991 + For novel ideas about building embedded systems (both hardware and + firmware), join the 40,000+ engineers who subscribe to [72]The Embedded + Muse, a free biweekly newsletter. The Muse has no hype and no vendor + PR. [73]Click here to subscribe. + LA104 Logic Analyzer October's giveaway is a LA104 mini logic analyzer. + I reviewed it in [74]Muse 406. .Enter the contest [75]here. + +By Jack Ganssle + + Wise amateurs fear [76]interrupts. Fools go where wise men fear to + tread. Normal sequential code is hard enough to understand, code, and + debug. Toss in a handful of asyncronous events that randomly change the + processor's execution path, perhaps thousands of times per second, and + you have a recipe for disaster. + + Yet interrupts are an important fact of life for all real time systems. + No experienced programmer would dream of replacing a clean interrupt + service routine with polled I/O, particularly where fast I/O response + is required. + + In fact, interrupts are the both the best and worse microprocessor + feature. Well thought out interrupt-driven code will be reasonably easy + to write, debug and maintain. A poorly conceived interrupt routine is + probably the worst possible software to work on. Because interrupts are + so important to embedded systems, it is vital to become proficient with + their use. + + If interrupts are tough to work with, then the non-maskable interrupt + (NMI) is the true killer of the business. Be careful before you connect + a peripheral to your processor's NMI input - think through the problems + carefully. + + Almost every processor has some sort of NMI signal, though it may be + called something else. On the 68000, a level 7 interrupt cannot be + masked, and is equivalent to NMI. Some 8051-family CPUs have no + non-maskable interrupt, an idea that is sort of appealing in terms of + enforcing interrupt discipline. + + I'm a firm believer in restricting NMI to those conditions that are + truly unusual and of momentous importance. Quite a few designers use + NMI as a general purpose interrupt, a practice that usually spells + disaster. + + When timing gets tight, the code can easily disable a conventional + interrupt. Indeed, the very assertion of an interrupt signal + automatically turns all interrupts off until the software explicitly + reenables them, giving the code a clean window to process a high + priority task. Not so with NMI. An NMI at any time will interrupt the + CPU - no ifs, ands or buts. As long as the hardware supplies NMIs to + the processor, it will stop whatever it's doing and vector through the + NMI handler. + + The very fact that NMI can never be disabled makes it ideal for + handling a small but vital class of extremely high priority events. + Chief among these is a power failure. If a system must die gracefully, + then hardware that detects the imminent loss of power can assert NMI to + let the software park disk heads, put moving sensors into a "safe" + state, copy important variables from RAM to non-volitile storage, and + generally prepare for being down. + + Modern power supplies have little reserve capacity. Old linear designs + had massive filtering capacitors that acted like batteries with several + seconds of reserve capacity. Today's off-line switchers use + comparatively tiny capacitors; smart electronics does the filtering. + When the AC power goes down, the switcher's output quickly follows + suit. + + During the short time it takes for power to trail away the code may + very well be executing with interrupts disabled. Only NMI is guaranteed + to be available at all times. Power fail is such an important event, + that NMI is really the only option for notifying the software of + power's impending demise. + + Perhaps more should be said about power fail circuits at this point, + since so many suffer from serious design flaws. Most embedded systems + ignore power fail conditions. Running ROM based code with no dangerous + or critical external hardware, they can restart without harm from the + top when power resumes. However, two types of systems require + power-fail management hardware and software. The first category are + those systems controlling moving objects; a disk controller should park + the head, a robot should stop all motors, and an X-ray system should + shut down the beam. + + The other class are systems that preserve transient data through a + power-up cycle. A data acquisition system might need to keep logged + data even when power goes down, an instrument sometimes has to save + painfully collected calibration constants, and a video game should + remember high scoring individuals' initials and totals. + +Decaying Power + + Far too many designs rely on nothing more than battery backed up static + RAMs or some true non-volitile device like an EEPROM to store data + through multiple on/off cycles. More often than not these schemes work, + but all will sooner or later fail. Let's consider what happens when the + AC power fails. + + Without AC, the power supply stops working. The computer continues to + run from the energy stored in the supply's output capacitor. The amount + of time left before the computer goes haywire is proportional to the + size of the capacitor in microfarads and inversely proportional + + Until the computer's 5 volts decays to about 4.75 it continues to run + properly. At the 4.75 volt level most of the system's chips are no + longer operating in their design region. No one can predict what will + happen with any certainty. + + At about 4.8 to 4.9 volts the well-designed power fail circuit will + inject an NMI into the computer (some detect missing AC cycles, a + better but more expensive approach). Probably the system has only + milleseconds before Vcc decays to the 4.75 volt region of instability. + The NMI routine should quickly shut down external events and save + critical variables. + + After processing the power fail condition, the computer and external + I/O is all in a safe state. The voltage level continues to decline past + 4.75 volts, eventually reaching zero. Unfortunately, the supply's + capacitor decays exponentially. It will provide something between zero + and 4.75 volts for a comparatively long time (perhaps seconds). + + What does the CPU chip, memories, and glue logic do with, say, 4 volts + applied? No one knows. No vendor will guarantee any behavior under the + 4.75 volt level. Frequently the program just runs wild, executing + practically random instructions. Your carefully saved data or + meticulously protected I/O could be destroyed by rogue instructions! + + No power fail circuit is complete unless it clamps the reset line + whenever power is less than the magic 4.75 volt level. A suitable + circuit keeps the CPU in a reset state, preventing wild execution from + corrupting the efforts of the NMI power save routine. Motorola sells a + 3-terminal reset controller for less than a dollar which will hold + reset down in low Vcc conditions. + + Consider another case: suppose the power grid's sadly overload + summertime generating capacity experiences a brownout. If the line + drops from 110 VAC to, say, 80 volts, what happens to the +5 volt + output from your system's power supply? Most likely it will go out of + regulation, giving perhaps 3 or 4 volts until the 110 input level is + reestablished. Hopefully the power fail circuit will assert an NMI to + the processor chip. Using the conventional resistor/capacitor unclamped + reset circuit, the reset input will decline only to the 3-4 volt level, + not nearly low enough to force a reset when power comes back. + + The reset clamping circuit will not only keep the CPU in a safe state; + in this brownout case it will also insure that the system restarts + properly when +5 volts is reestablished. + + Regardless, NMI is the only reasonable interrupt choice for power fail + detection. + +NMI Abuse + + Unfortunately, NMI is widely abused as a general purpose interrupt. Use + NMI only for events that occur infrequently. Never substitute it for + poor design. + + It's not too unusual to see a divider circuit driving NMI, generating + hundreds or thousands of interrupts per seconds. Usually these designs + start life using a reasonable maskable interrupt. As the programmers + debug the system they find the CPU occasionally misses an interrupt, so + they switch over to NMI. This is a mistake. If the code misses + interrupts, there is a fundamental flaw in its design that NMI will not + cure. + + Your code will miss interrupts only if some bottleneck keeps them + disabled for too long. Always design the code to keep interrupts + disabled only while servicing the hardware. Reenable them as soon as + possible. With good reentrant design, interrupts should never be off + for more than a few tens of microseconds. + +On the Edge + + Quite a few processors implement NMI as an edge sensitive interrupt. + This guarantees that even a breathtakingly short pulse will set the + CPU's internal NMI flip flop, so the interrupt simply cannot be missed. + It might, however, cause several kinds of nasty problems. + + Suppose the input comes from the real world, perhaps after having been + transmitted a few feet. Without proper pulse shaping circuitry, the + signal could easily have ragged edges or even multiple, closely spaced + transitions. Maskable interrupts live quite happily with short bouncing + on their lines, since the first transition will make the processor + disable the input and start the ISR. Even the fastest code will take a + few microseconds to service and reenable the interrupt, by which time + the transients will be long gone. NMI cannot be disabled; every bit of + bounce will reinitiate the NMI service routine. The result: one real + interrupt might masquerade as several independent NMIs, each one + pushing onto the stack and recalling the ISR. + + Edge sensitive inputs respond when the input voltage crosses some + threshold. Imperfect digital circuits give a rather broad window to the + threshold. If the NMI input signal is perfectly clean but moves slowly + from the idle to the asserted state, it stays within the threshold + region for far too long, sometimes causing multiple NMI triggers. + + Finally, the edge sensitive nature of the NMI signal renders it + susceptible to every stray bit of electrical noise. A clean NMI driven + by a gate on the other side of a circuit board might pick up unexpected + noise from other parts of the circuit. + + Edge sensitive NMI inputs must be clean, noise free, and should switch + quickly and cleanly. + + Remember that debugging NMI service routines is sometimes tough. How + will you single step in an NMI service routine if, while debugging, + dozens more NMIs keep coming? Most of us debug code by stopping at a + breakpoint and looking at the registers and variables. If, when + debugging the NMI handler, another comes along while we're stopped, + after resuming execution the service routine will re-invoke itself, + probably corrupting a non-reentrant value. + + In summary, NMI is a valuable feature. Don't abuse it; restrict its use + to those few situations where only an NMI will solve a problem. + + Do you need to eliminate bugs in your firmware? Shorten schedules? My + [77]Better Firmware Faster seminar will teach your team how to operate + at a world-class level, producing code with far fewer bugs in less + time. It's fast-paced, fun, and covers the unique issues faced by + embedded developers. [78]Here's information about how this class, + taught at your facility, will measurably improve your team's + effectiveness. + + Free Embedded Muse newsletter - twice/monthly, hard-hitting technical + info that goes to 40,000+ engineers. Click [79]here to sign up or enter + your email here: + ____________________ Submit + + Latest [80]Embedded Muse: Replies to 'Is Assembly Dead' and 'on Taking + Charge'. + + Latest [81]blog: Is a heart rate of 72,123 beats per minute possible? + + [82][ganssle-dot-com-ad.jpg] Advertise with us! Reach 200K embedded + developers per month. More info [83]here. + __________________________________________________________________ + + The Ganssle Group - [84]info@ganssle.com - copyright TGG, all rights + reserved. Contact info [85]here. + +References + + 1. http://www.ganssle.com/ + 2. http://www.ganssle.com/ + 3. http://www.ganssle.com/navigation.html + 4. http://www.ganssle.com/onsite.htm + 5. http://www.ganssle.com/classes.htm + 6. http://www.ganssle.com/onsite.htm + 7. http://www.ganssle.com/tem-subunsub.html + 8. http://www.ganssle.com/tem-subunsub.html + 9. http://www.ganssle.com/tem-back.htm + 10. http://www.ganssle.com/expertwitness.html + 11. http://www.ganssle.com/blog/index.html + 12. http://www.ganssle.com/video/video-list.html + 13. http://www.ganssle.com/tools.htm + 14. http://www.ganssle.com/tools.htm + 15. http://www.ganssle.com/book.htm + 16. http://www.ganssle.com/bkreviews.htm + 17. http://www.ganssle.com/spcl_reports.htm + 18. http://www.ganssle.com/reports/ultra-low-power-design.html + 19. http://www.ganssle.com/item/perils-of-scope-probes.html + 20. http://www.ganssle.com/salsurv2020.html + 21. http://www.ganssle.com/item/debouncing-switches-contacts-code.htm + 22. http://www.ganssle.com/item/great-watchdog-timers.htm + 23. http://www.ganssle.com/item/history-of-the-microprocessor.html + 24. http://www.ganssle.com/item/becoming-a-consultant.htm + 25. http://www.ganssle.com/misc/wom.html + 26. http://www.ganssle.com/item/guide-to-managing-firmware-teams.htm + 27. http://www.ganssle.com/item/writing-great-comments-firmware.htm + 28. http://www.ganssle.com/item/how-to-test-ram.htm + 29. http://www.ganssle.com/item/becoming-an-embedded-developer.htm + 30. http://www.ganssle.com/inspections.htm + 31. http://www.ganssle.com/item/automatically-debugging-firmware.htm + 32. http://www.ganssle.com/item/instrumenting-firmware-for-debugging.htm + 33. http://www.ganssle.com/item/approximations-for-trig-c-code.htm + 34. http://www.ganssle.com/item/approximations-c-code-exponentiation-log.htm + 35. http://www.ganssle.com/item/creating-great-resumes.htm + 36. http://www.ganssle.com/articles-subj.htm + 37. http://www.ganssle.com/articles.htm + 38. http://www.ganssle.com/articles-subj.htm + 39. http://www.ganssle.com/articles-subj.htm#Communications + 40. http://www.ganssle.com/articles-subj.htm#Debugging + 41. http://www.ganssle.com/articles-subj.htm#Fun + 42. http://www.ganssle.com/articles-subj.htm#Hardware + 43. http://www.ganssle.com/articles-subj.htm#Historical + 44. http://www.ganssle.com/articles-subj.htm#Managing + 45. http://www.ganssle.com/articles-subj.htm#Math + 46. http://www.ganssle.com/articles-subj.htm#Memory + 47. http://www.ganssle.com/articles-subj.htm#Philosophical + 48. http://www.ganssle.com/articles-subj.htm#realtime + 49. http://www.ganssle.com/articles-subj.htm#Processes + 50. http://www.ganssle.com/articles-subj.htm#Tools + 51. http://www.ganssle.com/jack/ + 52. http://www.ganssle.com/randomrants.htm + 53. http://www.ganssle.com/randomrants.htm#electronics + 54. http://www.ganssle.com/randomrants.htm#business + 55. http://www.ganssle.com/randomrants.htm#softwareengineering + 56. http://www.ganssle.com/randomrants.htm#products + 57. http://www.ganssle.com/randomrants.htm#philosophy + 58. http://www.ganssle.com/randomrants.htm#misc + 59. http://www.ganssle.com/randomrants.htm#history + 60. http://www.ganssle.com/randomrants.htm#software + 61. http://www.ganssle.com/randomrants.htm#random + 62. http://www.ganssle.com/randomrants.htm#fun + 63. http://www.ganssle.com/randomrants.htm#realtime + 64. http://www.ganssle.com/jokes.htm + 65. http://www.ganssle.com/contact.htm + 66. http://www.ganssle.com/contact.htm + 67. http://www.ganssle.com/advertise.html + 68. http://www.ganssle.com/search/search.html + 69. http://www.ganssle.com/bio.htm + 70. http://www.ganssle.com/expertwitness.html + 71. http://www.ganssle.com/privacy-policy.html + 72. http://www.ganssle.com/tem-subunsub.html + 73. http://www.ganssle.com/tem-subunsub.html + 74. http://www.ganssle.com/tem/tem406.html#article4 + 75. http://www.ganssle.com/contest.html + 76. http://www.ganssle.com/articles/aintrp.htm + 77. http://www.ganssle.com/onsite.htm + 78. http://www.ganssle.com/onsite.htm + 79. http://www.ganssle.com/tem-subunsub.html + 80. http://www.ganssle.com/tem/tem407.html + 81. http://www.ganssle.com/blog/blog/heart-rate.html + 82. http://www.ganssle.com/advertise.html + 83. http://www.ganssle.com/advertise.html + 84. mailto:info@ganssle.com + 85. http://www.ganssle.com/contact.htm -- cgit v1.2.3-54-g00ecf