My pic has a 10 bit convertor, but when I use the ReadAD(AN0) I only get values between 0-255 (e.g. 8 bits). Shouldn't I get more resolution than this?
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ReadAD returns 8 bit values because this is the size of a standard variable in GCBASIC. To get all 10 bits, please add this function to your program (or to GCBASIC\include\a-d.h)
word function ReadAD10(ADReadPort)
SET ADCON1.ADFM ON
Temp = ReadAD(ADReadPort)
movf ADRESL, W
movwf ReadAD10
ReadAD10_H = ADRESH
SET ADCON1.ADFM OFF
end function
You can now get the full 10 bit value using ReadAD10(AN0) instead of ReadAD(AN0).
How do you plan on using the value? Some commands might need to be altered in your program to handle the word variable returned by ReadAD10 (if and do will work fine, but other things such as variable setting commands might require some small changes).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm just learning PIC programming, so I was experimenting with a temperature sensor that I had. I thought a next step might be to log the values to an external eprom. Maybe the easiest way to do this would be to encode the value as BCD before I store it in the eprom.
The function is interesting, there is no return value that has to be defined? It's just the name of the fuction?
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All that is needed is the name of the function. However if you are going to use the same reading several times, it is best to use a return value like this:
'This line goes near the top of the program:
Dim SensorReading As Word
'This line goes where you need the reading:
SensorReading = ReadAD10(AN0)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed a lot of threads where there are code additions to the gcbasic install, like this recommended mod to a-d.h or another one I just read with defines that had to be added to rs232.h. It might be handy to users if there were some note made on whether the particular recommendation was going to be part of gcbasic at some time or not, and when.
I can see where folks keep hand crafting changes on their machine and having to merge a longer and longer list of things they added to make theirs work, based on recommendations here, every time they update. Quite a mess. I even found an update directory from a link here, but don't remember seeing it on Sourceforge - so there seems to be multiple release paths.
For instance, if this recommendation is good, and worthy of inclusion as it sounds like here, and the post is dated 1-21-07, a way to know if an update zip on 1-29-07 has it included would be nice. For one change, not a big deal, but after several are in queue, it gets messy for a user.
I suggest a sentence on a coded post like this to say whether it will be added to the next release, never added (use it only if you need it), or whatever. Maybe schedule an update every week or 2 weeks or whatever seems right, so everyone knows to look then. It may be a big update, or just a little one, but we would know that something like this would be already added next release. It may be, like my case, that I don't need this today, but will, and I would rather not diverge my base files from the releases if I don't have to, and I can't remember every little change mentioned to go back to when I do start using some function.
I also saw where some defines had been dropped unintentionally. Maybe send the release first to someone with an unmodified install and do a diff to verify the changes before releasing. That way if there's a question (like "why did you drop function X?") it can be corrected ahead of release.
Just my observations from poking around and trying to keep up FWIW... ;) It might also speed up inclusion of functions and such from users into the core files - you could just post that it's going to be included next update or not after they post and you capture the best of what comes in.
-Skip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to read a temp sensor (LM35) which is 10bit, so I included the above function, but I read nothing with the function, and I get something with the normal ReadAD() command. Any thoughts?
word function ReadAD10(ADReadPort)
SET ADCON1.ADFM ON
Temp = ReadAD(ADReadPort)
movf ADRESL, W
movwf ReadAD10
ReadAD10_H = ADRESH
SET ADCON1.ADFM OFF
end function
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have literally just added a proper ReadAD10 function to a-d.h. The new file is at http://gcbasic.sourceforge.net/newfiles/a-d.h . Make sure that you delete the ReadAD10 function from your code or else GCBASIC will use it and not the one in a-d.h.
So far it's only been tested on a 16F872 - I'm about to get out the 16F88, 16F877A and 18F4550 for more testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is interesting is that If I hook a 10K POT up to the input, I get results from 0-771. If I disconnect the ground from the thermistor (LM35), I also get 771.
-Sterling
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My pic has a 10 bit convertor, but when I use the ReadAD(AN0) I only get values between 0-255 (e.g. 8 bits). Shouldn't I get more resolution than this?
Steve
ReadAD returns 8 bit values because this is the size of a standard variable in GCBASIC. To get all 10 bits, please add this function to your program (or to GCBASIC\include\a-d.h)
word function ReadAD10(ADReadPort)
SET ADCON1.ADFM ON
Temp = ReadAD(ADReadPort)
movf ADRESL, W
movwf ReadAD10
ReadAD10_H = ADRESH
SET ADCON1.ADFM OFF
end function
You can now get the full 10 bit value using ReadAD10(AN0) instead of ReadAD(AN0).
How do you plan on using the value? Some commands might need to be altered in your program to handle the word variable returned by ReadAD10 (if and do will work fine, but other things such as variable setting commands might require some small changes).
I'm just learning PIC programming, so I was experimenting with a temperature sensor that I had. I thought a next step might be to log the values to an external eprom. Maybe the easiest way to do this would be to encode the value as BCD before I store it in the eprom.
The function is interesting, there is no return value that has to be defined? It's just the name of the fuction?
Steve
All that is needed is the name of the function. However if you are going to use the same reading several times, it is best to use a return value like this:
'This line goes near the top of the program:
Dim SensorReading As Word
'This line goes where you need the reading:
SensorReading = ReadAD10(AN0)
I've noticed a lot of threads where there are code additions to the gcbasic install, like this recommended mod to a-d.h or another one I just read with defines that had to be added to rs232.h. It might be handy to users if there were some note made on whether the particular recommendation was going to be part of gcbasic at some time or not, and when.
I can see where folks keep hand crafting changes on their machine and having to merge a longer and longer list of things they added to make theirs work, based on recommendations here, every time they update. Quite a mess. I even found an update directory from a link here, but don't remember seeing it on Sourceforge - so there seems to be multiple release paths.
For instance, if this recommendation is good, and worthy of inclusion as it sounds like here, and the post is dated 1-21-07, a way to know if an update zip on 1-29-07 has it included would be nice. For one change, not a big deal, but after several are in queue, it gets messy for a user.
I suggest a sentence on a coded post like this to say whether it will be added to the next release, never added (use it only if you need it), or whatever. Maybe schedule an update every week or 2 weeks or whatever seems right, so everyone knows to look then. It may be a big update, or just a little one, but we would know that something like this would be already added next release. It may be, like my case, that I don't need this today, but will, and I would rather not diverge my base files from the releases if I don't have to, and I can't remember every little change mentioned to go back to when I do start using some function.
I also saw where some defines had been dropped unintentionally. Maybe send the release first to someone with an unmodified install and do a diff to verify the changes before releasing. That way if there's a question (like "why did you drop function X?") it can be corrected ahead of release.
Just my observations from poking around and trying to keep up FWIW... ;) It might also speed up inclusion of functions and such from users into the core files - you could just post that it's going to be included next update or not after they post and you capture the best of what comes in.
-Skip
I'm trying to read a temp sensor (LM35) which is 10bit, so I included the above function, but I read nothing with the function, and I get something with the normal ReadAD() command. Any thoughts?
Here is the program:
#chip 16F684, 20
'#config _CP_OFF & _WDT_OFF & _PWRTE_ON & _HS_OSC
#mem 128
DIM potSensor as WORD
#define LCD_IO 4
#define LCD_DB4 PORTC.0
#define LCD_DB5 PORTC.1
#define LCD_DB6 PORTC.2
#define LCD_DB7 PORTC.3
#define LCD_RS PORTC.4
#define LCD_RW PORTA.0
#define LCD_Enable PORTC.5
ADoff
Main:
'initLCD
DIR PORTA.1 IN
wait 1 sec
Print "HELLO WORLD??"
Locate 1,0
potSensor = ReadAD10(AN1)
LCDWord (potSensor)
wait 50 10ms
cls
Goto Main
word function ReadAD10(ADReadPort)
SET ADCON1.ADFM ON
Temp = ReadAD(ADReadPort)
movf ADRESL, W
movwf ReadAD10
ReadAD10_H = ADRESH
SET ADCON1.ADFM OFF
end function
I have literally just added a proper ReadAD10 function to a-d.h. The new file is at http://gcbasic.sourceforge.net/newfiles/a-d.h . Make sure that you delete the ReadAD10 function from your code or else GCBASIC will use it and not the one in a-d.h.
So far it's only been tested on a 16F872 - I'm about to get out the 16F88, 16F877A and 18F4550 for more testing.
With the 16F684, I don't think it worked. The new function returned "0" whereas the 8bit function would return somewhere between 10-18.
-Sterling
What is interesting is that If I hook a 10K POT up to the input, I get results from 0-771. If I disconnect the ground from the thermistor (LM35), I also get 771.
-Sterling
okay, I thought I had the latest a-d.h file installed, but I guess not, or there was another update. Anyway, I think everything is working.
-Sterling