PIC PIC16F877 -> PIC12f683

[thaking]

I want to make code of PIC16F877 working on PIC12f683. The code of PIC16F877 is working fine, but I need on PIC12f683. Can anyone help me with this:


I started with change in this code, but get several error's. I don't know why I can't use definition as in PIC16f877 #bit ..... in PIC12f683

[thaking]

Anyone? I really need fast help.

Many thanks

[temtronic]

One problem you have

#define nok_cs PIN_A3

PIN_A3 aka GP3 is an INPUT ONLY pin !! You cannot use it as the nok_cs control pin .

Page 2 of the PIC12F683 datasheet clearly shows this. You'll have to use another pin if possible, or use another PIC for your project.

[thaking]

@temtronic I correct this, but not working

I tried my code on proteus: NOT WORKING, ON SCREEN MUST BE "TEST1.....but's is not"

Any ideas?

My code is now:

[temtronic]

With almost 40 years of programming micros(25 with PICs) I've learned that NO simulator works like the REAL World.

Sorry, but I do not use Proteus (or any other simulator). They do NOT work like real parts in the real world.All are full of 'bugs'!
You don't say what errors you get from Proteus(probably none),but I suspect the simulator is NOT telling you the truth.

Since you said this code worked fine with another part( I am assuming a REAL part, NOT the simulation), it might be in the 'configuration' or setup not the 'main' program that has the error.
I suggest creating a simple 'blinking LED' and program a real chip to confirm that you have the correct fuses etc.
Once you have a real LED blinking, rebuild your Nokia main code with your known good 'setup' code.Burn a real chip and see what happens.

[thaking]

@temtronic Proteus work fine, I tested on other code, with same PIC and 3310 just other code(example), so it must be problem in C code.

Maybe in configuration of PIN's wrong in my code, I don't know, so I asked you...

Thanks

[temtronic]

Couple of issues....
You're not using 'normal' PCM files...

IE: the normal pic12f683.h file for one thing.
From that file...
// Constants used to identify pins in the above are:

#define PIN_A0 40
#define PIN_A1 41
#define PIN_A2 42
#define PIN_A3 43
#define PIN_A4 44
#define PIN_A5 45

are the defines for the pins on PortA, for the 12f683

You've got this configuration...

#bit nok_dc = 0x40.0 //PIN_A0
#bit nok_res = 0x41.1 //PIN_A1
#bit nok_cs = 0x42.2 //PIN_A3
#bit nok_sda = 0x44.4 //PIN_A4
#bit nok_sclk = 0x45.5 //PIN_A5

only 1 might be right !

I'm NOT surprised that Proteus didn't list a LOT of errors, but it appears to me that your #bit assignments are pointing to RAM locations, NOT the actual PORTA pins.

That simple LED test I talked about earlier would have shown that out very quickly.
You can of course 'relabel' them for your use

also the use of the TRIS() function is best not used, let PCM handle that.

[thaking]

[temtronic]

look at your assignments for those pins
which worked

#bit nok_sclk = portb.5 // RB5
#bit nok_sda = portb.6 // RB6
#bit nok_dc = portb.7 // RB7
#bit nok_cs = portb.0 // RB0
#bit nok_res = portb.1 // RB1

each bit assignment references one bit of portb ( RB5.5,RB5.6,etc.)

now look at what you did here

#bit nok_dc = 0x40.0 //PIN_A0
#bit nok_res = 0x41.1 //PIN_A1
#bit nok_cs = 0x42.2 //PIN_A3
#bit nok_sda = 0x44.4 //PIN_A4
#bit nok_sclk = 0x45.5 //PIN_A5

which do not work as you expect
0x40...0x45 are RAM locations,not PORTA
In the CCS manual it tells about this pin assignments..
Every PIC has a header that 'predefines' these values

your..
#define PIN_A0 nok_dc
is backwards

#define nok_dc PIN_A0
is the corrrect way

