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 support@ccsinfo.com

The quirks and flaws of the CCS compiler
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
dmderev



Joined: 29 Jun 2018
Posts: 2

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 1:28 am     Reply with quote

Thanks for the explanation, Ttelmah. However, I started exactly from what you suggested, and I know the crystal frequency and use CCS's configuration GUI. So I thought I could see the expected result and it did not happen. I read the help file many times and looked at examples. And certainly, it was because of the wrong under-the-hood clock settings. The issue was that it was not easy to discover what compiler really did... IMHO, I think that Arduino IDE suffers from the same issue.

Searching help assumes that one knows what to look for. What I really find missing is the source code for all built-in pragmas, not only examples which all use them differently. It is compiler's hidden inner work that is frustrating - it is not clear what and how is done under the hood. Especially if the user is experienced in other C compilers and tools for higher-end processors.

On the #fuses example - "Some fuses are set by the compiler based on other compiler directives. For example, the oscillator fuses are set up by the #USE delay directive. The debug, No debug and ICSPN Fuses are set by the #DEVICE ICD=directive." So if I specify #fuses explicitly - will they be overridden by compiler? Will it depend on the order in which they are used in the text? How the compiler lists the final options chosen?
"When linking multiple compilation units be aware this directive applies to the final object file. Later files in the import list may reverse settings in previous files." - will there be a report or warning?

Probably, if the documentation focused on these issues and they could be found easily, it would be more pleasant experience...

I am not really complaining, I am sharing the experience from evaluation... Maybe after extensive use all that becomes intuitive, but 8-bit PICs are being phased out and coding for it was expected to be completed in a week from start to finish.
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 1:43 am     Reply with quote

It will depend on the order. That is why simply looking at what the .lst files gives is the easiest thing. For instance if you set the fuses explicitly, and then use a #use delay statement that changes the divisions, it is the delay ones that will be used.
The internal routines are not simple code. There are probably something like a hundred different possible code 'sets' generated by different #use rs232 syntaxes (software, hardware, buffered, RS485, etc. etc..). Just look at the list file to see the assembler generated. In symbolic mode this shows exactly what is being done.

The wizard does _rely_ on what it is being told matching the hardware, and is 'thick'. It won't warn you if a setting does something wrong. It is a dangerous tool... Sad

That the hardware is usually the problem, is exemplified by this thread:
<http://www.ccsinfo.com/forum/viewtopic.php?t=57204>

A chip being run under-voltage, and the UART being the first part to fail. The standard routines really are reliable. However the oscillator settings on the 45/2550/55, are always annoying.
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 5:23 am     Reply with quote

1st, I 'm sorry you've had a bad experience with the compiler but I've been using it since V2.4xx or so( been 20+ years,sigh over 2 DECADES !) and 'learned' C through the eyes of CCS.
some things I've picked up along the way..
NO 'wizard' is smart and all knowing. Same goes for 'simulators'. Both are made by humans who think they know what's best. Just consider the WDT fuse. For me , it is always set NOWDT. Cutting code is challenging enough but to have a WDT enabled and not know ,leads to a LOT of problems.
The PIC in your post has more fuses than instructions. When I got some 5-10 years ago, I created a separate #INCLUDE file of ALL the fuses, one per line WITH comments when I coded ythe 1Hz LED program. This allows the main program to be 'clean' visually and gives me a set of known, working fuses.
While the 4550 has internal USB, I found it better to use a $2 USB<>TTL module. Saves a lot of code space,no code to write(and debug) and modules have always worked for me.
CCS provides a LOT of examples,some go back 20+ years, and while the style of coding may have changed CCS does not hide anything.You can dump the listing and see how and where the asm is.
PICs are powerful, so you really need to read the datasheets. yes, I KNOW 400-600 pages is a lot BUT usually you can skim over 200-350 of them and concentrate on details. IE. I print off the 4550 'clock' page and highlight the clock path. By doing that I saw that a simple 4MHz xtal can be used,even for USB ! Good news as I have lots of them from my 16C84 days!!
I use MPLAB 8.92 to program a Pickit3 with old versions of the compilers( mid 4.xxx, early 5.xxx) that like the 3 or 4 PICs I use. Never ever use an ICD, simulator or wizard, I let the real World show me what's happening. The 18F46K22 is my 'goto' PIC ,while overkill for 99% of the project I do, I KNOW how it works(well, more or less). Since I'm now retired from 1/2 century of code cutting, I just 'play with PICs' and am amazed a $1 PIC does more than my first $10,000 microcomputer.
Jay
newguy



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 9:38 am     Reply with quote

I'm afraid you were rather unfairly "parachuted" into a rather impossible task: being given a week to migrate some code with an unfamiliar tool set. CCS is definitely the best product I've ever used. It definitely has its quirks and the odd bug, but overall it's fantastic.

We just hired an experienced FW developer about a month ago. He had never touched a PIC before, let alone the CCS compiler. We gave him a project I started about a year ago but never had time to complete. He just got it done yesterday. The project was a proof of concept to a) reduce part count of an existing product, and b) see if we could also reduce the current draw. It's a battery operated device with ~13uA draw which translates to about a 10-12 year lifetime with the original battery. He managed to get a 10.3uA current draw. And he had never really delved into the world of ultra low power before.

He loves the compiler and he loves the Microchip line now. Then again, he had me to help him avoid the pitfalls.
diode_blade



Joined: 18 Aug 2014
Posts: 52
Location: Sheffield, South Yorkshire

View user's profile Send private message Send e-mail

PostPosted: Sat Jun 30, 2018 11:44 am     Reply with quote

