no it's incorrect.

How about this thread: http://forum.allaboutcircuits.com/showthread.php?t=90913

How about opening a blog (wordpress, altervista, blogspot etc.), doing some actual work, and then discussing your stuff, and how you can archieve further goals?

It is not correlating.

8 BIT MICROCONTROLLER is just saying, the data width is 8bit.

Instructions will use 8bit operands, but there could be some 16bit one's, using two 8bit registers.

Like kind of a "class". A Ford Fiesta is not a Mercedes 300SL and is not a mountainbike.

SPECIFICATION is the definition what is the input data, the existing operations and the way they are implemented, and the ususal field of application. It is also called "the Architecture".

Have you downloaded 16F5X.pdf ?
Have you actually read it?
There you have a block diagram of a simple MCU.

512 x 12 bit words program FLASH + PC (program counter)
ALU, and 8bit register file + FSR (File select register)
TIMER (one 8bit timer)
IO port

About 35 Instructions.

If you follow the advice, and learn about PIC 16F5X, you will be able to answer most your questions yourself.

Also download MPLABX, and run some programs in the simulator, and examine the machine registers.

thanks for help I have downloaded datasheet and I am reading. but can you tell me where I did made mistake

 

OK thank you too for taking the effort.

I have spent a lot of time with the 16F5X. It helped me to learn.

1. A Microcontroller is a CPU. It is the same.

8 bit micro controller
8 bit CPU - same thing

8 bit ALU - correcct

8 bit decoder - incorrect. Instruction encoding is normally different size

8 bit data - correct. Obvious.

8 bit instruction - Most CPU have one operand, or two operand, or even more than that for each opcode.

Simple instruction might be 8bit, but might be different size. And some instruction take 2 words or more.

64 k program memory - nobody can know that. Normally, it is less for 8bit chips.

64 k data memory - you need 16bit address for that, and normally 8bit CPU has much less installed memory.

8 bit port input
8 bit port output - Most CPUs have 8bit ports, even 16 or 32bit one's

16 bit timer - No correlation here.

You put together a list but there is not much correlation.
The data size is 8bit, so the ALU also is 8bit but it might have some 16bit operations.

There is also an address generation unit inside controller chips.

2

I'd recommend you to study not just the 16F5X, but also other, more complex 8bit conntroller datasheets.

Happy reading! Some are 300 or 400 pages.

It takes a lot of practice, and reading, and time, to master Microcontroller, and to be able to scribble one on paper, or build with software/FPGA etc.

It takes much less maybe to take a source somewhere, mangle through a compiler, and cobble together a controller core on a large FPGA that somehow works.

3

How about trying displays, such as character LCD, GLCD, and color TFT? It will keep you occupied for months.

Learn the basics first and then try something advanced.

 

OK thank you too for taking the effort.

I have spent a lot of time with the 16F5X. It helped me to learn.

1. A Microcontroller is a CPU. It is the same.

8 bit micro controller
8 bit CPU - same thing

8 bit ALU - correcct

8 bit decoder - incorrect. Instruction encoding is normally different size

8 bit data - correct. Obvious.

8 bit instruction - Most CPU have one operand, or two operand, or even more than that for each opcode.

Simple instruction might be 8bit, but might be different size. And some instruction take 2 words or more.

64 k program memory - nobody can know that. Normally, it is less for 8bit chips.

64 k data memory - you need 16bit address for that, and normally 8bit CPU has much less installed memory.

8 bit port input
8 bit port output - Most CPUs have 8bit ports, even 16 or 32bit one's

16 bit timer - No correlation here.

You put together a list but there is not much correlation.
The data size is 8bit, so the ALU also is 8bit but it might have some 16bit operations.

There is also an address generation unit inside controller chips.

2

I'd recommend you to study not just the 16F5X, but also other, more complex 8bit conntroller datasheets.

Happy reading! Some are 300 or 400 pages.

It takes a lot of practice, and reading, and time, to master Microcontroller, and to be able to scribble one on paper, or build with software/FPGA etc.

It takes much less maybe to take a source somewhere, mangle through a compiler, and cobble together a controller core on a large FPGA that somehow works.

3

How about trying displays, such as character LCD, GLCD, and color TFT? It will keep you occupied for months.

Learn the basics first and then try something advanced.

thanks for your Explationation. It will help me a lot, If I need any information, I will post

 

