|
|
View previous topic :: View next topic |
Author |
Message |
small_chick
Joined: 17 Jul 2012 Posts: 53
|
I2C problems ??? |
Posted: Fri Jul 20, 2012 8:17 am |
|
|
I have some questions about I2C, I hope you can help me! However, the content seems fairly long to display here, so I put all in pdf, you can download it here ! sorry for this inconvenience !!!
http://www.mediafire.com/view/?8jjm57b68ao3tkm |
|
|
Rohit de Sa
Joined: 09 Nov 2007 Posts: 282 Location: India
|
|
Posted: Fri Jul 20, 2012 11:50 am |
|
|
You really could have made this much easier for others. There was absolutely no need to use a PDF. That's probably why you've not yet got answers. Your questions should simply have been:
Quote: | -I don’t know what do “hardware I2C functions”, “the hardware-based I2C” and “a software-based master I2C device” are ?
-In the purpose part, it states that “ To access the correct function use the stream identifier”, could you give me an example ? | ....and give the reference as the CCS-C manual.
Anyway, both these questions have already been asked and answered in some similar form on the forum. Do a search for more details. In short - "hardware" functions rely on the PIC's built-in dedicated hardware to perform a certain function. Having built-in registers, comparators, timers, data slicers, etc to fully perform a certain operation is a huge advantage - it leaves the PIC free to do other things.
For example, most new PICs have a hardware UART. This means that data that needs to be transmitted simply needs to be put into a memory-mapped register in the PIC. The UART hardware takes care of timing, raising the UART Tx pin high or pulling it low, etc.
To save on cost, some of the earlier PICs (and even some of the really low pin count devices) don't have a hardware UART. This does not mean you can't interface to other serial devices. You could write software to pull the pin high or low, and take care of the timing using delays or a timer. Of course this is pretty painful and complicated. CCS has software libraries which do this painful task for you.
CCS also allows you to 'create' multiple UARTs (or I2C 'pipelines' - sorry, can't think of a better term). A 'stream' is simply a unique 'name' for that particular 'pipeline'.
eg: I can create two I2C streams:
Code: | #use I2C(master, sda=PIN_B0, scl=PIN_B1,stream=channel1)
#use I2C(master, sda=PIN_D2, scl=PIN_c2,stream=channel2)
|
and then later in code:
Code: | i2c_write (channel1, 0x23);
i2c_write (channel2, 0x11); | The device writes 0x23 to the device connected to B0, B1, and then writes 0x11 to the device connected to D2, C2 |
|
|
small_chick
Joined: 17 Jul 2012 Posts: 53
|
|
Posted: Fri Jul 20, 2012 7:37 pm |
|
|
I suppose that "hardware functions" means what PIC really does without being programmed ! Is it what you mean, Rohit de Sa ? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9218 Location: Greensville,Ontario
|
|
Posted: Fri Jul 20, 2012 8:20 pm |
|
|
'hardware functions' refers to a 'module' that the PIC may have , built internally. UART,eeprom,timers,PWM,ADC,DAC,etc.
In the beginning, microcomputers consisted of the ALU and a few I/O pins.Everything(UARTS,adc,ram,eeprom,etc) were external 'devices' or 'modules' that were added to the computer to do certain tasks.
Over the past 40 years, many of these external 'modules' have been built into the main computer 'core'.
One example is the UART.
It takes a fair amount of code to allow a PIC or other computer to act as a UART (serial communications) ,having a builtin 'hardware' UART greatly simplifies the coding(programming) process however hardware modules have limitations.One is that generally speaking hardware 'functions' are physically 'tied' to 'specific' I/O pins.
A 'software' based UART is also referred to as 'bit-banging',where the programmer cuts code on a bit by bit level to do the UART functions.Since you , the programmer is in total control, you can assign the 'software UART' to any I/O pin.
One of the key benefits of using 'software' based functions or modules is that you can have, say, several UARTs, I2C busses,or One Wire busses depending on the project's requirements.
Obviously there are 'pros and cons' to using either of these techniques,entire books can (and have) been written about this subject and goes beyond the scope of this forum.As a general 'rule', projects always will need more pins,functions and memory so it's better to buy say 40 pin devices even though a 28 pin PIC should do.
hth
jay |
|
|
small_chick
Joined: 17 Jul 2012 Posts: 53
|
|
Posted: Fri Jul 20, 2012 9:33 pm |
|
|
Thanks for your explanation, temtronic !!! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19482
|
|
Posted: Sat Jul 21, 2012 1:07 am |
|
|
And from your other thread, # commands, are _preprocessor_ directives, not lines of C code.
Read any C book, and you will see such commands being used, and they _do not_ have the trailing ';' needed by a line of C. Hence the compiler complains when you include this....
Best Wishes |
|
|
small_chick
Joined: 17 Jul 2012 Posts: 53
|
|
Posted: Sat Jul 21, 2012 8:11 am |
|
|
I have a problem as follow:
I use i2c functions but the header file of PIC doesn't define anything related to i2c. Therefore, when i use this direction "#use i2c(master);", there's an error:
Error 104 "main.c" Line 4(5,18): Extra characters on preprocessor command line ";"
//***********************
how can i use i2c functions recommended by CCS ? please help me! thanks!
I use PIC16F887.
And one more question is that:
is it always necessary to have a header file with the same name as the .c file, for example lcd.h & lcd.c ,... ?
If I have already defined all functions and variables in .c file, do i need to create a header file corresponding to the .c file ?
And how can I create a header file and a .c file ? is it able to do this with notepad ?
I'm looking forward to receiving your replies ! thanks ! |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1343
|
|
Posted: Sat Jul 21, 2012 9:07 am |
|
|
If you read Ttelmah's post right above yours and if you read the error itself, it will tell you what is wrong with that call (though you should be using some other options as well, but that is not a compiler error).
For your second question, file names can be whatever you want. Most find it useful to name the .c and the .h the same for organizational purposes, but you don't have to name them the same. |
|
|
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Sat Jul 21, 2012 9:12 am |
|
|
If you read Ttelmah's post just above yours, he explains your error message about the pre-processor directive.
The .h files are usually used to define constants and other things that are used in the .c program - they are usually the same name as the "c" file simply to make it clear what they are for, HOWEVER, every C file does not need a .h file and often you will see includes for .h files that do not have an associated .c file (io.h, system.h, lcd.h pic16f14k22 etc). Get yourself a decent C book and look through it many things will be explained.
mikey _________________ mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|