CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Using Canbus and TCPIP at the same time

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
user_1066



Joined: 10 Feb 2017
Posts: 6

View user's profile Send private message

Using Canbus and TCPIP at the same time
PostPosted: Wed Nov 15, 2017 7:28 am     Reply with quote

Hi

I'm working on a project that uses TCPIP via an ENC28J60 on a dsPic33. All works fine.

I need to add canbus to the project but immediately run into compiler issues.

I've gone back and used the Project 24 wizard to create a completely new project and added both TCPIP and Canbus and it produces the same set of errors. This is with absolutely no extra code added.

Firstly, 33EP512MC806_registers.h redefines a whole set of registers like
#word C1CTRL1 = 0x400 etc

Ok, so I commented all these out

Then can-pic24.h has Duplicate #locates like
#word C1FEN1=getenv("SFR:C1FEN1")

Which doesn't stop it compiling, but I then get
Not enough RAM for all variables, which is a bit strange, because if I compile canbus and TCPIP separately, they use very little RAM.

I'm guessing that there is some interaction there somewhere but I can't find it.

Any help would be appreciated.

Thanks

CCS Compiler Version 5.075
Pic dsPic33512MC806
Ttelmah



Joined: 11 Mar 2010
Posts: 19186

View user's profile Send private message

PostPosted: Wed Nov 15, 2017 8:03 am     Reply with quote

Do some careful forum searches (perhaps using Google to search). I remember about a year ago, somebody posting the same problem (CANBUS with a network also used - not sure if he was using TCPIP)
Unfortunately these CCS 'libraries' are written generally to be used on their own. Hopefully you can find the thread or somebody else can point you to it. May well help.
user_1066



Joined: 10 Feb 2017
Posts: 6

View user's profile Send private message

PostPosted: Wed Nov 15, 2017 9:12 am     Reply with quote

Thanks for the Help.

After looking further I found that
Code:

      #BANK_DMA
      uint16_t ecan1_message_buffer[32][8];


in can-PIC24.c is giving

"Not enough RAM for all variables" Message.

So possibly the TCPIP stack is locating something in the DMA area as well?

[Edit]

#device PSV=16

was in the TCPIP code which stops the use of #BANK_DMA !!! for some reason
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Thu Nov 16, 2017 5:29 am     Reply with quote

Ttelmah wrote:
I remember about a year ago, somebody posting the same problem (CANBUS with a network also used - not sure if he was using TCPIP)
Unfortunately these CCS 'libraries' are written generally to be used on their own.


That may well have been me. I was indeed developing a PIC24 based application with an ENC624J600 LAN interface and CAN. I based it on the CCS supplied version of Microchip's TCP/IP stack and stumbled across many problems, which I kicked over, got round and generally swore at one by one. It's been working, and working well for nine months or so and is in production.

However, it wasn't easy to get it working, and even less so to get it reliable. It took something like three months of hard grind to get it, and related code, into some sort of shape suitable for production use.

That said, I do know a number of things. Yes, there is a problem with the xxxxxxregister.h file clashing with CCS CAN code. The two were clearly never intended to play together. The register file is used as part of a porting wrapper to make the CCS C compiler compatible (after a fashion) with the XCn code of Microchip's stack. You need, as you've already discovered, to comment out all references to CAN peripherals in the header file.

Also the porting forces case sensitivity on as the Microchip code requires it, whereas CCS C code normally doesn't need it. This can also cause some issues with CCS code.

The CCS is not a fully ported version of the Microchip stack. Only the features, and its a very limited subset, are ported. Yes, you can turn on features of the Microchip stack, but expect them not to work without significant effort.

The PSV is used primarily to access a file system, for webpages, in program memory. PSV is used to map the file system into RAM address space for faster, more direct access. If you enable HTTP support in the CCS wizard then it uses this method of storing the file system. I found the PSV implementation as provided by CCS did not work and p24Hxxxx.h needed modification. The PSV code needs to be able to be interruptible, hence the PSV_SAVE and PSV_RESTORE macros. I, however, did not want to use program memory as I needed uploadable webpages, so my early work on getting the PSV stuff sorted was arguably pointless. Getting the required stack code to work with external EEPROM was quite another matter as CCS had not ported it.

My hardware uses PMP to interface with the ENC624J600, not SPI. Again, this is an available option on the Microchip stack, but again CCS had not ported it. I used the PMP for improved performance, but as a by-product, it neatly sidestepped using the SPI for two devices, LAN chip and EEPROM. That's complicated as you need interruptible access to the EEPROM (i.e. implement hold).

I do not recall any memory issues, but that may well be related to the set of options I was using. CAN support on 24s and dsPICs etc requires a fair chunk of memory as the CAN peripheral on these PICs is significantly more sophisticated and implements much more buffering than that found on 18s. I implemented another layer of buffering, on both transmit and receive, on top of that, and still had no RAM issues. However, as another part of the porting process, the TCP/IP stack turns on PASS STRINGs IN RAM, and this will use more RAM than with it turned off. This may, with some combinations of stack functionality, use a lot more RAM than you are expecting.

I did not encounter any issue with #BANK_DMA. I cannot find it in any of my project code. I can make no comment on it. Perhaps it is compiler issue related...

I can only add that getting all this to work, and more importantly work reliably, was difficult and time consuming: one of the most complex debugging tasks (debugging as I didn't write most of the code!) I have ever had to undertake.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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