Version 4 Comments

[Quique]

I'm testing the IDE v4.055/PCD v4.055
I created a new project with the Wizard
I chose DSPIC30F4013 and enabled the following peripheals
RS-232, Hardware pins of TX1,RX1 (F5-F4), 9600, 8, N, 1
RS232 receive data Interrupts (UART1)

A/D channels A0 to A3
SPI Master CkP=1 CKE=0, Divide by 16

Some generated identifiers are not recognized by the compiler:

1) setup_adc_ports(AN0_TO_AN3|VSS_VDD);
// I replaced the unknown identifier AN0_TO_AN3 by sAN0|sAN1|sAN2|sAN3 (defined in 30F4013.h)
2) setup_psp(PSP_DISABLED);
//I commented this line, the 30F4013 have PSP!?
3) setup_spi(SPI_MASTER|SPI_H_TO_L|SPI_XMIT_L_TO_H|SPI_CLK_DIV_16);
//The bold identifier is not defined for this MCU. I defined the SPI1CON bits
#bit CKP = 0x222.6
#bit CKE = 0x222.8
then
CKP=1;
CKE=0;
(Also is possible to define SPI_XMIT_LTO_H as 0x40)

With these minor modifications the A/D, SPI and UART Tx worked correctly, but not the UART Rx nor the RDA interrupt.
I also tried with TX2,RX2, and alternative TX1,RX1, waiting interrupt or polling without success.

Anyone have experienced this?

[Storic]

yes I have on the 24FJ series I stop trying and waiting for lots of fixes before I try again
_________________
What has been learnt if you make the same mistake?

[Guest]

I discovered the mistake!
The wizard generates the following line (in myfile.h) for the (supposed) UART1:
#use rs232(baud=9600,parity=N,xmit=PIN_F3,rcv=PIN_F2,bits=8)
and/or for UART2:
#use rs232(baud=9600,parity=N,xmit=PIN_F5,rcv=PIN_F4,bits=8)

but these lines are for SOFTWARE UARTs !!!

In previous versions, when the pins are the same as hardware UART ones, the compiler assumed hardware UART. Not now...

For HARDWARE UARTS is necessary to edit them...
#use rs232(baud=9600,parity=N,bits=8,UART1) or...
#use rs232(baud=9600,parity=N,bits=8,UART2) or...
#use rs232(baud=9600,parity=N,bits=8,UART1A) for alternate pins on UART1...
etc.

The CCS HELP for this directive (#USE RS232) is very detailed, but I didnt see it before... !!!!! ....... ... ...

Good luck Storic!!

[EdWaugh]

Hi Everyone,

I realise this is a pretty long/old thread now but I thought I would see if there were any opinions of the new v4.062. I've stayed with v3.249 with my 18F6722 until now but I just noticed the 18F6723 has been released that would be a drop in replacement but with a 12bit A2D and the nasty high interrupt bug (that meant they didn't work) fixed. I think CCS implemented a workaround for the high interrupt thing so you may not have noticed.
The 18f6723 is not listed on the website yet but I assume it will go into v4 but not v3.

So:
Any luck with v4.062?
How about with multiple serial ports and compilation units?

cheers

ed

[Ken Johnson]

Hi Ed

I just looked in \devices (V4.062) for the 18F6723 - it is not there yet :( If you let ccs know you need it, I expect they'll add it promptly.

I have had good results with the V4 compiler for some time now with the 18F and 16F parts. One project uses the 18F8722 with both serial ports (plus adc, spi, pwm, timers, fast interrupt, etc). This is a fairly complex project, and all works well.

I want to port this project to a dsPIC, but so far no-go. The code won't even run very far before the processor resets. It looks like variable assignments over-write sfr regs, but I can't pin it down :(

Multiple compilation units didn't work early on, so I went with the "traditional" (for ccs) approach, and haven't tried multiple compile since - maybe it works now?

Still hoping for a workable dsPIC compiler . . .

Ken

[Storic]

It seems that all or most of the issue I needed have been resolved. I am still yet to check in full, all of the small sample codes I have tried worked. now it is time o put it together and we will see what happens next
_________________
What has been learnt if you make the same mistake?

[Benjamin]

I've switched to version 4 since 4.060, (been using 3.249) and tried two very big projects on PIC18F6722, using UARTS, SPI, external memory (using addressmod), I2C... and everything compiles and works great for the first time in V4! I have had a few issues between V4.060 to V4.062 but CCS replied within 24h and bugs where quickly fixed. Also, the debuger never worked well with my projects and now I use it every day, it actually works 99% of the time.
I think it is safe to switch to V4 now. The new features in V4 are great and now that I'm used to them, I don't want to go back to V3!

[EdWaugh]

Hi,

That's good to know, could you tell me what options you are using? Are you using multiple compilation units or sticking to the ccs style of #including .c files? Have you set it to v3 compatibility mode or anything?

cheers

ed

[Benjamin]

I haven't tried multiple compilation units and I haven't had to change anything in my programs for them to work (no v3 compatilibity stuff), they compile and work fine.

[Laurent Chouinard]

Now I've just spend the last two hours trying to pass a pointer to ROM to a function, using v4.064, and even though it compiles, it always produces gibberish.

I've tried so many things that I couldn't really provide code here, so I'll just wildly ask: did anyone succeed doing something like that?

It's all very trivial. Purpose is to pass text strings in ROM to the printLCD function.

[Laurent Chouinard]

Follow-up: see http://www.ccsinfo.com/forum/viewtopic.php?t=33000

[Guest]

Noticed that the 4.064 makes mistakes in structs handling.

I am writing a CAN library for the dsPIC30F chips.

My chip is dsPIC30F6010A

Here is my struct.

/* Generic structure for CAN Transmit Data Length Code Register */
typedef struct CxTXxDLCBITS {
unsigned :3;
unsigned DLC :4;
unsigned TXRB0 :1;
unsigned TXRB1 :1;
unsigned TXRTR :1;
unsigned EID5_0 :6;
} ;
struct CxTXxDLCBITS C1TX0DLC;
#byte C1TX0DLC = 0x0364


When I make this operation it fails.

unsigned EID5_0 = 0x3E;
C1TX0DLC.EID5_0 = EID5_0;


If I look in the assembler list it looks like this:

365: C1TX0DLC.EID5_0 = EID5_0;
001B080200030 mov.w #0x3,0x0000
001B280B66365 and.b 0x0365
001B480BFC814 mov.b 0x0814,0x0000
001B680DD0042 sl 0x0000,#2,0x0000
001B880B24C00 and.b #0xc0,0x0000
001BA80B76365 ior.b 0x0365

The problem is “and.b #0xc0,0x0000”

It should not AND with 0xC0, because the EID5_0 variable is located from bit 2 to 7.
It should make AND with 0xFC.

[future_]

Hi,

how is function pointers support on the latest versions, anything useable yet?

I am waiting for it so I'll port a library from another project.

Thank you.

[kender]

[Franck26]

Hello,
About the multiple compilation units, I've tried it several times untill the V4.062, after that I gave up.
Still not working....
I've sent several email to CCS and still no reply .

Was it working before V4? or is it just a legend?

Franck.