[85] Tip of the day

[GARTHWILSON]

Tip of the day, #36

Debugging. Part II. Software. A simple effective debugging tool is a piezoelectric beeper, the kind that's .010"-.020" thick and needs an AC signal in order to sound.



The one at the top is in a black plastic housing that's about 3/8" thick and improves the volume if there's no sounding board. The small one is 3/4" diameter and .012" thick. The bigger one that's tarnished from skin oils and soldering at four points around the edge (but would still work perfectly fine) is 1-3/8" diameter and about .020" thick.

They can be taped or soldered onto the breaboard, so the entire breadboard acts as a sounding board. I've even used scissors to cut them down to fit a tight space, like this one on the back of a mostly analog breadboard with a microcontroller on it:


Very simple beep and delay routines should run on the first try. Write about 3 beep routines of different frequencies and maybe different durations so you can tell them apart. These should save the processor registers like an ISR does. Once these work, call them at appropriate places in your next routine. Put delays between the beeps to make them easier to separate when you hear them. Does it make it to point A before crashing? How about point B? Does the loop that point C is in get run the right number of times? Keep re-assembling and trying your code, each time narrowing down the problem area. LEDs can also be used to monitor the progress; but the software-driven beeper's sound "signature" assures you that the output is not a random effect of a crash. As code development advances, you might incorporate other debugging routines; but in the absence of expensive debugging tools, the lowly beep is indispensable as a "crash-finder".

Without a digital-storage oscilloscope, you can still study a pulse train output by making the software repeat in a loop for an analog scope. For real-time, things that cannot be slowed down to deliver a beep can be watched on the scope with probes on various I/O lines. Sometimes it can be a challenge to get the triggering and sweep rate just right, but it's usually doable. (to be continued)

[GARTHWILSON]

Tip of the day, #37

