CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Suspect errors in PIC12LF1501.h file - how to tell?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Ttelmah



Joined: 11 Mar 2010
Posts: 19529

View user's profile Send private message

PostPosted: Sun May 22, 2016 2:18 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Sun May 22, 2016 3:21 pm     Reply with quote

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

View user's profile Send private message

PostPosted: Mon May 23, 2016 12:49 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon May 23, 2016 5:15 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon May 23, 2016 7:51 am     Reply with quote

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

View user's profile Send private message

PostPosted: Mon May 23, 2016 10:09 am     Reply with quote

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

View user's profile Send private message

Successful test program
PostPosted: Mon May 23, 2016 1:06 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
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