this allows PIN_A0 to be referred to as nok_dc in your program

Every project I create, I include the PICpart.h file then 'reassign' the pins with new 'names' for that project,any unused pins have names like unusedA0,unusedB3, etc.
That way it's easy to see what available pins I have for future uses.

[thaking]

@temtronic thanks I understand what I do wrong, I define just location :X

But how can I define for example PIN_A0 as bit, like in PIC16F877 code? If I define for example #define nok_dc PIN_A0 , then will be error in code, because I need bytes; nok_cs=1; ..

[temtronic]

Ok..
In the manual there's an article on how and why those numbers are used.
The COMPILER takes this information and does the 'bit assignments' automatically for you.Saves you a lot of headaches and you can rename them anytime you want.

example..
this is thePIC16F88.h file

#define PIN_A0 40
#define PIN_A1 41
#define PIN_A2 42
#define PIN_A3 43
#define PIN_A4 44
#define PIN_A5 45
#define PIN_A6 46
#define PIN_A7 47

#define PIN_B0 48
#define PIN_B1 49
#define PIN_B2 50
#define PIN_B3 51
#define PIN_B4 52
#define PIN_B5 53
#define PIN_B6 54
#define PIN_B7 55


in my program I 'redefine' as follows...

//defines for PIC16F88
#define nua7 PIN_A7
#define nua6 PIN_A6
#define nua5 PIN_A5
#define nua4 PIN_A4
#define nua3 PIN_A3
#define tsrt PIN_A2
#define tslt PIN_A1
#define nua0 PIN_A0

#define nub7 PIN_B7
#define nub6 PIN_B6
#define topc PIN_B5
#define GLED PIN_B4
#define FAN PIN_B3
#define nub2 PIN_B2
#define nub1 PIN_B1
#define nub0 PIN_B0
//defines for pinouts

As shown PIN_B3 has been given the 'name' FAN, so that any reference in the program will use it.

Ie. output_high(FAN) is the same as output_high(PORT_B3)

For me, any 'nuxx' define is an unused pin, available for future use.
The define 'GLED' refers to a Green LED, currently 'assignerd' to PIN_B4.

I tend to use short,equal length names.A habit from days when variables could only be a few bytes long.

[thaking]

@temtronic thanks for your time and help, buy you don't understand me what is my problem.

I will show now in PIC16F877 code which is work OK:

Original "configuration" of pin in working code are:

[temtronic]

Do you still have

#device PIC16F877
as your first line ?


program should look like this...

#device PIC16f877
#include<16F877.h>
#use delay(clock=4000000)
...


The .jpg was fuzzy, but I think the error is 'unrecognized identifier' which ,means the compiler has no knowledge of the 'word'.

Open up the 16f877.h file and see that the defines for the port pins are all there. Also there is a 16f877a.h version and you should use that if you're using the 16f877a chip.

[thaking]

Please look at my whole project(I have all set up, as you said; other code is the same as in original which work ok; but when I configure PIN's like you suggest CCS compiler give's me error's)

http://rapidshare.com/files/4443337/project.rar

Many thanks

[Ttelmah]

You are a little like the guy putting diesel in a petrol car, then being surprised at problems....
You need to understand what you are doing.

There are a number of fundamentally different 'ways' of addressing pins in CCS. The CCS way, is to let the compiler do it's work, use the headers that come with the compiler, and then use the input, and output instructions.
Advantages:
1) Makes it far easier to transport code between processors.
2) Allows the compiler to control TRIS for you (for 99% of code, this is easier).
3) Generally more reliable.
However, it means you _must_ use the input and output instructions. You cannot access the port as if it was a register.

The alternative is to define the ports yourself.

Now your header, says you have used the latter, _which is why the CCS defines will not work for you_.

You need to do exactly what you did on the original processor, put back the original #bit defines (just changing the one used for CS), and then _editing_ the _port, and tris_ defines only, to match the data sheet of the new chip.

Best Wishes