| View previous topic :: View next topic |
| Author |
Message |
bela
Joined: 31 Aug 2008
Posts: 27
Location: Bedford, BEDS UK
|
| DSPIC33FJ128MC802 |
 Posted: Thu Aug 20, 2009 9:28 am |
 |
|
Does anyone know why the header file calls for 61 IO pins and 6 analogue ports (PortB-PortG) when the device is a 28 pin with only 5 A ports and a full B Port?
PCD 4.080
This is bad. I can't use that device now. |
|
 |
dyeatman
Joined: 06 Sep 2003
Posts: 1933
Location: Norman, OK
|
|
| Posted: Thu Aug 20, 2009 9:37 am |
|
|
Did you report this to CCS Support? They may be able to help you get the corrected version.
_________________
Google and Forum Search are some of your best tools!!!! |
|
|
bela
Joined: 31 Aug 2008
Posts: 27
Location: Bedford, BEDS UK
|
|
| Posted: Thu Aug 20, 2009 10:06 am |
|
|
| Just done. Has anyone else come across this? |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Aug 20, 2009 10:28 am |
|
|
Your complaining about ten month old PCD 4.080.
- The device file has been changed since long
- Did you experience any problem when accessing the existing pins with V4.080? The pin codes are still identical in newer device file.
- What do you exactly mean with
| Quote: | | I can't use that device now. |
A bunch of general PCD bugs has been removed since V4.080, it may be meaningful to use a recent version anyway. |
|
|
bela
Joined: 31 Aug 2008
Posts: 27
Location: Bedford, BEDS UK
|
|
| Posted: Thu Aug 20, 2009 11:29 am |
|
|
| Quote: |
Your complaining about ten month old PCD 4.080.
|
Yes. Should have worked ten months ago because ten months ago I paid for a compiler that apparently supported this device. It didn't, that's a fundamental problem so I am complaining.
| Quote: |
- Did you experience any problem when accessing the existing pins with V4.080? The pin codes are still identical in newer device file.
|
Yes because as already mentioned the A port is undefined. Also, the C-G ports don't exist. Introducing further possible problems by modifying header files is not an option for me.
| Quote: |
What do you exactly mean with "I can't use that device now."
|
Here's what I meant exactly: I meant that I have had to switch to a different device because the code won't compile.
If there are strange and hard to track down bugs then that's fine if there's a new issue but any code for the supported devices should work no matter how old I let the compiler get. It's got that old because I don't use any of the tools, including download manager, other than the raw compiler since they look and operate like a six-year-old has written it. That's probably why I wasn't aware of any new versions. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Thu Aug 20, 2009 11:56 am |
|
|
Microchip is coming out with new devices all the time.
It's crazy -- and it's hard to keep up with.
CCS's policy is: You find a bug, we update your compiler for free.
Pretty cool in my book (I've worked with a lot of companies where I find the bugs but only get to see them fixed in the next paid version. Bleah!)
Let 'em know ... they'll take care of you if it's a compiler problem.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Aug 20, 2009 12:01 pm |
|
|
O.K., I didn't realize, that the port A definititions have been missing in the old device file. So I understand the "can't use" point.
I also agree, that it's reasonable to expect a functional compiler. I also down't want to play down PCD's lack of initial product quality. Let's say, I took it for granted.
On the other hand, the CCS concept of built-in functions and hardware abstraction layer involves a high effort in adapting the great variety of PIC24 and 30/33 chips. Possibly, it has been underestimated at CCS when scheduling the 16-bit compiler.
If you use C30, adaption of different chips is basically your business. You get a hopefully correct SFR definition file, nothing more. It's easy to operate PIC chips that aren't correctly supported by PCD in the same way. So "can't use" isn't true, actually.
Unfortunately there has been also a number of more general PCD bugs, some persisting until recent V4.097. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Thu Aug 20, 2009 12:59 pm |
|
|
| FvM wrote: | | If you use C30, adaption of different chips is basically your business. You get a hopefully correct SFR definition file, nothing more. It's easy to operate PIC chips that aren't correctly supported by PCD in the same way. So "can't use" isn't true, actually. |
I remember that about C18. What-a-pain.
There's a lot more to CCS than meets the eye. Try C18 w/the 30day trial version and see. Most of the time, EVERY project is more of a new adventure than one would want. :(
| FvM wrote: | | Unfortunately there has been also a number of more general PCD bugs, some persisting until recent V4.097. |
I have PCD, but haven't been using it lately (buried in PCH)... what bugs are still around that I should be on the lookout for?
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Thu Aug 20, 2009 3:41 pm |
|
|
One year ago, there was a rather high likelihood, that a few lines complex calculation involving int32 and pointers failed in PCD, mostly by confusing working registers.
These bugs have been almost fixed, my ultimative test case, the RFC 1321 CHAP algorithm is still failing in most recent V4.097. I previously found a workaround by decomposing some of the most complex int32 expressions.
http://www.ccsinfo.com/forum/viewtopic.php?t=36359
This worked for V4.081, temporarily my workaround was invalidated by PCD updates, now (since V4.096, I think) it's working again. But the original MD5 code doesn't yet.
Apart from this case (complex int32 operations with pointers), I have a special bug with pointer arithmetics and another with int16/int8 compare
| Code: | | (int16array[int8idx] >> 8) == var8) |
One year ago, I also experienced failure of several PCD built-in functions, e.g. with ADC or CRC unit. I moved to low-level SFR programming, thus I don't know, if they have been fixed in the meantime. |
|
|
bela
Joined: 31 Aug 2008
Posts: 27
Location: Bedford, BEDS UK
|
|
| Posted: Fri Aug 21, 2009 11:55 am |
|
|
Thanks guys for your replies on this subject.
I remember from a very old version we had of the CCS compiler which included a tool for adding a new / modifying existing device in devices.dat. As far as PCD / PCH goes, We didn't purchase the GUI tools, just the raw compiler as I prefer to run it Linux. (I run the windows version in Linux - long story)
So, I'm aware that one could probably use almost any PIC with CCS but in reality, the budget allowed for 10 days to complete the software so any remote chance of introducing problems was not an option. In general, all the projects I'm tasked with are to a budget and so I often need to 'stick to what I know' to get it done in time! :-)
Which is why, if I was somewhat abrupt about it spoiling my plans, my apologies. CCS replied to my complaint over night and sent me an updated header. I thought that was very prompt and professional.
I've got to a point where the software is now 'good enough' and it has raised a question. If you guys wouldn't mind me picking your brains:
The project is essentially to upload bitmap files onto two oled displays. We are not deigning a PCB for this one because of the budget problem (and also that it's overkill for this demo) so I'm using a Microchip demo board part # DM300027, 28 pin 24Fs and dsPIC33s. This demo board is ideal as it's tiny and has USB. The demo board uses an 18F2450 as a simple USB to serial converter and I'm using the dsPIC above as the main micro, connected to the densitron OLEDs over SPI.
The OLEDs are 160 x 128 RGB which makes 61440 bytes to fill the screen.
I have modified the 18F chip to do full speed USB, using the usb.c and HAL from the compiler. the 18F is working very well in terms of USB. The existing connections between the two PICS (tx and rx) are now CLK and DAT creating a simple two wire interface. Thankfully, the CLK (dsPIC end) is on a CN interrupt port. The dsPIC's interrupt for this simply reads the DAT port status and buffers up the data - 64 byte circular buffer.
The dsPIC forwards the data onto the SPI ports of the OLEDS. The remote PC program has already pulled in the bitmap file and re formatted it to how the OLEDs expect the RGB data.
The dsPIC is running at 80mhz (25mhz OSC / PLL). The 18F is running at 48mhz (USB clock / 2). I understand that 80mhz on a dsPIC should be 40 MPIPS? However, the 18F PIC needs to delay for at least 5 clock cycles on the CLK pin toggle so that the dsPIC has time to interrupt and set the bit in the buffer. But why?
The displays still take one second to update and you can see the screen 'refreshing' which looks undesirable.
So these are my questions:
1. Am I at the limit in terms of what I can do with a dsPIC?
2. Compressed data is better but is there a library (source code) out there that I can use to decompress and figure out how to compress it at the windows/Linux PC end?
Thanks for any help.
Darren. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Fri Aug 21, 2009 5:50 pm |
|
|
what are the speeds of the various data links?
SPI is set for ?
The 18F -> 24F is set for ?
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
bela
Joined: 31 Aug 2008
Posts: 27
Location: Bedford, BEDS UK
|
|
| Posted: Mon Aug 24, 2009 3:03 am |
|
|
Hi. I'm not using the compiler routines, I'm trying to clock out / interrupt in as fast a possible.
This is the interrupt code in the dsPIC. The buffered data is forwarded onto the oled displays.
| Code: |
#INT_CNI
void cni_isr()
{
// this interrupt fires when the
// Clock from the USB pic changing state
short dtwi_temp;
dtwi_bit_counter--;
if(input(DTWI_DATA_IN_PORT))bit_set(dtwi_byte, dtwi_bit_counter);
if(dtwi_bit_counter==0) {
dtwi_buffer[dtwi_bin]=dtwi_byte;
dtwi_temp=dtwi_bin;
dtwi_bin=(dtwi_bin+1) % DTWI_BSIZE;
if(dtwi_bin==dtwi_bout)dtwi_bin=dtwi_temp;
dtwi_bit_counter=8;
dtwi_byte=0;
}
}
|
This is the bit banging out code in the 18F (entire file)
| Code: |
#include <18F2450.h>
#fuses NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
//#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7)
#define USB_HID_DEVICE FALSE //Not a HID driver
#define USB_EP1_TX_ENABLE USB_ENABLE_BULK //turn on EP1(EndPoint1) for IN bulk/interrupt transfers
#define USB_EP1_RX_ENABLE USB_ENABLE_BULK //turn on EP1(EndPoint1) for OUT bulk/interrupt transfers
#define USB_EP1_TX_SIZE 1 //size to allocate for the tx endpoint 1 buffer
#define USB_EP1_RX_SIZE 1 //size to allocate for the rx endpoint 1 buffer
// Daz's special two wire interface (receiver) pins...
#define CLK_PORT PIN_C7
#define DAT_PORT PIN_C6
#define USB_EP3_TX_SIZE 0
#define USB_EP4_TX_SIZE 0
#define USB_EP5_TX_SIZE 0
#define USB_EP6_TX_SIZE 0
#define USB_EP7_TX_SIZE 0
#define USB_EP8_TX_SIZE 0
#define USB_EP9_TX_SIZE 0
#define USB_EP10_TX_SIZE 0
#define USB_EP11_TX_SIZE 0
#define USB_EP12_TX_SIZE 0
#define USB_EP13_TX_SIZE 0
#define USB_EP14_TX_SIZE 0
#define USB_EP15_TX_SIZE 0
#define USB_EP3_RX_SIZE 0
#define USB_EP4_RX_SIZE 0
#define USB_EP5_RX_SIZE 0
#define USB_EP6_RX_SIZE 0
#define USB_EP7_RX_SIZE 0
#define USB_EP8_RX_SIZE 0
#define USB_EP9_RX_SIZE 0
#define USB_EP10_RX_SIZE 0
#define USB_EP11_RX_SIZE 0
#define USB_EP12_RX_SIZE 0
#define USB_EP13_RX_SIZE 0
#define USB_EP14_RX_SIZE 0
#define USB_EP15_RX_SIZE 0
#include <USB_HAL_PIC18.h> //Microchip PIC18Fxx5x Hardware layer for CCS's PIC USB driver
#include <PicUSB.h> //Hardware descriptor tables
#include <usb.c> //CCS Library for USB comms
int rxdata[64];
void transmit()
{
int cloop=8;
while(TRUE) {
cloop--;
output_bit(DAT_PORT, bit_test(rxdata[0], cloop));
output_toggle(CLK_PORT);
delay_cycles(5);
if(cloop==0)break;
}
}
void usb_wait_for_enumeration1()
{
output_high(PIN_A2);
usb_wait_for_enumeration();
output_low(PIN_A2);
usb_task();
}
void usb_wait_for_enumeration2()
{
output_high(PIN_A3);
usb_wait_for_enumeration();
output_low(PIN_A3);
usb_task();
}
void main(void)
{
usb_init();
usb_task();
usb_wait_for_enumeration1();
while (TRUE) {
if(usb_enumerated()) {
if (usb_kbhit(1)) {
usb_get_packet(1, rxdata, 1);
transmit();
}
}
else usb_wait_for_enumeration2();
}
}
|
And this is the code which pushes the buffered data onto the oleds in the dsPIC...
| Code: |
void oled_write_dram8(unsigned short data)
{
short loop=8;
/* write the 16 bit RGBdata out */
if(oled_selected==1){ output_low(OLED_CS1); }
if(oled_selected==2){ output_low(OLED_CS2); }
while(TRUE) {
loop--;
output_low(SCLOCK);
output_bit(SDATA_TX, bit_test(data, loop)); // spit it out
output_high(SCLOCK); // set the clock
//delay_cycles(1); // tDHS
if(loop==0)break;
}
if(oled_selected==1){ output_high(OLED_CS1); }
if(oled_selected==2){ output_high(OLED_CS2); }
//delay_cycles(1); // tCSH
}
|
Thanks for any help. |
|
|
bkamen
Joined: 07 Jan 2004
Posts: 1615
Location: Central Illinois, USA
|
|
| Posted: Mon Aug 24, 2009 9:55 am |
|
|
pardon me for asking the obvious but:
1: Why are you using software SPI over hardware?
2: Have you used an oscilloscope to monitor the the data transmissions to see where the gaps are?
From what you've described, I can see all sorts of places for a slow down.
I would be doing as much data transferring in hardware when possible to keep the PICs available for other things.
-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
