View previous topic :: View next topic |
Author |
Message |
Arakel
Joined: 06 Aug 2016 Posts: 107 Location: Moscow
|
CCS plus assembly |
Posted: Thu Mar 16, 2017 12:42 am |
|
|
Good day! I have a question that I am trying to figure out. Is there any way to include Assembler code in CCS? Sometimes the functions of CCS are not very efficient and they cause problems do to bugs, the best way that I can think of to overcome this, and it probably always works is to add an Assembler instruction in the code. _________________ Yo! I love learning and technology! I just do not have experience so do not be angry if I ask a stupid question about a detail! From so much to remember sometimes I forget the details in order to remember the big problems! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Thu Mar 16, 2017 12:49 am |
|
|
Look at ex_glint.c
ex_fir.c (PCD)
ex_macro.c
Each shows a small piece of assembler being included in the CCS code.
99% of such functions can be coded without using assembler. #byte and #word to talk directly to SFR's etc..
The CCS assembler allows C variables to be accessed by name in the assembler. The command list is in the manual. |
|
![](templates/subSilver/images/spacer.gif) |
Arakel
Joined: 06 Aug 2016 Posts: 107 Location: Moscow
|
|
Posted: Thu Mar 16, 2017 1:02 am |
|
|
Thank you! You deserve a beer! _________________ Yo! I love learning and technology! I just do not have experience so do not be angry if I ask a stupid question about a detail! From so much to remember sometimes I forget the details in order to remember the big problems! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Thu Mar 16, 2017 5:47 am |
|
|
While Mr T's comment about coding functions in C vs Assembler is true, you may be able to 'refine' a C function. Some programmers code for speed, others for compact code, others don't seem to do care and create 'bloatware'.
When you cut code in Assembler you have a better understanding of what's happening 'inside the PIC'. Microchip has several 'Tips and Tricks' books, where simply resequencing the code or thinking 'upside down' can save bytes or microseconds.
In the good old days of 2Mhz clocks it was important, not so much now with 64Mhz speeds, however if you want clean,tight code, it's worth investigating HOW code works.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Arakel
Joined: 06 Aug 2016 Posts: 107 Location: Moscow
|
|
Posted: Thu Mar 16, 2017 5:58 am |
|
|
This is useful also, and I like Microchip, the direction in which they work should continue and not stop! They are doing things right! But I just dont have the time at the moment to read a 600 page datasheet or 6000 page book. Plus I have to read Kernighan and Ritchie, and I should some day. _________________ Yo! I love learning and technology! I just do not have experience so do not be angry if I ask a stupid question about a detail! From so much to remember sometimes I forget the details in order to remember the big problems! |
|
![](templates/subSilver/images/spacer.gif) |
jeremiah
Joined: 20 Jul 2010 Posts: 1329
|
|
Posted: Thu Mar 16, 2017 6:21 am |
|
|
Arakel wrote: | But I just dont have the time at the moment to read a 600 page datasheet |
I understand the sentiment here, but please consider:
If you want to be programming microcontrollers, then you simply have to make the time to read the 600 page data sheets. Eventually you will get to the point where you no longer need to read the whole thing and your instincts will help you skim through new ones quickly. Before you get to that point though, you need to get a better understanding of how everything works and all the available options. Otherwise you going to run into problems. There are no shortcuts to real learning. |
|
![](templates/subSilver/images/spacer.gif) |
Arakel
Joined: 06 Aug 2016 Posts: 107 Location: Moscow
|
|
Posted: Thu Mar 16, 2017 7:13 am |
|
|
I understand that, this is the very reason why I first must read what I have now and then continue forward. _________________ Yo! I love learning and technology! I just do not have experience so do not be angry if I ask a stupid question about a detail! From so much to remember sometimes I forget the details in order to remember the big problems! |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Thu Mar 16, 2017 7:45 am |
|
|
The only thing that I've done which has required the use of assembly is getting a PIC to boot from its internal oscillator and then doing an immediate switchover to an external crystal. The necessary registers are locked and can only be accessed once a special time sensitive unlock sequence is generated, and that's what I used assembly for. For everything else - plain old C suffices, especially given that you can directly access special function registers very easily.
Just remember that C is portable; assembly isn't. Just the other day I actually had someone ask my opinion about keeping all their specialized IP, created over the past 2 decades, which is entirely written in assembly. ...For an obsolete family of processors. I don't think they particularly liked my answer, but to me there's really only one alternative: start fresh in C. At least with C you have a relatively easy migration path in future. With assembly, if you change processor families or change manufacturers, all your IP is quite useless. |
|
![](templates/subSilver/images/spacer.gif) |
Arakel
Joined: 06 Aug 2016 Posts: 107 Location: Moscow
|
|
Posted: Thu Mar 16, 2017 7:51 am |
|
|
They still use assembly, especially for mainframes, I dont think that they change the manufacturer, but especially It might have been for the mainframes used the by US emigration service, they use assembly. _________________ Yo! I love learning and technology! I just do not have experience so do not be angry if I ask a stupid question about a detail! From so much to remember sometimes I forget the details in order to remember the big problems! |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9177 Location: Greensville,Ontario
|
|
Posted: Thu Mar 16, 2017 7:53 am |
|
|
just a note... not all C is the same ! We've all seen C code presented here, from another compiler, that will not work as written in CCS C. There's always tweeks to be done.
Every high level language has 'variations' though the closest to 'universal' or machine/OS independent I seen was COBOL. Once you entered the machine/OS specifics in the first section (say 10-20 lines), the 'main' program would compile and execute on any machine from an IBM mainframe to the lowly TRS80-II.
Jay |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Thu Mar 16, 2017 8:37 am |
|
|
It's worth saying, that I have things like the unlock sequence, and things like flash I/O routines, that exactly match the data sheet, but are coded in C....
'Core' C, will 99.9% translate between almost any compiler (with the limitation of being 'aware' of data sizes). However we are writing in 'embedded C', which implies working directly with some parts of the chip, rather than relying on an 'OS' outside. Exactly the same is true of any language. Even languages like Pascal, when you get involved in directly accessing hardware, customisation for the machine becomes necessary.
Historically, perhaps ten years ago, a lot of CCS code would involve some assembler sections. Nowadays the need for these is getting less and less. However there are still the odd 'tiny' part, where it cleaner, safer, & probably quicker to write, in assembler. Sometimes there are little parts of the initialisation or setup, where the default is very 'safe', but often over complex.... |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Thu Mar 16, 2017 8:42 am |
|
|
temtronic wrote: | just a note... not all C is the same ! We've all seen C code presented here ,from another compiler, that will not work as written in CCS C. There's always tweeks to be done. |
I know and I agree. I'm just pointing out that tweaking C code - which is written in a sort of quasi-recognizable format - isn't all that difficult if you've been involved with coding or firmware for any length of time. Migrating a bunch of MOV, MUL, ADD, etc, perhaps with some instructions that don't exist on the platform to which you're migrating is a herculean task. Easier to start with a high level flowchart of what the program does and start fresh. Cheaper too. |
|
![](templates/subSilver/images/spacer.gif) |
gjs_rsdi
Joined: 06 Feb 2006 Posts: 468 Location: Bali
|
|
Posted: Sat Mar 18, 2017 7:03 am |
|
|
Used assembler with CCS when I had no choice.
With my old CCS compiler and PIC18F2520 was a problem using
Code: | setup_ccp2(CCP_CAPTURE_FE);
setup_ccp2(CCP_CAPTURE_RE); |
So I used
Code: | #asm
movlw 0x04//FE
movwf 0xFBA//CCP2CON
#endasm
#asm
movlw 0x05//RE
movwf 0xFBA//CCP2CON
#endasm
|
Worked flawlessly. But yes, you need to learn the hardware
Best wishes
Joe |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Sat Mar 18, 2017 1:06 pm |
|
|
However that doesn't need assembler:
Code: |
#byte CCP2CON = getenv("SFR:CCP2CON")
//then
CCP2CON=CCP_CAPTURE_FE;
//will set falling edge
CCP2CON=CCP_CAPTURE_RE;
//will set rising edge
|
Much cleaner.... |
|
![](templates/subSilver/images/spacer.gif) |
gjs_rsdi
Joined: 06 Feb 2006 Posts: 468 Location: Bali
|
|
Posted: Sun Mar 19, 2017 5:23 am |
|
|
As I suppose you know from my questions Ttelmah, I am not really a C programmer
Just not long time ago learned that I can use "getenv" for certain things.
So using assembler to overcome the bug was natural to me
Best wishes
James |
|
![](templates/subSilver/images/spacer.gif) |
|