Chuck Peddle is the father of both the 6800 and then the 6500. It is not a councidence that they are similar in many ways.

 

OK, my experience with interrupts is minimal. Most of my assy coding was short subroutines to speed up BASIC code.So where do I find the opcode set so I can begin my first baby steps in assy. Starting off what is the CPU I should plan on using? A website would be great. Thank you.

As I understand it 6502 and 6800 CPUs are cousins, correct?

BTW I still think in BASIC.

That will suit you fine. You want to think in baby steps.

Move variable into register.
Add number to register.
Store register back to variable.
Is value in register zero?
If no, continue with next instruction.
Else, go to that instruction over there.

If you are entertaining playing with Atmel AVR, I would suggest you get any one of the bare-metal through-hole DIP packages:

ATmega48-PU
ATmega88-PU
ATmega168-PU
ATmega328-PU

ATmega48A-PU
ATmega88A-PU
ATmega168A-PU
ATmega328A-PU

ATmega48-10PU
ATmega88-10PU
ATmega168-10PU
ATmega328-10PU

ATmega48-20PU
ATmega88-20PU
ATmega168-20PU
ATmega328-20PU

(not sure on all the part number variations, I have to look them up.)

and buy a Pocket AVR Programmer.
https://www.sparkfun.com/products/9825

If you choose to go this route I will show you how to get started.

 

If you want a smaller package, you can choose:

(8-pin DIP)
ATtiny25V-10PU
ATtiny45V-10PU
ATtiny85V-10PU

ATtiny25V-20PU
ATtiny45V-20PU
ATtiny85V-20PU

first number 2/4/8 refers to number of kilobytes of code (flash) memory.
10/20 refers to max clock speed in MHz.

(20-pin DIP)
ATtiny2313V-10PU
ATtiny2313-20PU

 

I've run out of gas tonight, but I will pursue this tomorrow, Just wanted you to know I haven't come close to stopping. When I do assy, I flowchart for best efficiency.

 

Flowcharting is good. I prefer to use flowcharts more than pseudo-code.
Flowcharts are good for teaching, conveying programming flow, and documentation.
For personal work, I tend not to use flowcharts as I can visualize the chart on the fly as I program.

Classic example exercises in flowcharting is successive approximation ADC and sorting.

See my blog on Structured Programming.

 

The Atmel is a nice chip. However, I suggest you still might consider PIC's.

The enhanced mid-range PIC's (e.g., 16(L)F1829) and above have automatic context saving and restoration on interrupt and return. It's not a huge deal, but it saves a few steps assuming an interrupt may occur during a math calculation where knowing STATUS flags, such as the zero and carry flags, is useful. There are 49 instructions, and 16-bit counters (decimal = 65535 ). Tracking the 17th bit gives a full 5 digit counter (decimal = 99999). Of course, you can count the counter turnovers and get 24 bits (>7 digits).

The newer enhanced mid-range (e.g., 16(L)F18426 series) give 2, 24-bit timers with only 50 instructions to learn.

Either 8-bit MCU can probably do what you want to do. It's a matter of taste. PIC's seem more popular for Assembly language programming.

I agree on flow-charting being useful, but in doing some math, e.g., BIN2BCD, I have found a spread sheet more useful for keeping code to a minimum.

 

If you choose to take the Atmel AVR route, you can get started without having to purchase any hardware initially.

Download Atmel Studio 7

It has a simulator and can run both ASM and C in the same project.
I can create a blog on this when you are ready.

Or you can start here:
http://www.nicerland.com/eduFiles/AVR/Tutorials/AsmProgrammingInAtmelStudio7.pdf

This second link is added as a reference. It is probably has more detail than what you need to get started.
http://ww1.microchip.com/downloads/en/DeviceDoc/Getting-Started-with-Atmel-Studio7.pdf

 

When you decide that you need higher performance in a chip I would recommend moving to STM32 ARM MCUs. The performance will blow you away.

 

The clear market dominance is ARM core, not only at embedded CPU but in
ASIC work as well.

https://www.arm.com/zh/files/event/1_2015_ARM_Embedded_Seminar_Richard_York.pdf

https://m.eet.com/media/1246048/2017-embedded-market-study.pdf

Atmel/Microchip rapidly introduced/introducing ARM core based parts. As are almost all other
CPU manufacturers.

Note that other vendors have niches, eg. low end low pin count Microchip, analog capability
Cypress (with ARM core), high end graphic Freescale....but ARM dominates in WW shipments
and its growing.

