|
|
View previous topic :: View next topic |
Author |
Message |
Ttelmah
Joined: 11 Mar 2010 Posts: 19529
|
|
Posted: Sun May 22, 2016 2:18 pm |
|
|
Quote: |
To Ttelmah:
WPUEN is not defined. Is there a graceful way to set bits in the OPTION register?
|
I assumed you had read my post where I show how to generate this.......
Sixth post in the thread. |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Sun May 22, 2016 3:21 pm |
|
|
Ttelmah: I saw your
#bit WPUEN=getenv("BIT:WPUEN")
but that left me puzzled. I see that it works but I don't know why. Where does getenv() get its information from? Since I am already doubting the accuracy of the PIC12LF1501.h file I want to know what the source of the info is.
Then I saw in the CCS manual Q&A that I can declare bits in registers like this
#BIT WPUEN = 0x095.7 // Weak pull up !enable
which may be less portable but makes more sense to me. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19529
|
|
Posted: Mon May 23, 2016 12:49 am |
|
|
The device database.
If this is flawed, nothing is going to work (it does happen, but then the only real solution is to talk to CCS). Generally this is the 'core' of every chip. You can write a .h file for a chip, but this won't work without the device database. It can be edited if you have the IDE, and even new chips added, but to do it 'from scratch', would take several days of work, even for a basic chip, and weeks of work for a complex one (I do mean this - think just how many registers and bits there are in a DSPIC). Fortunately, 99% of entries can be based on other earlier chips.
Where does it come from?. CCS generate the entries for each new chip from the data sheet, and using previous chips. That's why sometimes there are faults, when very new features appear.
'getenv', is in fact the way to read this, and also can allow you to find errors. So (for instance) if you think that the compiler is writing to the wrong register inside it's code, a 'getenv' on that register name, allows you to see what register the compiler thinks this is. It is therefore better always to use the compilers 'knowledge' here, since this allows you to always be sure that the database is right.
However I don't think you have any problems like this (except for the missing DACOUT2 entry in the .h file). The pullups are not strong enough to give what you are seeing. The first thing to turn off is the comparator. If it's output was driving the pin, everything would be explained, and a lot of the comparators _do_ default to being enabled.
General rule is if a pin is not doing what you expect, start by ensuring _everything else on the pin is turned off_....
In fact, looking back, you are making a %^&* of it yourself. You are setting the DACOUT2 pin as a digital output, with your fixed_io statement. You do not want it programmed as a digital output, it is being used as an analog output...... |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1351
|
|
Posted: Mon May 23, 2016 5:15 am |
|
|
SherpaDoug wrote: | Ttelmah: I saw your
#bit WPUEN=getenv("BIT:WPUEN")
but that left me puzzled. I see that it works but I don't know why. Where does getenv() get its information from? Since I am already doubting the accuracy of the PIC12LF1501.h file I want to know what the source of the info is.
Then I saw in the CCS manual Q&A that I can declare bits in registers like this
#BIT WPUEN = 0x095.7 // Weak pull up !enable
which may be less portable but makes more sense to me. |
As a note, you can always verify the WPUEN is set correctly by looking at the .SYM file (not the .ESYM). It will tell you what address is being used by every variable (and every function as well). |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Mon May 23, 2016 7:51 am |
|
|
Thanks Ttelmah, that makes things much clearer. Is this device database and getenv behavior documented anywhere in the manual or is it just tribal knowledge?
I frequently examine the .sym and .lst files to see how the compiler is interpreting my C code when something is not working. I started programming PICs in assembly before I bought the CCS version 2 compiler (1990's). But as I mentiond I have been away from PICs for a few years. I basically skipped CCS version 4. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19529
|
|
Posted: Mon May 23, 2016 10:09 am |
|
|
getenv, is documented in the manual. However the names you can use are basically from the data sheet. If you have the IDE, the device editor, then select 'registers', displays all the register names and bit names available. |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
Successful test program |
Posted: Mon May 23, 2016 1:06 pm |
|
|
For anyone in the future with similar issues here is my finished test program that exercises Software Serial, DAC and Timer1 on the PIC12LF1501:
Code: | //Simple-counter-3 main.c
#include <main.h>
int16 count;
int DACnum, DACloop;
void main()
{
setup_timer_1(T1_EXTERNAL|T1_DIV_BY_1);
setup_dac(0x80|0x10|0x00); //DAC enable | DACOUT2 | VDD-VSS
DACnum = 0;
while(TRUE)
{
dac_write(DACnum);
for(DACloop = 25; DACloop > 0; DACloop--)
{
output_high(ProxPwr);
delay_ms(1);
set_timer1(0);
delay_ms(10);
count = get_timer1();
output_low(ProxPwr);
printf("count => %Lu DAC => %u\n\r", count, DACnum);
delay_ms(15);
}
DACnum++;
}
} |
Code: | //simple-counter-3 main.h
#include <12LF1501.h>
#use delay(internal=16MHz)
#use FIXED_IO( A_outputs=PIN_A4,PIN_A0)
#define TX PIN_A0
#define Bias PIN_A2
#define ProxPwr PIN_A4
#define ProxE PIN_A5
#use rs232(baud=38400,parity=N,xmit=TX,bits=8,stream=PORT1,errors)
|
It prints out the Timer1 count vs DAC bias voltage applied to a gated oscillator.
Many thanks to all those who replied. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
|
|
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
|