 |
 |
| View previous topic :: View next topic |
| Author |
Message |
prwatCCS
Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK
|
| v3.190 and 18F6621 |
 Posted: Tue May 04, 2004 4:43 pm |
 |
|
Has anyone experience of using (or attempting to use) v3.190 with the 18F6621 part.
I have - with some frustrations - and am keen to learn of any other "known" problems before I start attempting to ship product.
So far I have seen :
(1) The original devices.dat shipped with v3.190 did not allow read_program_eeprom() calls to compile. A new one, emailed from CCS tech support did, but still failed to allow read_program_memory() calls. This can however be cured by editing the appropriate device file from within the program.
(2) Situations whereby system header files (eg 18F6621.h)already "open" in my project are read from a directory OTHER than the one shown as listed under Options/Include Dirs. This can be "fixed" by closing the files, recompiling and then reopening them!
(3) A situation whereby it seems necessary to place dummy lines of code that access structures in ROM in order to ensure that calls of the form
address = label_adress(name_of_structure) compile with the correct address of the structure/array. I am still in discussion with CCS tech support on this one and will post more details separately.
Anything else I should be aware of ??
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
 |
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| No experience yet ! |
| Posted: Tue May 04, 2004 5:51 pm |
|
|
Hi,
I posted a message some weeks ago asking for any tips on using this "new " chip.
I did not get any replies, yours is the first that has posted anything practical.
I visited CCS today because I am now starting that project with the pic18f6621.
I'll keep you posted if I run into anything special.
Best regards
Hans Wedemeyer |
|
|
prwatCCS
Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK
|
|
| Posted: Wed May 05, 2004 1:26 am |
|
|
To give you an outline of what I am using :
I am using the part at 40Mhz (10Mhz XTAL in *4 PLL mode).
Timer 0 and Timer1 interupts
Both serial ports at high speed (>200KB) using irq's for TX and RX.
The first six Analog inputs.
The SPI port for external serial eeprom.
Almost all of the other ports as general IO, leds, switches, EEprom select etc.
Not all the code is yet in place, but I have the serial ports, leds , switches etc going and code in place for ADC. Need to add SPI next - this will be based on earlier code I had running on an 18F452.
What I have so far now compiles and runs. I am using MPLAB ICD2 to program device and debug - some quirks with breakpoints now and again but progress can be made ....
regards
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
EMS
Guest
|
| 18FXXXX |
| Posted: Wed May 05, 2004 8:37 pm |
|
|
I've been using the CCS compiler for about a year. The compiler seems to generate rather good code. The debugger is another story. Breakpoint issues were brought up during version 3.148 and have been duplicated in 3.189. The bug is minor but when the program becomes large the time it takes to close out all the breakpoint windows is annoying. The code that was developed is an rs485(250kbps) peer to peer protocol that is used for building and street lighting control. This also includes a wireless protocol that allows peer to peer control over a large 65535 node network. Almost all of the 18F modules were used except the CAN module. If there are any bugs i will post it.
Ted Ems
EE
Blackbird |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| Project with 6621 |
| Posted: Wed May 05, 2004 10:58 pm |
|
|
I'm doing a low current and slow application. It will use SPI both UARTs and software I2C(spit)
There will be FRAM and other storage plus three CCP ports.
A lot of code is already working on PIC18F252.
I'll be doing RTC as described in the data sheet, my only "unkown" is will I have to take care of possible interrupt collisions with other interrupts... Timer RS232 etc.
If the silicon does not have bugs I can't see there are any other special problems. |
|
|
prwatCCS
Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK
|
|
| Posted: Sun May 09, 2004 5:04 pm |
|
|
In my original post I indicated that I had referred a problem to CCS and that I would post details of my findings. After considerable difficulty in getting a straight answer from Tech support, and several phone calls by myself from the UK to the US, I think they have now acknowledged a problem and | Quote: | | It will be fixed in the next release |
. However they gave no indication of timescale in any of their emails ....
I have taken the time to extract the offending section of code out of my project and present it as an example of the problem.
If you are interested, please follow the instructions in the code below.
Unfortunately for CCS, my original code didn't crash the compiler ...
but when I came to prepare this example, it did, so I'll be sending it to them again for further consideration.
All of this came about because I wanted a simple and efficient storage of table data in program memory which can be copied to RAM at run-time.
| Code: |
// main.c
//
// copyright Howard Eaton Lighting Ltd 2004
//
// author : Peter Willis
#include <18F6621.h>
#fuses DEBUG
#device ICD=TRUE
#fuses H4,WRT,PUT,NOPROTECT,PUT,BROWNOUT,NOLVP,NOWDT,NOWRT, NOWRTD, NOWAIT
#fuses MCU, NOWRTC, NOWRTB, NOEBTR, NOEBTRB, NOCPB, MCLR
#fuses WDT128,NOOSCSEN,BORV20,NOCPD,STVREN
#device ADC=10
#define CLOCK_FREQUENCY 40000000
#define FOSC 40
#use delay(clock=CLOCK_FREQUENCY)
// To Observe the problem I am presenting
//
// (i) compile this file as is, with no definition of RELOCATE_TABLES or FIX_3190_PROBLEM
//
// you will get the expected result, with tables efficiently generated at 0004: DATA 00,00
// and correct resolutions of address when using label_address() calls to find the start of each table.
// (ii) uncomment the line below to allow defintion of RELOCATE_TABLES and attempt to compile
//
// WARNING - on my system, if you have enabled Standad COD, Expanded COD or COFF debug file output, the
// compilation window never goes away and you appear to endlessly compile when
// RELOCATE_TABLES is defined and FIX_3190_PROBLEM 1 is not defined.
// so be warned - there are at least two related problems here. What you should really be looking at is the list file
// where the tables have now appeared incorrectly as
/*
6000: ADDWF FF9,F
6002: RETLW 00
6004: RETLW 00
6006: RETLW 00
6008: RETLW 00
600A: RETLW 00
600C: RETLW 00
and the label_address() calls all point (erroneously) at 0x026A
.................... address = label_address(W0_HDR);
0034: MOVLW 02
0036: MOVWF 03
0038: MOVLW 6A
003A: MOVWF 1F
003C: MOVFF 03,20
0040: CLRF 21
0042: CLRF 22
.................... stepaddress = label_address(W0_DATA);
0044: MOVLW 02
0046: MOVWF 03
0048: MOVLW 6A
004A: MOVWF 23
004C: MOVFF 03,24
0050: CLRF 25
0052: CLRF 26
.................... break;
*/
// (iii) uncomment the line below to allow defintion of FIX_3190_PROBLEM and attempt to compile
// Now - it admittedly works, but you get a lot more code than you really needed and you have to remember to add the dummy
// lines of table access code every time you add more structures in ROM space.
//
//
// NOTE : you do NOT have to have conciously relocated the tables using #ORG to see this problem. I first encountered it in my project
// when the tables were automaticlly placed after my moderately large interrupt handlers.
//
// I have seen the problem with compiler versions v3.188 and v3.190 - I have not tried others.
//#define RELOCATE_TABLES 1
//#define FIX_3190_PROBLEM 1
#opt 9
#use fast_io( A )
#use fast_io( B )
#use fast_io( C )
#use fast_io( D )
#use fast_io( E )
#use fast_io( F )
#use fast_io( G )
///////////////////////////////////////////////////////////////////////
//
// local defines and typedefs
typedef unsigned int8 u8;
typedef unsigned int16 u16;
typedef unsigned int32 u32;
typedef signed int8 s8;
typedef struct {
u16 one;
u8 two;
u8 three;
u16 four;
u8 five;
u8 six;
u8 seven;
} Header_T;
typedef struct {
u16 onedata;
u16 twodata;
u16 threedata;
u8 fourarray[10];
} Data_T;
Header_T _Header;
Data_T _Data;
#ifdef RELOCATE_TABLES
#ORG 0x6000,0x6fff DEFAULT
#endif
Header_T CONST W0_HDR[] = { 0x0000,0,0,0x0000,3,0,0 };
Data_T CONST W0_DATA[] = {
600,300,300,0x7F,0xFF,0xFF,0xFF,0,0,0,0,0,0,
600,300,300,0xFF,0x7F,0xFF,0xFF,0,0,0,0,0,0,
600,300,300,0xFF,0xFF,0x7F,0xFF,0,0,0,0,0,0,
600,300,300,0xFF,0xFF,0xFF,0x7F,0,0,0,0,0,0 };
Header_T CONST W1_HDR[] = { 0x0101,0,0,0x0000,3,0,0 };
Data_T CONST W1_DATA[] = {
500,100,300,0x00,0xFF,0xFF,0xFF,0,0,0,0,0,0,
500,100,300,0xFF,0x00,0xFF,0xFF,0,0,0,0,0,0,
500,100,300,0xFF,0xFF,0x00,0xFF,0,0,0,0,0,0,
500,100,300,0xFF,0xFF,0xFF,0x00,0,0,0,0,0,0 };
#ifdef RELOCATE_TABLES
#ORG DEFAULT
#endif
void InitTables(void);
////////////////////////////////////////////////////////////////////////
//
// here we go...
//
// This code is ONLY to demonstrate table generation problems in CCS v3.190 (and earlier)
//
// some of the names have been changed to protect the innocent...
void main()
{
u8 select;
u32 address;
u32 stepaddress;
InitTables();
while(1)
{
switch(select)
{
case 0:
address = label_address(W0_HDR);
stepaddress = label_address(W0_DATA);
break;
case 1:
address = label_address(W1_HDR);
stepaddress = label_address(W1_DATA);
break;
}
}
}
void InitTables(void)
{
u8 slot;
u16 temp;
slot = 0;
#ifdef FIX_3190_PROBLEM
if(slot !=0)
{ //We NEVER actually run this code - it just needs to exist !
temp = W0_DATA[0].fourarray[slot]; //seem to need this line to ensure existence of ROM table
temp = W1_DATA[0].fourarray[slot]; //seem to need this line to ensure existence of ROM table
temp = W0_HDR[slot].one; //seem to need this line to ensure existence of ROM table
temp = W1_HDR[slot].one; //seem to need this line to ensure existence of ROM table
}
#endif
}
|
enjoy
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK |
|
|
Guest
|
| Confirmed the compiler loops ! |
| Posted: Thu May 20, 2004 7:27 am |
|
|
I would like to confirm the compiler does not like the code if
#define RELOCATE_TABLES 1
is used.
CCS have started NOT updating the compiler as frequently as they used to do.
Other people have also reported issues.
H'mm spending money on 1 year subscription may not be worth it anymore.
Anyway, thanks for the heads up on this issue. I'm not using tables at all.
Hans W |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