sure. Feel free to ask any details. I will reply, or others will jump in.
Dont mind sometimes I confront people, but it's not difficult to get along with me.

Some years ago I wanted to know how a SEGA TV game machine works, and did not have much of clue.

 

sure. Feel free to ask any details. I will reply, or others will jump in.
Dont mind sometimes I confront people, but it's not difficult to get along with me.

Some years ago I wanted to know how a SEGA TV game machine works, and did not have much of clue.

I am having problem how to decide decoder bit for 8 bit controller I don't want to copy another micro controller I just want to know logic why we used

 

I am having problem how to decide decoder bit for 8 bit controller I don't want to copy another micro controller I just want to know logic why we used

Some CPUs are kind of pervert- they contain a different, simpler CPU, which is executing a program from a decoder ROM (sometimes called microcode).

For each complex instruction, this internal controller will fetch bits from a bus, enable circuits, latch the value, write back, etc.

How in turn this secondary controller works...it is kindof a chicken and egg problem.

Guess in the old days developers knocked on wood, twinkled with one eye and said "Fingers crossed!".

Sometimes what I explain is quite obvious, sometimes not so obvious. Depends on the architecture, so, make yourself familiar with a couple of different controllers.

I introduced one- the 16F5X. It is only 50 pages or so.

 

Instead of having the OP (who is clearly a beginner) reading and starting at a document that doesn't explain anything, how about giving a resource that actually explains the parts and what they do?

Perhaps, something like this...

...or even this.

 

Instead of having the OP (who is clearly a beginner) reading and starting at a document that doesn't explain anything, how about giving a resource that actually explains the parts and what they do?

Perhaps, something like this...

...or even this.

I don't know what does mean by op but I think you are talking about me am I right?

 

I have not yet seen a manual or book: How to construct a CPU step-by-step, failsafe and efficient.

I did read the history how the 68000 was engineered- there was one guy who applied the cut&paste method- with paper.

I also did read history of the C language, and I examined BCPL emulators- I must say, at first I did not have much of a clue.

In the meanwhile, I did do other things which I understood more.

Take the SEGA Master System manual- that's actually quite horrible when you have to deal with the tiles based VDP, and access it in z80 assembler via port writes.

There are many things which can go wrong and no "failsafe working straight of of the box" software package exists.

I'd reciommend OP to think about "Message in Space".

Think of each line on the .matrix as a CPU instruction. Now you just add a comperator, and a small table with values, and then you activate some command sequence.

Right, you need a sequencer. For each instruction, you need to perform a number of smaller steps.

Then OP can see- bit width is totally secondary- construct as needed, 3 bits here and 9 bits there. Just leave the bits empty when not needed

It does not have to be a fully functional microcontroller for the first trial run. Just a very primitive one.

I could build one from whatever components, but I'd say it takes considerable mileage to do it properly. And it is not easy.

 

I don't know what does mean by op but I think you are talking about me am I right?

OP can be either Original Poster, or Original Post
, depending on usage.

And, yes, I was referring to you as the OP.

 

If CPU is 8 bit and ALU is 8 bit why we can't use 8 bit instruction decoder

 

That is the usual block diagram of a controller.

However, TIMER, A/D, IO ports, EEPROM, SFRs, even the ALU are not essential for a microcontroller.

It is all explained with great detail, but the core of the controller is just called "control logic".

If you implement the control logic, you don't neccessarily need TIMER, A/D, IO ports, EEPROM, SFRs, and ALU. Even if for some purposes these devices might be handy.

You can perfectly build a simple microcontroller which is able to branch, and which is not doing anything useful, and it is still kind of a very primitive microcontroller.

Or if you go further, it is just a circuit that somehow reminds of a microcontroller, ilf you extend it further, some day, you'g get a microcontroller.

But here my point- eventually it'd be sufficient to get an idea how a microcontroller works- without to understand all details in terms of memorizing them to the bone.

 

I have not yet seen a manual or book: How to construct a CPU step-by-step, failsafe and efficient.

I did read the history how the 68000 was engineered- there was one guy who applied the cut&paste method- with paper.

I also did read history of the C language, and I examined BCPL emulators- I must say, at first I did not have much of a clue.

In the meanwhile, I did do other things which I understood more.

Take the SEGA Master System manual- that's actually quite horrible when you have to deal with the tiles based VDP, and access it in z80 assembler via port writes.

There are many things which can go wrong and no "failsafe working straight of of the box" software package exists.