Each of us has his/her favorite, I am no exception, Cypress because of extensive analog, ARM
cores, routable, DSP, extensive logic element library from gates to MSI to COM. And create
your own components (component is onchip resource). Example is DDS component done by a
user for general purpose work, specialized PWM by another......HW creation by Verilog for highly
custom work, or for simple stuff with a twist. Even codeless designs. Its FPGA like fabric lending
itself to flexibility not found in other manufacturers.

But I preach. In short I would consider ASM or C programming with ARM core based MCUs.


Regards, Dana.

 

Cost counts, as does the learning curve. I've been putting background thought in the project itself, While in count mode it would be better to count in simple binary? Then convert the binary number into BCD for display decoding? Or count in BCD in the MCU? The former would be much faster I should think. The latter slower but simpler to program, especially for the 7 segment display.

 

Cost counts, as does the learning curve. I've been putting background thought in the project itself, While in count mode it would be better to count in simple binary? Then convert the binary number into BCD for display decoding? Or count in BCD in the MCU? The former would be much faster I should think. The latter slower but simpler to program, especially for the 7 segment display.

In terms of CPU efficiency it doesn't matter either way.
The standard method is to count in binary and convert to BCD for display.

What is your maximum input clock frequency?
What is your minimum input clock frequency?

Are you interested in frequency and period or simply total count?

 

Counting in binary helps if there is any math to do before display.

 

I'm not a complete novice in coding.Having said that I find learning a new language intimidating.

yep. Don't ever try LISP, COBOL or FORTH. APL (A programming Language) is still better than LISP.

LabView is totally weird. It's based on data flow. VI's as they are called, execute when all the data is available. very easy to write parallel processes. Since it isn't sequential unless forced, you have the possibility of "race conditions" in software.

LOGO is baffling right now.

I have a long list including assembly languages.

 

One of my first languages was FORTRAN, from there I went on to BASIC, then tiny BASIC on the Trash80. Then a PET. Anyone remember the PDP series of computers?

 

In terms of CPU efficiency it doesn't matter either way.
The standard method is to count in binary and convert to BCD for display.

What is your maximum input clock frequency?
What is your minimum input clock frequency?

Are you interested in frequency and period or simply total count?

Simple speed is most important, hardware will supplement the MCU counter/display I am after a simple counter/display at this point.

I'm beginning to wonder If I have bitten off more than I can chew.

 

yep. Don't ever try LISP, COBOL or FORTH. APL (A programming Language) is still better than LISP.

LabView is totally weird. It's based on data flow. VI's as they are called, execute when all the data is available. very easy to write parallel processes. Since it isn't sequential unless forced, you have the possibility of "race conditions" in software.

LOGO is baffling right now.

I have a long list including assembly languages.

I studied all of the above, including SNOBAL, ALGOL, Pascal.

Turbo Pascal Version 1.0 has got to be one of most efficient platforms I have worked with. Totally resident in memory.

APL was one of my favorites. It was amazing how much you could accomplish with it.
Forth had a sound rationale behind it, following in the shadows of APL. It was meant for rapid, efficient, machine control on a compact footprint.

 

Cost counts, as does the learning curve. I've been putting background thought in the project itself, While in count mode it would be better to count in simple binary? Then convert the binary number into BCD for display decoding? Or count in BCD in the MCU? The former would be much faster I should think. The latter slower but simpler to program, especially for the 7 segment display.

Count in binary. But note in the code, you deal with the decimal value; not binary. . On a MCU, conversion to BCD is much easier than with discrete logic. Here’s a function in C, that returns the lowest digit in BCD of any integer. Call it repeatedly until the number is zero. The function value is the BCD digit.

byte Decimal2BCD(int *Num) {
   int tmpNum = Num;
   Num = Num / 10;
   return Decimal2BCD =
           tmpNum % 10;
}

 

I miss the old decimal mode in the 6502. Setting that bit determines whether the ALU works in binary or decimal. It was very handy.

 

I miss the old decimal mode in the 6502. Setting that bit determines whether the ALU works in binary or decimal. It was very handy.

... and on the RCA1802.

 

I'm surprised no one has mentioned the good'ol 8051 ... it's easy to learn, and its latest incarnations have become very powerful... although some people feel it's become obsolete. I don't.

Personally, it's not a chip's language that I find intimidating, but rather its architecture. And the 8051 family is simple enough to understand thoroughly in a short time.