|
|
View previous topic :: View next topic |
Author |
Message |
dmderev
Joined: 29 Jun 2018 Posts: 2
|
|
Posted: Sat Jun 30, 2018 1:28 am |
|
|
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: 19591
|
|
Posted: Sat Jun 30, 2018 1:43 am |
|
|
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...
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: 9271 Location: Greensville,Ontario
|
|
Posted: Sat Jun 30, 2018 5:23 am |
|
|
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: 1911
|
|
Posted: Sat Jun 30, 2018 9:38 am |
|
|
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: 55 Location: Sheffield, South Yorkshire
|
|
Posted: Sat Jun 30, 2018 11:44 am |
|
|
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: 9271 Location: Greensville,Ontario
|
|
Posted: Sat Jun 30, 2018 12:04 pm |
|
|
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: 19591
|
|
Posted: Sat Jun 30, 2018 1:25 pm |
|
|
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: 1911
|
|
Posted: Sat Jun 30, 2018 2:35 pm |
|
|
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: 9271 Location: Greensville,Ontario
|
|
Posted: Sat Jun 30, 2018 2:47 pm |
|
|
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: 1911
|
|
Posted: Sat Jun 30, 2018 2:55 pm |
|
|
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: 19591
|
|
Posted: Sun Jul 01, 2018 3:58 am |
|
|
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: 1911
|
|
Posted: Sun Jul 01, 2018 10:17 am |
|
|
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: 589 Location: Des Moines, Iowa, USA
|
read_i2c problem reported in 2013 |
Posted: Thu Aug 22, 2019 12:22 pm |
|
|
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 ?
Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002. |
|
|
|
|
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
|