Debugging.  Part III.  An ounce of prevention... Take a building-block approach.  Start with the really simple stuff, then use those things as components to build or debug more advanced components, and so on.  The job is only complicated if you don't break it down into manageable chunks, conquer them, and then put them together in steps.  Working for small, low-budget outfits, I have found that the lack of expensive debugging tools actually teaches you to write better code.  You can't have the attitude that "I'll whip out this code in record time and debug it later."  Out of necessity, I've become more structured and neat in my programming, documenting everything thoroughly, making the code as readable as I know how, and proofreading.  Large companies are finally starting to see the value in this, and the industry magazines have recently had some articles on code inspection and having committees of the programmers' peers proofread the code.  I sometimes catch bugs when further commenting code that's already working but not exhaustively tested yet.  I comment as if trying to explain it to someone else who hasn't been following my train of though on it.  (If I come back to change it a year later, I'll need the comments anyway.)  As a result of this madness, no user has ever found a software bug in any product or automated test equipment I programmed.  The projects have had from 700 to 10,500 lines of code.  BTW, using a lines-of-code-per-day benchmark of programming performance is a sure way to end up with inefficient, buggy code that's hard to figure out and fix or modify later.  I once worked with a programmer who typed non-stop.  I always wondered what he was typing.  After he left the company, I had to fix a 4-page routine he wrote.  When I was done, it was down to a half page, bug-free, clearer, faster, and did more with less memory.  (Eventually most of what he wrote had to be redone.)

[GARTHWILSON]

Tip of the day, #38

Don't ignore your assembler' more advanced features.  Macros especially make assembly code more concise, even hiding the ugly details of conditional assembly based on input parameters or other factors.  Since there's no run-time overhead, macros don't slow the execution down like JSR and RTS do, and a macro may be worth defining even if you only use it once.  The simple example

Code: Select all

        DISPLAY_IMM    "Press YES key to continue"
        WAIT_FOR_KEY   YESKEY

could display the message and then wait in a loop until the user presses the Yes/Continue key.  The first line, "display immediate", indicates that the parameter is the actual string to display and not just an address.  It might assemble

Code: Select all

        JSR    DISP_QUOTE
        BYTE   25             ; (the string length)
        BYTE   "Press YES key to continue"

where the first line calls a subroutine, which uses the return address to pick up the next byte which tells how many bytes following make up the string that is to be displayed, gets the string, and advances the return address past the data to the next actual instruction.  The WAIT_FOR_KEY line might assemble

Code: Select all

ReScan: JSR    SCAN_KEYPAD
        CMP    #YESKEY
        BNE    ReScan

Suddenly assembly is a higher-level language than you thought.  A macro may replace hundreds of lines.  A complex piece of code may be much more clear with certain portions pre-defined as macros with descriptive names.  A macro's parameter list can be as long as you want, as long as it all fits on one line of usually 255 characters.  Most assemblers allow nested macros.  The assembler's list code output file shows exactly what got assembled.

Edit, 7/28/12:  I put an article on my website about macros, focusing on program structures to get better control of your project.  It is posted at http://wilsonminesco.com/StructureMacros/index.html and has accompanying working source code.  Here is probably the simplest of the program structures:

Code: Select all

        CMP  #14
        IF_EQ            ; clear enough that it really needs no comments
           <actions>
           <actions>
           <actions>
        END_IF

No label is needed.  It assembles exactly what you would do by hand, with no penalties, just better readability.  It can be nested many levels deep too, and each branch instruction will go to the right place.

[GARTHWILSON]

Tip of the day, #39

Some of you have mentioned using PIC microcontrollers.  Macros can again make your PIC code a little easier in perhaps an unexpected way.  Define macros named after 65c02 mnemonics.  For example, disabling interrupts on the PIC requires a loop because if an interrupt hits during the instruction to disable interrupts (clearing GIE), the interrupt service will still go forward, restoring the ability to interrupt when done.  It must go back through the loop again if it finds that interrupts are not disabled after the instruction to disable them.  Put the loop in a macro, and name it SEI, like the two-clock 6502 instruction that does what the PIC can't insure in less than 12 clocks.

Doing a conditional branch on the PIC takes two instructions: one to test the flag, whether zero, carry, etc and skip around the branch instruction if appropriate, plus the actual GOTO instruction.  Define macros in your PIC code and call them BEQ, BNE, BMI, BPL, etc like the 6502 mnemonics.  In this example, the PIC takes 8-12 clocks to do what the 6502 does in 2-3.  This is often the case.  In my experience, the 65c02 can do a job generally in half the number of clocks it takes the PIC to do the same job.  (Beware when Microchip tells you their PICs have single-cycle instructions—when they say one cycle, they really mean an instruction cycle, which is 4 clock cycles.  The clock info here is unrelated to macros—just a plug for the '02.)

[GARTHWILSON]

Tip of the day, #40

Crashing is common during development and the reset button gets used. Most crashes do not make the computer write garbage all over your program so it's not usually necessary to re-load a RAM-resident program to get it going again. Instead of having your ROMed reset routine start over new every time, put in a choice to either

A. start new,
B. keep the old program but don't run it yet, or
C. keep the old and even set it up again and run it so you don't have to re-issue instructions and parameters for the program to process to get things going again.

You may not need choice B if you're only doing assembly language unless the target computer itself is doing the assembling and you need for it to keep the old pointers, tables, etc..

My workbench computer has the LCD ask "New/Old/Init-Ap?" The choice is made using the first 3 keys of the 5-key keypad. Init-Ap executes a routine at the address I stored in the Init-Ap variable when I loaded the program. (The variable is initialized to point to a do-nothing routine if you choose option A above.) Without fixing the cause of the crash, 2 seconds may be all that's needed to reset and restart the program to try a different condition to see how it behaves. (Don't you wish Windoze were so considerate of your time?!)

Here's the display of choices on mine. The three correspond to the three keys in the left column in the keypad.

[GARTHWILSON]

I've reached the end of the tips I can think of that can be more-or-less adequately communicated without diagrams or lines of code.  Edit:  Tips resume 2/3 of the way down page 4 of this topic, with Tip #41, "Getting started," with considerations that will save the newbie a lot of indirection and frustration.  And since we're not on the Delphi forum anymore and I can add photos, diagrams, and code, I might continue to slowly add tips.

Although this topic has increased forum traffic, there have not been any responses.  Everyone seems to be taking it in silently.  I'm not particularly disappointed, but I told Mike that it was not my intention for this to become my own personal column.  He was quite supportive.

I would like to see others add their own tips from their work with other 65-family parts.  This may include the 65134, 65265, 65151, and other microcontrollers, 6508, 6509, 6510, 65F11, and other variations of the 6502 microprocessor, the 6523 & 6525 TPI's, 6526 CIA, 6532 RIOT, 6552 dual ACIA, 6529 IOD, 6590 EBC, 6545 CRTC, 6560, 6561, 6567, 6569, 6572, and 6573 VIC's, 6582 SID, and so on.  Most of us have no experience at all with many of these and may never see a lot of them, but your tip might spark an idea and save the day for someone in an unexpected way.  Give it a try.

Almost all of my tips were from personal experience.  I have broken some rules of writing trying to limit the length of some of them.  Everyone will have their own style, but I would only suggest being sure of what you write.  Who knows—I might challenge you on the tip (or so it may seem).  That's not to make life difficult, but just to learn more or make sure I'm understanding something right.  Go for it.

Edit, Apr 26, 2012: I have a 6502 primer, with the index at http://wilsonminesco.com/6502primer/index.html , for those wanting to build their own 6502 computer.

[saipan59]

Garth,
You've done a great job with your tips!

Here's one from me:
For address decoding on a not-real-fast design, try using a 74LS145 instead of an LS138. the '145 has open collector outputs, which means you can "wire-OR" the outputs to change the memory mapping. For example, configure it so that outputs 0-7 are each an 8K block. By simply connecting (for example) 0 and 1 together, you now have a 16K decoded block. Use male Berg-type pins with those little black jumpers to make quick changes.

This approach was hotly debated some months ago in the "PCB project" discussion. Because there is no active pullup on an O.C. signal, the signal integrity may not be good enough for higher clock speeds. What is "higher"?? Well, it depends on several things, such as the value of the pullup resistor, the loading on the signal, etc. I've used this approach at 1.84 MHz with no problems, and it should work at 2 or 3 times that speed.

Pete

[trmelton9]

All the boards I got from Rockwell & DynaTem had a 4MHZ crystal & a 74HC74 to divide it to 1MHZ. The DynaTem boards also had jumpers so that the board could run at 2MHZ.
Until I read your Tip I really never thought of connecting a crystal directly to the 6502. I remeber looking at the DATA sheet & seeing that it had an onboard oscillator, but the examples I had didn't use it that way.

Ted Melton

[trmelton9]

Do you have any website references to these serial flashparts ? I had thought about using flash parts, but I haven't had the time to do the research. I think that would be a good solution for industrial controllers & data acqusition.
Ted Melton

[GARTHWILSON]

Quote:

Do you have any website references to these serial flashparts ?

For Atmel, go to www.atmel.com/atmel/products/prod108.htm and you'll see the different Dataflash parts you can download data sheets on, in three different file types including .pdf for Acrobat Reader.  The AT45DB642 is at the bottom of the list.  That's the 8Mx8 serial flash memory.

Sandisk ( www.sandisk.com ) supposedly has a 64Mx8 serial flash chip now, but I went to their website after seeing an ad for it, and all I can find is a couple of articles about it (TriFlash) plus info on their memory cards and things like that, and how to buy those things.  I E-mailed them twice in the last two weeks asking the same thing, and they have not responded.  I asked about the IC that was advertised, saying I don't want a module, a card, a socket, or any of that—"I want the IC.  Can I get just the IC you advertised?"  I'm still interested, but the fact that they don't get back to customers (or potential customers in this case) in two days or better speaks very, very poorly of a company.

[GARTHWILSON]

Quote:

Until I read your Tip I really never thought of connecting a crystal directly to the 6502.

My data books don't recommend it for NMOS 6502's, but I never looked into what the reason might be.  I've done it with the CMOS 65c02 though.

Edit: I have a section on clock generation, with diagrams, at http://wilsonminesco.com/6502primer/ClkGen.html.

For a product in the late 80's, we switched an extra resistor in the RC clock circuit in and out with an output bit so that the computer would save battery power running at 200kHz most of the time, and then go to 1MHz temporarily to keep the customer from waiting when it had to do a string of lengthy floating-point calculations.  Another edit: I quit using floating-point years ago for most applications, preferring instead the scaled-integer method described at the beginning of my index page about large look-up tables for hyper-fast math, at http://wilsonminesco.com/16bitMathTables/index.html.

[trmelton9]

I checked out the Atmel parts. They look interesting. What's the avalibility & price of these parts ? Are you using them for DATA storage only ? Or is there some way to use them for Program Code ? Like boot with a small EPROM, & then copy from the Atmel part to RAM & then run from there ? How would you get the prgram into the Atmel part to start with ?
Ted Melton

[trmelton9]

I agree that will work, but if anyone tries to trouble shoot the board ... ? Isn't this just a way to make reverse engineering more difficult ?:) Just try & disasemble that program. If you're wire wrapping, I don't see a benefit. If you're laying out a PCB, what's 1 or 2 more VIA's
Ted Melton

[GARTHWILSON]

Quote:

I checked out the Atmel parts. They look interesting. What's the availability & price of these parts ? Are you using them for DATA storage only ? Or is there some way to use them for Program Code ?  Like boot with a small EPROM, & then copy from the Atmel part to RAM & then run from there ? How would you get the program into the Atmel part to start with ?

Edit, 9/1/22:  The 8-megabyte 26VF064 in an 8-pin SOIC package is $3.35 in qty 1.  Obviously the per-megabyte price has come way down.  What's below is what I wrote 21 years ago though:

The 2Mx8 is about $16, available now.  I got some for engineering use (not production quantities yet) from All American.  All American  normally sells to OEMs, but I'm sure there's no reason a hobbyist can't call them up with credit card in hand and order.  Hobbyists just need to make sure they make it quick for these distributors and not take too much of their time for piddly small orders, so that they don't decide not to sell to them.

I'm trying to get a few of the 8Mx8's right now.  Those are not available in production quantities yet, but small quantities for engineering are supposedly being shipped.  (I would call them "engineering samples", but at $35 each, they don't usually send them out free.)

I've made the Atmel 2Mx8 work; and although the data sheet looks pretty complicated, everything worked the first time when I just followed the instructions and timings they give.  There don't seem to be any hidden tricks.  Some of their instructions are for storing.  Storing data is just as easy as reading it, except that it takes a couple of milliseconds so you have to wait for it to get done before you issue another similar command.  They're not like EPROMs which are generally programmed in a programmer and not altered once in the circuit.  Think of the flash more like a disc, except you don't have to have a SCSI port or learn a disc controller.  As far as a FAT or anything like that, you can do it any way you want, so there's no reason for it to be intimidating like it might be to learn how to use a floppy disc drive controller.

The Atmel 8Mx8 looks like it operates the same way, but I can't speak from experience yet.  You can store whatever you want in either of these, and it won't care if it's a section of the phone book or a collection of executable programs (or anything else for that matter).  The flash memory is divided into pages of 528 bytes each for the 2Mx8 and 1056 bytes each for the 8Mx8.  The reason they're a little more than 512 and 1024 bytes per page is that there's some extra to store things like where the next page for the particular file is.  This comes into play because files in flash can get fragmented.  The way to make sure they don't get fragmented when the flash is relatively full and files are constantly getting written, deleted, or modified is to always be moving them around to produce large enough empty spaces to keep a whole file together when you store it.  All this moving around is is not only slow, but will eventually wear out the memory, unlike the case with a big battery-backed SRAM.  I can't find the spec. quickly right now, but I think any given page is good for something in the range of 100,000 to 1M write cycles before it becomes undependable.  If you use a stationary FAT without some sort of wear-leveling method, the FAT area would probably be the first to wear out if your application does a lot of writes.  On the other hand, floppies probably wear out faster, but they're probably more likely to get damaged first.

The Sandisk TriFlash 64Mx8 is $110, or less than $2 per megabyte, but that's the one I haven't been able to get any info out of the company yet on.

Garth

[GARTHWILSON]

Quote:

I agree that will work, but if anyone tries to troubleshoot the board ... ? Isn't this just a way to make reverse engineering more difficult ?:) Just try & disassemble that program. If you're wire wrapping, I don't see a benefit. If you're laying out a PCB, what's 1 or 2 more VIA's

I must apologize that I'm not sure what you're responding to here.  If it's Tip #1, it's true that you won't gain much by mixing the address and data lines around if you're wire-wrapping; but for the poor guy who has to lay out the board, whether 2 layers or 12, it might make the difference between fitting it in easily and pulling out his hair.

Maybe I missed it though, since I don't know where the VIAs come in.  Let me know and I'll correct this post.