..and this is relevant because...?

Designing the CPU at the Register-Transfer Level (RTL), allows one to see the individual operations and how they work together to produce a CPU. It also helps one to understand how opcodes are created from the control signals for each RTL block and how the size of the opcodes is independent of the data bus size.

 

OP can be either Original Poster, or Original Post
, depending on usage.

And, yes, I was referring to you as the OP.

I don't mind you can say anything. I only want to complete my project

 

If CPU is 8 bit and ALU is 8 bit why we can't use 8 bit instruction decoder

Of course you can. But you don't have to. It could be 5 bit, 9 bit, or 13 bit.

In reality, you dont normally have such affinity.

8bit controller only says the data bus is 8bit, and the regular ALU operations have 8bit operands (not even neccessarily 8bit results).

There is for instance something called EA or effective address- sometimes combined from the PC, and paging bits, and SFRs.

A so-called EA calculation unit. Not normally the input operands will be 8bit and neither the output.

But if you wanted to, it could be.

Make yourself free of that 8bit, 16bit consideration. It is just an agreement. We could have 9bit CPUs. It is an agreement which makes working together easier.

8bit CPU says not much if nothing. It only says "this CPU is built in a way it has an 8bit bus and mostly is dealing with 8bit data", in terms of conformity.

What if we'd have 7bit chips, 13bit chips, 5bit, and 9bit- nothing matching together properly.

So we need "classes" of 8bit, 16bit, 32bit, etc.

Internally, you are not bound to that at all.

 

This is a pretty good intro at a glance.

 

..and this is relevant because...?

Designing the CPU at the Register-Transfer Level (RTL), allows one to see the individual operations and how they work together to produce a CPU. It also helps one to understand how opcodes are created from the control signals for each RTL block and how the size of the opcodes is independent of the data bus size.

It is just kindof relevant. If you'd examine that manual, you'd eventually consider not to program this machine, even if you'd be able to- unless you'd have good reasons.

I wrote there is no correlation between data bus size and opcode size.

Sure you have the control logic, small state machines, sequences of RTL operations, if you want to call it that way.

It does not take so much effort to build a circuit that somehow behaves like a micro controller, but the practical efforts to make it a useful microcontroller are considerable.

I don't know if Op realy wants to build a useful controller, or if OP just wants to understand how it works internally.

For me it was enough to understand how it works- I don't have to produce a new controller neither I want to.

 

Of course you can. But you don't have to. It could be 5 bit, 9 bit, or 13 bit.

In reality, you dont normally have such affinity.

8bit controller only says the data bus is 8bit, and the regular ALU operations have 8bit operands (not even neccessarily 8bit results).

There is for instance something called EA or effective address- sometimes combined from the PC, and paging bits, and SFRs.

A so-called EA calculation unit. Not normally the input operands will be 8bit and neither the output.

But if you wanted to, it could be.

Make yourself free of that 8bit, 16bit consideration. It is just an agreement. We could have 9bit CPUs. It is an agreement which makes working together easier.

8bit CPU says not much if nothing. It only says "this CPU is built in a way it has an 8bit bus and mostly is dealing with 8bit data", in terms of conformity.

What if we'd have 7bit chips, 13bit chips, 5bit, and 9bit- nothing matching together properly.

So we need "classes" of 8bit, 16bit, 32bit, etc.

Internally, you are not bound to that at all.

micro controller has 8 bit instruction it means it can do 256 operations like add ,sub , and not, logic .......up to 256 . to decode 256 operations how many control input are required ?

 

This is a pretty good intro at a glance.

I figured out some day, it is just another kind of microcontroller, simpler in the making, and more difficult to program and to design.

But the internal microcontroller is exchangeable with the external one, in some kind.

If you understand one of them, you dont need to understand the other, not neccessarily in its technical terms, but if you dont, you have that chicken and egg problem.

Maybe you'd think I talk nonsense, but that way sometimes in software you implement kind of a digital ccircuit, and state machines- the same components the CPU is made of on a very low level.

If I'd be up to memorize and understand literally that document to all details, I'd get old...

 

I don't know if Op realy wants to build a useful controller, or if OP just wants to understand how it works internally.

For me it was enough to understand how it works- I don't have to produce a new controller neither I want to.

I don't want to copy another micro controller I want to know why we use only this things, we can use another I want to know the concept of every features and I know I need more time