View previous topic :: View next topic |
Author |
Message |
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
Need 16F1789.h |
Posted: Sun May 19, 2013 3:11 pm |
|
|
I've the latest version of compiler, but 16F1789 device not supported.
The 16F1783 is similar, but lacking functions of the 16F1789.
Any ideas on how to reliably modify the 16F1783.h or does
anyone have the desired include file already drafted ?
Thanks! |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Sun May 19, 2013 3:23 pm |
|
|
what compiler version do you have ??
BTW =
where did you buy yours ??
i only have two pieces in DIP from the early release Microchip sampling program and i don't think ccs supports it yet
the best answer is to wait till CCS updates to include it. |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
reply to ASMBOY |
Posted: Sun May 19, 2013 3:39 pm |
|
|
I've latest rev of everything, purchased from CCS.
The chips can be bought at Digikey for under $2.
My previous message stated that I KNOW CCS has not provided support yet, but the only thing needed is the .h file ... simple text file that defines register addresses and values.
I could bust open the 16F1783.h and make edits so it would support the 16F1789 (then save it as 16F1789.h), but then I need to check the spec for all the register addresses and values and that seems a bit tedious at the moment while I'm looking to get through this particular project quickly. |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Sun May 19, 2013 3:48 pm |
|
|
the main problems in "faking it" will be memory paging shortcomings.
( it is a 16F part after all)
BUT the header file is NOT the only issue
as there are core support problems
in the ccs control database to overcome as as well.
and lastly spoofing your programming fixture to ignore the wrong device
type ID read back code.;
you may find yourself putting in much effort that will not pay off.
which supported part were you planning to spoof ?? |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
|
Posted: Sun May 19, 2013 4:19 pm |
|
|
your questions are answered in previous posts.
My goal is to find a reliable solution. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Sun May 19, 2013 5:47 pm |
|
|
Since there are hunderds of PICs to choose from , what is 'special' about the 16F1789?
In the past, I found it easier to stick with a more powerful PIC,truly overkill for most applications, than to waste time($$$) on a smaller,cheaper PIC.
Frankly anything less than 40 pins, is NOT cost effective in the long run.While the price of the PIC is a couples bucks more,that's nothing compared to R&D labour,PCB design,debugging,etc.
Case in point, I'm using an 18F46K22 for a client's project.1000 piece run.Smaller PIC will 'save' $2000.However,I save $5000 alone by 'reusing' a previous 46K22PCB(with minor tweaks), save a week of 'code issues',again a few grand, and time for the complete project is 5 weeks ahead of client's schedule so everyone wins.
hth
jay |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun May 19, 2013 5:54 pm |
|
|
Quote: | I've the latest version of compiler, but 16F1789 device not supported.
The 16F1783 is similar, but lacking functions of the 16F1789.
Any ideas on how to reliably modify the 16F1783.h or does
anyone have the desired include file already drafted ?
|
The .h file has constants that are used as parameters for the built-in
functions. The built-in functions are in the compiler's .DLL files. To add
support for new features in the 16F1789, CCS would have to write the
code for the new functions, test it, and put it into the .DLL file(s) that are
included with the compiler. In addition to that, CCS would have to
put in a new entry into the devices4.dat file, which is a database of
features and specs for each PIC. Just having a 16F1789.h file won't
won't be enough.
Quote: |
but the only thing needed is the .h file ... simple text file that defines
register addresses and values. |
The 16F1789.h file, if it existed, would not contain register addresses
and values. It contains constants for the built-in functions. In your
statement above, are you possibly referring to a "def_16F1789.h" file ?
If the CCS PCWH IDE had support for the 16F1789, then you could
press a button on one of the windows, I think it's the device editor,
and you could generate a file with register addresses that allow you
to directly access each SFR register. Is this what you are talking about ?
You can't get that ability until CCS adds support for the 16F1789.
Quote: | The 16F1783 is similar, but lacking functions of the 16F1789. |
What peripherals in the 16F1789 would you like to have a built-in
function for ? Can you post a list ? |
|
|
avatarengineer
Joined: 13 May 2013 Posts: 51 Location: Arizona
|
Choices |
Posted: Mon May 20, 2013 1:31 pm |
|
|
Despite no desire to justify my choices,
the 16F1789 has certain salient attributes;
1) low part cost (< $2)
2) 12 ADC (most important)
3) can clock at 32MHz (versus 8 or 16 for other 16F parts )
I would use the supported 16F1783, but it is shy a few pins I need.
The 4x Flash ROM of the 16F1789 is nice, but not likely needed.
So all in all, not much functional difference other than an extra CCP. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon May 20, 2013 3:48 pm |
|
|
If you have the full CCS IDE program (PCWH or PCWHD) you could try
using the Device Editor to add the 16F1789. This post has instructions:
http://www.ccsinfo.com/forum/viewtopic.php?t=29362
You could use the 16F1783 as a base, and then copy it, as suggested
in the instructions.
Those instructions are for CCS vs. 3.249. The Device Editor probably
changed in appearance since then. Here is a more modern screenshot
of it. I don't know if it reflects the current compiler version, because
I don't have the full IDE:
http://www.ccsinfo.com/images/content/device_editor.gif |
|
|
asmboy
Joined: 20 Nov 2007 Posts: 2128 Location: albany ny
|
|
Posted: Mon May 20, 2013 3:56 pm |
|
|
sounds like the 18F4523 that i have used in several successful instrument designs with "great joy" as my Buddhist master would say
best of all - is very well supported and has very reliable code accuracy support - right now -- from CCS --
yes more $$ -
- but in my practice, the 16F parts are no special bargain unless
cost alone is the driver of your project.
i feel lucky in that performance is what i get paid to deliver
- and a few $$ more for a rock solid product is more in demand than cheap.
and tho i have only tested it - not deployed it yet
the 18F46K80 at abt $2.50 , 64mhz, 64kb, 4k eeprom- for most applications CRUSHES the 16F part you seem destined to "hurt yourself" with .
to the pioneers go the arrows , sez i
my vote goes with jay on this one .. |
|
|
|