I'll chuck in my 2 penneth for what its worth, I love this compiler yes it has flaws but don't all compilers. I am doing a project at the moment which MPLAB ver 8.9** the last ver does not support.
I am using MPLABX the latest ver and the latest ver of this compiler.
Following other users advice on here I have the latest version plus 3 others 1 going back to a ver 4. All installed in their own directories.
MplabX can be right pain in the butt but I have my basic code working and am using an ICD3 in debug mode to check everything.
I posted on here the other week about the SPI setup after I had read through previous posts and thanks to Temtronic and his simple suggestion to see if I was using hardware SPI I halted the program and read the SFR registers for MSSP module I was using and it was using the hardware spi.
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 12:04 pm     Reply with quote

this...
but 8-bit PICs are being phased out and coding for it was expected to be completed in a week from start to finish.

...concerns me but I assume you mean the 8 bit PICs where you work? If so, why? Sounds like a TOTAL redesign of a product.There are a LOT of 8 bit PICs that might work, though you'd need to do a deep analysis of what IS required, then look at 100s of PICs.
'completed in a week'? Yeah, right. It ain't never going to happen. Even I abandoned the 4550 years ago(wh chose it ?) in favour for the 46k22 +USB<>TTL module. better PIC ,cheaper, more powerful, etc. The 4550's built in USB is a PAIN to deal with on every level. If your boss said it could be done in a week, I'd ask him to SHOW me HOW as HE has already determined it 'can be done'.
There are 1,000s of PICs so choosing one as the 'best for the job' can easily take 2-3 weeks alone. It's the 'details' like the client (or boss) decides AFTER you've got the 'proof of concept' running that ...' just stick 2 more LEDs and a 4x4 kpd instead of the 3x4 one we've always had'. Most bosses or higher ups haven't a clue about true costing, they just want the product out the door, least the ones I've had. They'll scream about the PIC costing 50 cents more but fail to understand you've saved $100s by slashing R&D time from months to days. Same trick goes for battery operated devices. Buy a bigger battery and NOT have to spend 2 weeks 'tweaking' every bit of code and parts values to reduce current consumption(only to find out the PIC doesn't wakeup quite as expected,sigh)
Over the years(decades in fact) ,I've tried the 'other' compilers and always came back to CCS. Once you focus on it, stuff comes fairly easy as a LOT of the code is done 'behind the scenes' YET you can look at it anytime you want.Most of the functions that CCS has created are optimized though one programmers idea may be speed ,the other size, neither is really important these days when PICs race along at 64MHz(or more) with 64KW of code space.
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 1:25 pm     Reply with quote

The amazing thing is just how long lived the '8bit PIC' actually is.
You can even still buy PIC16C84's, which were superceded by the 16F84 in 1995!. This chip came out in 1992 (some people say 1993, but was using it in 92). Redesigning a board because you think "8-bit PICs are being phased out", is currently pointless.
newguy



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 2:35 pm     Reply with quote

Just last week I discovered that I'm going to have to migrate a project where an 8 bit processor is "just fine" to a 16 bit simply because the combination of peripherals we require just isn't available in a single 8 bit incarnation: direct LCD drive and capsense (or mtouch) capacitive button sensing. Oh, ultra low power too. Couldn't find any 8 bit PIC that had both LCD and capacitive sensing. But I did find a 24-series family that does. Feel kind of "dirty" for having to specify something so obviously overkill, but it's the only option Microchip offers, so....
temtronic



Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 2:47 pm     Reply with quote

re: newguy PIC choice
Depending on the qty you need , maybe contact Microchip. They have 1,000s of PICs where the combination of internals leads me to believe they were 'custom' PICs then offered to the general market.
Perhaps an I2C cap sensor chip( 50c/qty) will work? Migration can have a huge R&D cost unless you KNOW the new PIC.
Had to lookup the 16C84...yessh $5 ! 18F46K22 about 1/2 that !!
Jay
newguy



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Sat Jun 30, 2018 2:55 pm     Reply with quote

Good ideas - I'll have to reach out to Microchip. No matter how "big" my production runs get, I don't consider myself big enough to warrant a custom processor but I guess it doesn't hurt to ask!
Ttelmah



Joined: 11 Mar 2010
Posts: 19215

View user's profile Send private message

PostPosted: Sun Jul 01, 2018 3:58 am     Reply with quote

Or (of course), just use two PICs...
You don't say how many capacitor sense lines you need?. There are 8pin PICs that offer this feature. Single line serial to the master chip?.
Also remember that cap touch sensing can be done lots of ways without chips having the specific peripheral. If you have a comparator with an SR latch, you can use the capacitance to generate a relaxation oscillator, and time this with a counter (en542979.pdf). Or you can use a normal ADC using CVD sensing (01298A.pdf). <http://www.ccsinfo.com/forum/viewtopic.php?t=49242&highlight=cvd>

Best Wishes
newguy



Joined: 24 Jun 2004
Posts: 1900

View user's profile Send private message

PostPosted: Sun Jul 01, 2018 10:17 am     Reply with quote

You know, when I searched for an 8 bit PIC that can do touch sense and drive an LCD I didn't think to tick the "ADC with computation" box. PIC16F19197 looks like it fits the bill. Thanks!
allenhuffman



Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA

View user's profile Send private message Visit poster's website

read_i2c problem reported in 2013
PostPosted: Thu Aug 22, 2019 12:22 pm     Reply with quote

DireSpume wrote:

15. As with many of the built-in CCS functions, the details of what they do aren’t clearly explained in the manual. Calling read_i2c() will release the clock. If you aren’t immediately exiting the ISR, then you must not call this function or the master could send another byte while you’re still in the ISR. Read the data register directly, then call read_i2c() just before exiting the ISR (this is how to do clock stretching). Also, the documentation for read_i2c() says that it acknowledges by default; however, it seems that the opposite is true – always specifically specify the ack argument in read_i2c().


Does anyone know if this is still a concern?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?
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