Jump to content


Photo

Porting Tcp/ip To Boostc


55 replies to this topic

#1 tunretni

tunretni

    Newbrie

  • Members
  • 2 posts

Posted 16 April 2007 - 04:47 PM

Has anyone undertaken such a port? I have a PICDEM2.net board and I'm using it to prototype an embedded application that requires networking.

I'd like to use BoostC as this is a non-commercial application for my own use only and I don't want to spend $500 for a compiler, but, if the port is a huge effort, my time is pretty scarce.

I'm interested to know if anyone has already done this work, or perhaps someone is working on it and needs help.

#2 emte

emte

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 378 posts
  • Location:Victoria, BC, Canada

Posted 17 April 2007 - 03:02 AM

yes/no, BrownFrog is getting Microchip's TCP/IP stack to work with BoostC
but it is so badly written it takes a lot to sort out and it seems a few
issues with BoostC vs MCC18 are cropping up as well.

The code is property of Microchip so it cannot be offered as anything
more than a personal library, which should be no issue for you.

An effort to develop a native BoostC enc28j60 TCP/IP stack would be
great, but if any project is in the works i am unaware.
Good intentions always exist, intelligent thought patterns ... not quite as much

Are you linked in?

#3 vez

vez

    Newbrie

  • Members
  • 7 posts

Posted 23 April 2007 - 06:39 AM

Has anyone undertaken such a port? I have a PICDEM2.net board and I'm using it to prototype an embedded application that requires networking.

I'd like to use BoostC as this is a non-commercial application for my own use only and I don't want to spend $500 for a compiler, but, if the port is a huge effort, my time is pretty scarce.

I'm interested to know if anyone has already done this work, or perhaps someone is working on it and needs help.

<{POST_SNAPBACK}>

I tried to do this, but the main problem - boostc does not support bit fields, without this this is almost impossible. Moreover, Hi-Tech PICC18 can compile stack (there is a project file for this), but the gotten code is inoperable, only C18 gave me workable code for now. ( I tested for PICDEMNET.2 board)

#4 kenk

kenk

    Newbrie

  • Members
  • 3 posts

Posted 23 April 2007 - 01:57 PM

emte and others,
There is an ongoing discussion regarding an open software initiative to develop a TCP/IP stack other than what is avaliable from Microchip. The discussion is centered about the development platform and the services on the platform. Who is BrownFrog that was referenced??? Can you give me a web address or phone#??? I am trying to get NovoRTOS considered as the multitasker to be used. Again, we are only in a discussion phase. The development module is complete and tested. It is an 18F87J60 with sectorized SRAM as packet buffering space, RS485, RS232, Ramtron FRAM (2 devices), LEDS, piezo audio, dedicated parallel port for code tracing and, of course, an ICD2 connector. We have been in difficult discussions with Microchip because the 87J60 has problems with the ICD2 Debug Exec at this time. No indication when this issue will be resolved, so we are on a semihold with this. I will let the Forum know when we have moved off center on this project.
kenk

#5 emte

emte

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 378 posts
  • Location:Victoria, BC, Canada

Posted 23 April 2007 - 02:21 PM

... That seems like a bit of overkill, unless you need a full stack inside a
regular PIC. Myself i just use the enc28j60 since it already exists and is cheap.

Brownfrog is a member of this forum, you can see a few posts from him.
Good intentions always exist, intelligent thought patterns ... not quite as much

Are you linked in?

#6 asmallri

asmallri

    Enthusiast

  • EstablishedMember
  • PipPip
  • 169 posts
  • Location:Western Australia

Posted 25 April 2007 - 02:44 AM

emte and others,
There is an ongoing discussion regarding an open software initiative to develop a TCP/IP stack other than what is avaliable from Microchip.  The discussion is centered about the development platform and the services on the platform....

It is an 18F87J60 with sectorized SRAM as packet buffering space, RS485, RS232, Ramtron FRAM (2 devices), LEDS, piezo audio, dedicated parallel port for code tracing and, of course, an ICD2 connector. 


I think this is a bit over the top for a PIC Microcontroller. For the amount of money spent I think a Rabbit platform would be more cost effective and versatile. I think the PIC is a poor choice for a generalised networking development platform for multiple reasons.

We have been in difficult discussions with Microchip because the 87J60 has problems with the ICD2 Debug Exec at this time. 


Two problems with the ICD, Microchip have effectively superseded it and the PIC's CPU and embedded Ethernet controller have to content for access to the PIC's RAM. I wasted a lot of time debugging non existing faults before I realised this solution (ICD2 with EtherPIC) was fundamentally flawed. I use a bootloader for developing and debugging the 18FxxJ6x family. It is very effective and significantly faster than using an ICD2 with this PIC family.

No indication when this issue will be resolved, so we are on a semihold with this.

If you are holding on a pending ICD2 fix you are likely to be waiting for the next ice age.

There are a number of challenges with the RTOS, and generalized open source approach, To be attractive to the wider community you need to support multiple compilers. While this may seem trivial in a PC environment, it is not trivial in an embedded PIC environment because there is no common hardware abstraction layer. Each compiler has their own unique approach to dealing with low level I/O. No two compilers use the same native base types. Take the obvious, an 18F series PIC's base type is 8 bits. You would naturally expect all PIC C compilers would have an 8 bit integer base type but instead you have CCS with 8 bit, MCHP with 16bit, BoostC with 32 bit etc. The challenges represented by these vastly different implementations of compilers and linkers are not insurmountable but it does tend to mean the stack would initially be developed for the largest potential market as opposed to the "general" market, in this case the MCHP C18 compiler. However, MCHP already has a free (but expensive) stack so not a lot of incentive except for developers that do not like the unreasonable licensing conditions tied to the Microchip stack. Consequently the niche market for this stack gets even smaller.
Regards, Andrew

Need a file system? http://www.brushelec...p?page=software
Home of Ethernet and SD/MMC Bootloader for PICs!!

#7 emte

emte

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 378 posts
  • Location:Victoria, BC, Canada

Posted 25 April 2007 - 03:29 AM

Myself, i think the problem is that of public perception.

There is truly no need for the "stack" Microchip has produced.
It is bloated, poorly implemented, and suffers terribly from
something that looks a lot like "code inheritance" syndrom.

One can not cleanly strip it down to the elements you need to use
in a project. Rarely would you ever encounter a case where you
would need even half the elements in it ( ignoring the juducious
duplications in it ).

Each layer should have been cleanly implemented and inherited
as all the models dictate. In a C world this is not always easy, BUT
there is a new oportunity put forth by BOTH SourceBoost and
Microchip with the introduction of their new and (newish) C++
compilers. Sure, Microchip's is currently restricted to dsPICs but
that does not mean there may not be a plan to shift more devices
to it in a push for a cross-platform compiler(as it is GCC based).

But BoostC++ is already here and needs an intensive project
(such as this) to test for and help develop it in a way only live
testing can.
Good intentions always exist, intelligent thought patterns ... not quite as much

Are you linked in?

#8 kenk

kenk

    Newbrie

  • Members
  • 3 posts

Posted 25 April 2007 - 03:26 PM

Hello,
I did not enter the earlier post to start an argument about Microchip's TCP/IP stack! I was simply noting that there is an ongoing discussion about an open software initiative. I wanted to outline a development platform that maight be used for this process for those people who might be interested. Period!

I have used the Rabbit solution and do not like it because there is no support for 9-bit RS485 protocols. It is not significantly faster and certainly not cheaper. The compilier has its issues as well. Its called 'been there and done that'.

I have already tried the ENC28J60 route. My view is that the SPI becomes a bottleneck, but, this is not relevant to this discussion. I do not quite understand the comment about RAM contention inside the PIC between the cpu and Ethernet controller on the 18FxxJ6x??? I understand the issue of the ICD2 shortcommings. This is why I added the dedicated parallel port connection for code tracing. I would prefer an ICE2000 module, but none will ever be available and I can understand why. So we (users) need to be creative!!!

Any design is a careful tradeoff between hardware and software complexity. The software also has to be carefully partioned and segmented between WHAT SHOULD BE low level assembly and high level modularity.

I like to learn from others efforts. We cannot learn if there is no detailed discussion about other's problems and HOW THEY SOLVED THEM.
kenk

#9 emte

emte

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 378 posts
  • Location:Victoria, BC, Canada

Posted 25 April 2007 - 04:45 PM

I have already tried the ENC28J60 route.  My view is that the SPI becomes a bottleneck, but, this is not relevant to this discussion.  I do not quite understand the comment about RAM contention inside the PIC between the cpu and Ethernet controller on the 18FxxJ6x???  I understand the issue of the ICD2 shortcommings.  This is why I added the dedicated parallel port connection for code tracing.  I would prefer an ICE2000 module, but none will ever be available and I can understand why.  So we (users) need to be creative!!!

<{POST_SNAPBACK}>


Why do you view SPI as the bottleneck? the enc28J60 only does 10Base-T which is
pretty slow( not that the MCU attatched is super fast either :blink: ).

I am with you on not understanding the whole 18F ram thing as well, or even the rabbit one.
Why the MCU talking to the ethernet chip is a factor as well seems strange. If you spend
enough time stripping it down, the http webserver fits just fine even on the 10F and 12F
chips, as you can find on the internet. Sure you need an external data storage for it to use,
but that is no differnet than a full fledged production server.
One of the old 16F84 server pages: WWWpic2

Btw ICEs are not really any better than an ICD and both are more expensive than simply
dumping data out your serial port. Its a little more crude but faster to implement and change.
Good intentions always exist, intelligent thought patterns ... not quite as much

Are you linked in?

#10 asmallri

asmallri

    Enthusiast

  • EstablishedMember
  • PipPip
  • 169 posts
  • Location:Western Australia

Posted 25 April 2007 - 05:11 PM

I do not quite understand the comment about RAM contention inside the PIC between the cpu and Ethernet controller on the 18FxxJ6x???


The PIC's CPU and the Ethernet Module compete for access to the PIC's Ethernet modules RAM. This is why the driver code has the NOPs embedded. The ICD2, when it accesses this memory, does not "know" when it should introduce NOPs and therefore when tracing with the ICDs the values return may (and often are) garbage.

... If you spend enough time stripping it down, the http webserver fits just fine even on the 10F and 12F chips, as you can find on the internet.


These implementations are not attempting to drive an Ethernet controller.
Regards, Andrew

Need a file system? http://www.brushelec...p?page=software
Home of Ethernet and SD/MMC Bootloader for PICs!!

#11 kenk

kenk

    Newbrie

  • Members
  • 3 posts

Posted 25 April 2007 - 05:25 PM

Hello Emte,
The bottleneck is the SPI that connects the ENC28J60 and possibly more than one FRAM IC or other storage device. It is difficult enough to deal with the ISR issues for SPI, etc., but to have multiple devices on the SPI and having to sort this out in an ISR (taking more time in the ISR), is not a good hardware design. I spent two years trying to get the Rabbit based module to work right. Support was not the greatest and the Forum was not as helpful as we would all like Forums to be. I did two designs, first, with a buffered 9-bit UART (Oxford Semi, if I remember correctly), and second, with dual ported memory (Cypress) between a PIC and a Rabbit. Complex, large amount of PCB space, clunky, and everything else. Still, I would not discourage others to try this approach. Everyone should try their ideas, that is how we learn from experience.

The ICE2000 is not like the ICD2 at all. The ICE2000 is based on a 'bondout part' and does not suffer from programming into Flash, time to detrmine register values, etc. Most importantly, for complex code, it had code tracing ability. So this is why we also developed a ICD2 Adjunct, for doing 3-instruction macro code tracing. Anyone who would SERIOUSLY like to know how this is done, can see the attachment I left on the Microchip ICD2 website. Oh well, there was no real interest their eventhough the attachment is a very detailed functional design description. I recommend that you check on how the code tracing works on the Real Ice. We (the user community) should do all we can to help ourselves in developing hardware and software tools.

We should probably just let this thread terminate or go offline because we are getting into discussion areas that really do not belong on this or any other Forum.
kenk

#12 emte

emte

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 378 posts
  • Location:Victoria, BC, Canada

Posted 25 April 2007 - 05:30 PM

i have a 12F675 pushing udp via the enc28j60...

In the fight to strip down the stack and still have it usable
i have no idea how its actually working. it sits in the corner
and i cover my eyes as i walk by so i do not scare it.

i had started a very small MAC implementation pre-BoostC++
release. But on reflecting what i was doing, tossed the code
and now plan to retry in C++, which is better suited for it.

First things first though, i have to finish an RF manchester
implementation ( which is actually fairly close in structure,
just different controller hardware)

Edited by emte, 25 April 2007 - 05:32 PM.

Good intentions always exist, intelligent thought patterns ... not quite as much

Are you linked in?

#13 asmallri

asmallri

    Enthusiast

  • EstablishedMember
  • PipPip
  • 169 posts
  • Location:Western Australia

Posted 25 April 2007 - 05:58 PM

i have a 12F675 pushing udp via the enc28j60...

In the fight to strip down the stack


Impressive that you did this with the MCHP stack and a possible sign of craziness :-)
Regards, Andrew

Need a file system? http://www.brushelec...p?page=software
Home of Ethernet and SD/MMC Bootloader for PICs!!

#14 emte

emte

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 378 posts
  • Location:Victoria, BC, Canada

Posted 25 April 2007 - 06:03 PM

i have a 12F675 pushing udp via the enc28j60...

In the fight to strip down the stack


Impressive that you did this with the MCHP stack and a possible sign of craziness :-)

<{POST_SNAPBACK}>



Yeah, i will conceed that. Concidering it was with the last verion of the stack
of which Microchip had 6 "copies" of across thier site and only 2 of which worked.
Good intentions always exist, intelligent thought patterns ... not quite as much

Are you linked in?

#15 tom 2007

tom 2007

    Regular

  • EstablishedMember
  • Pip
  • 58 posts
  • Gender:Male

Posted 05 June 2011 - 11:18 AM

I've been busy porting TCP/IP from Microchip to boostc for quite some weeks now. Finaly it seems to be working quite well. If anyone is still interested in this i've uploaded an example project here: PIC18F27J53Ethernet.zip.

This example uses the PIC18F27J53,ENC28J60 and 23K256 chips connected with a 6MHz SPI bus.

Code compiles into +/- 45000 bytes (takes lot of time :rolleyes: ) most of it is based on the Microchip TCP/IP stack examples.
Code includes:
-ENC28J60 "driver"
-IP
-TCP (client & server)
-UDP
-ARP
-DHCP client
-DNS client
-very basic http server that supports http GET method and urls with parameters
-very basic http client that can download small http files into the sram module
-http server example
-UDP example
-TCP client example
-max 5 UDP sockets and 5 TCP sockets (1500 Bytes of RAM used)

Edited by tom 2007, 05 June 2011 - 11:25 AM.


#16 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 22 June 2012 - 04:28 PM

Hi Tom. Doing some searching I came by this. Would be aviailable to assist integrating this with my current project.

Ondra

#17 tom 2007

tom 2007

    Regular

  • EstablishedMember
  • Pip
  • 58 posts
  • Gender:Male

Posted 23 June 2012 - 03:31 PM

To implement to an existing project:

First make sure your PIC has enough ROM because the project can get really BIG (50K or more). I've used the PIC18F27J53 because it has 128KB ROM, runs at 48MHz and is available in SMD & DIL package.

Then download & extract the files from the example.
-Add the files in the 'stack' folder to your project.
-add stackconf.h to your project.
-Take a look at the schematic (pdf file).

Normaly you only need to change the stackconf.h file to make everything work with your project.
Here you need to define some settings for things like the chip select of the ENC28J60, SPI read/write functions, how the TCP stack code can access external SRAM, ram size, ...

Any more questions please ask.

Edited by tom 2007, 23 June 2012 - 03:32 PM.


#18 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 25 June 2012 - 02:10 AM

First of all; Thanks Tom.

I spent time this weekend trying to get the piceth._c project to compile. As it is, it did not compile. Going through the files I made changes to the

#pragma config list to accommodate the target and crystal I have on my current setup. Again when tried to build the project it failed. A major compile

issue I keep running into is: "piceth.c(71): error:" in the piceth.c file their is no code on line 71:
I am using the latest version of Sourceboost. Have you tried to compile the project using that version, and should I be using another older version?

Currentl I have an existing project with a setup consisting of:
PIC18F6722
10MHz crystal set to HS PLL
I have a ENC28J60 ethernet module connected to the first spi1 port
I have a 24LC512-I/SN EEPROM 512KBIT 400KHZ 8SOIC connected to the second spi2 port
My current project was created using FLOWCODE IDE.

Using the information above could you guide me on the changes need to get the current test file included with the project, up and running?
If you don't have the time could you assist me in finding someone who can?

Thanks in advance.

dra

Building...
"C:\Program Files\SourceBoostC IDE\SourceBoost\boostc_pic18.exe" piceth.c -t PIC18F6722 -idx 1 -O2 -obj Release -d _RELEASE
"C:\Program Files\SourceBoostC IDE\SourceBoost\boostc_pic18.exe" spi.c -t PIC18F6722 -idx 1 -O2 -obj Release -d _RELEASE
piceth.c(71): error: failure
2> 2> BoostC Optimizing C Compiler Version 7.10 (for PIC18 architecture)
2> http://www.sourceboost.com
2> Copyright© 2004-2012 Pavel Baranov
2> Copyright© 2004-2012 David Hobday

#19 JorgeF

JorgeF

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 274 posts
  • Gender:Male
  • Location:ES @ Europe, third rock from the Sun

Posted 25 June 2012 - 09:48 AM

Hi


Out of curiosity, I downloaded the project and tried a full build.
It didn't even start to compile, I had to correct the project file ".__c" and changed the Sourceboost install path to mine.

Then it failed in the main 'c' file because of the "#pragma DEBUG" configuration.
Removed that and it all compiled and build with no more fuss.
And it was not that slow either, a full rebuild took a little less than 5 mins (2 min compile <3 mins link).


About the "DEBUG" configuration, I found it strange that it is not available, because the fuse does exist (AFA datasheet Knows).
Its true that Microchip states that this fuse is used by their ICD tools and should not be activated by user code.
Maybe thats why it is not made available by BoostC.

I used Sourceboost IDE 7.05 with BoostC 7.05 (Pro licence), running on a 32bit version Windows Vista Hoem Premium.


Best regards
Jorge

Edited by JorgeF, 25 June 2012 - 09:50 AM.


#20 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 25 June 2012 - 12:00 PM

Thanks Jorge. If you don't mine could you detail the changes you had to make in the ._c file.

Ondra

#21 JorgeF

JorgeF

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 274 posts
  • Gender:Male
  • Location:ES @ Europe, third rock from the Sun

Posted 25 June 2012 - 12:14 PM

Hi

Thats not much to it, but here it goes.

I opened the "piceth.__c" file with notepad++ and changed the following settings:

[Settings]
Active Directory=C:\Users\Tom\Documents\pic\ethernet\
Target=PIC18F27J53
................
[Tools]
BoostDir=D:\program files\SourceBoost\
................


I just replaced the paths with the correct ones for my installation, thats all.
You can do the same or use the IDE to build a new project.
I prefer to edit this by hand cause it allows me to retain all the other project options like compiler/linker directive and so.


But I don't think your problem lies here.
Based in your post above, I think that its a question of having chamged the target device adn possibly some clash bettwen flow code libs and this tcp/ip stack.
Did you notice that line 71 in the piceth.c is the line including the definitios for the external static RAM?
By your description it seems that your project uses external EEPROM and not SRAM.
Probably this won't even work because EEPROM lakes the speed to receive ethernet data packets.

There are probably a few definitions that might need adjustements to the new device.
And after that lots of small adjustements in code to make it compatible with the ready made modules that Flow Code relies on.


Best regards
Jorge

Edited by JorgeF, 25 June 2012 - 01:41 PM.


#22 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 25 June 2012 - 01:52 PM

Thanks again.
Going back to the original file. I downloaded then saved to a different directory. Made the changes you described to the piceth__.c file. Compiled and got the #Debug error. I removed the debug config. Build and compile. Then I got the following error. Looking at the error location. The code looks fine.
Any Ideas on this.

Building...
"C:\program files\SourceBoostC IDE\SourceBoost\boostc_pic18.exe" piceth.c spi.c sp.c SRAM.c rtc.c stack\stackmain.c stack\eth\ENC28J60.c -t PIC18F27J53 -idx 1 -O2 -obj Release -d _RELEASE
"C:\program files\SourceBoostC IDE\SourceBoost\boostc_pic18.exe" stack\IP.c stack\UDP.c stack\nbns.c stack\ICMP.c http.c stack\DHCP.c stack\DNS.c -t PIC18F27J53 -idx 1 -O2 -obj Release -d _RELEASE
piceth.c(285:7): error: unknown identifier 'j'
piceth.c(285:7): error: invalid operand 'j'
piceth.c(285:8): error: failed to generate expression
piceth.c(285:8): internal error: failed to generate 'for' expression
piceth.c(287:7): error: unknown identifier 'j'
piceth.c(287:7): error: invalid operand 'j'
piceth.c(287:8): error: failed to generate expression
piceth.c(287:8): internal error: failed to generate 'for' expression
2> 2> BoostC Optimizing C Compiler Version 7.10 (for PIC18 architecture)
2> http://www.sourceboost.com
2> Copyright© 2004-2012 Pavel Baranov
2> Copyright© 2004-2012 David Hobday

2> Licensed to Ondra Simons under Single user Full License for 1 node(s)
2> Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only


1> 1> BoostC Optimizing C Compiler Version 7.10 (for PIC18 architecture)
1> http://www.sourceboost.com
1> Copyright© 2004-2012 Pavel Baranov
1> Copyright© 2004-2012 David Hobday

1> Licensed to Ondra Simons under Single user Full License for 1 node(s)
1> Limitations: PIC18 max code size:Unlimited, max RAM banks:Unlimited, Non commercial use only


2> stack\IP.c
2> stack\UDP.c
1> piceth.c
2> stack\nbns.c
2> stack\ICMP.c
2> http.c
2> stack\DHCP.c
2> stack\DNS.c

2> success
error: failed
Failed to locate output file 'Release\piceth.hex'
Done

Failed

#23 tom 2007

tom 2007

    Regular

  • EstablishedMember
  • Pip
  • 58 posts
  • Gender:Male

Posted 25 June 2012 - 06:27 PM

Can you check if the variable j is declared?

#24 JorgeF

JorgeF

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 274 posts
  • Gender:Male
  • Location:ES @ Europe, third rock from the Sun

Posted 26 June 2012 - 08:15 AM

Hi

I think I know what is happening.

There is a declaration for the variable "j" a few lines before this error.
That declaration is inside a for loop.
This poses a scope question that has been debated in this foruns not long ago.
http://forum.sourceb...?showtopic=5052.

My BoostC 7.05 is accepting that declaration in the scope of the function, so after the loop where it is declared its available also for the remaining of the function.
But Dra is using the new version 7.10.
I supposed that the scope question has been sorted out and the "j" variable goes out of scope when the loop where it is declared finishes. So its not available for the second loop, thus firing the compiler error.

The solution is to redeclare it in every loop where it is used.
It can also be declared it at function level, but that would be less eficient.


Best regards
Jorge

Edited by JorgeF, 26 June 2012 - 08:16 AM.


#25 JorgeF

JorgeF

    Super Enthusiast

  • EstablishedMember
  • PipPipPip
  • 274 posts
  • Gender:Male
  • Location:ES @ Europe, third rock from the Sun

Posted 26 June 2012 - 08:53 AM

Hi

Just confirmed my theory above.
After a quick and dirty installation of Sourceboost 7.10 RC, the same error of an undeclared "j" variable stokr.
The correction was to add the "unsigned char " declaration in the two loops where it was missing.


Best regards
Jorge

#26 tom 2007

tom 2007

    Regular

  • EstablishedMember
  • Pip
  • 58 posts
  • Gender:Male

Posted 26 June 2012 - 04:51 PM

Yes that's possible. It was written like that because in the 7.05 version I got the error "variable 'j' already declared" that's why I removed the declaration in the second loop.

So to Dra:
At line 283 change the code:
for (unsigned char j=0;j<250;j++) SomeData[j]=j;
sram_write(0,SomeData,250); //write data
for (unsigned char j=0;j<250;j++) SomeData[j]=0;
sram_read(0,SomeData,250);
for (unsigned char j=0;j<250;j++){
  if (SomeData[j]!=j){
   serial_send_string("Error address: ");
   serial_send_hex(j);
   serial_send_string("\r\n");
  }
}

Also you will need to add a serial RAM (23K256) if you want to use TCP connections. The EEPROM can be used for storing settings like the IP address and firmware updates.

Edited by tom 2007, 26 June 2012 - 04:56 PM.


#27 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 27 June 2012 - 01:21 PM

I think am feeling the love here guys.
Thanks, I give it a go today.

Ondra

#28 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 24 September 2012 - 10:27 AM

Good day Tom and Jorge.
I have a board that uses the 18f6722 device. Trying to compile using this device I got the following errors listed below.
Could you give some guidance on the changes needed to get the code to work with my set up. On my board I have the
chips hardware spi connected to the SRAM and ENC28J60 module. Thanks in advance.



spi.c(13:2): error: unknown identifier 'rpinr21'
spi.c(13:2): error: invalid operand 'rpinr21'
spi.c(13:9): error: failed to generate expression
spi.c(13:13): error: unknown identifier 'rpinr22'
spi.c(13:13): error: invalid operand 'rpinr22'
spi.c(13:20): error: failed to generate expression
spi.c(13:25): error: unknown identifier 'rpor10'
spi.c(13:25): error: invalid operand 'rpor10'
spi.c(13:31): error: failed to generate expression
spi.c(13:36): error: unknown identifier 'rpor9'
spi.c(13:36): error: invalid operand 'rpor9'
spi.c(13:41): error: failed to generate expression

.

rtc.c(20:67): error: unknown identifier 'TMR3CS1'
rtc.c(20:67): error: unexpected '.' operator
rtc.c(20:61): error: failed to generate expression
rtc.c(20:61): error: invalid operand 't3con.TMR3CS1'
rtc.c(20:74): error: failed to generate expression
rtc.c(20:84): error: unknown identifier 'TMR3CS0'
rtc.c(20:84): error: unexpected '.' operator
rtc.c(20:78): error: failed to generate expression
rtc.c(20:78): error: invalid operand 't3con.TMR3CS0'
rtc.c(20:91): error: failed to generate expression

.......................................................................

IPtest.c(410:2): error: unknown identifier 'ancon0'
IPtest.c(410:2): error: invalid operand 'ancon0'
IPtest.c(410:9): error: failed to generate expression
IPtest.c(411:2): error: unknown identifier 'ancon1'
IPtest.c(411:2): error: invalid operand 'ancon1'
IPtest.c(411:9): error: failed to generate expression
IPtest.c(412:2): error: unknown identifier 'cm1con'
IPtest.c(412:2): error: invalid operand 'cm1con'
IPtest.c(412:9): error: failed to generate expression
IPtest.c(413:2): error: unknown identifier 'cm2con'
IPtest.c(413:2): error: invalid operand 'cm2con'
IPtest.c(413:9): error: failed to generate expression
IPtest.c(414:2): error: unknown identifier 'cm3con'
IPtest.c(414:2): error: invalid operand 'cm3con'
IPtest.c(414:9): error: failed to generate expression
IPtest.c success

failure

#29 Dra

Dra

    Regular

  • EstablishedMember
  • Pip
  • 24 posts

Posted 24 September 2012 - 03:33 PM

From the guys at flowcode. Could you add any further insite to this? Thanks in advance.


spi.c(13:2): error: unknown identifier 'rpinr21'



The 18F6722 does not have remappable peripherals, they are fixed in place, so you can safely comment out all of these lines of code.


rtc.c(20:67): error: unknown identifier 'TMR3CS1'



The 18F6722 also does not have a RTCC peripheral so is there any way to remove these functions from the program. Does the program need RTCC functionality?


IPtest.c(410:2): error: unknown identifier 'ancon0'



The final set of errors seem to relate to the ADC and Comparator peripherals. Again are these actually required, Could you replace these with say a Flowcode ADC component which will automatically switch in the correct code for your device?

#30 tom 2007

tom 2007

    Regular

  • EstablishedMember
  • Pip
  • 58 posts
  • Gender:Male

Posted 24 September 2012 - 05:20 PM

1) rpinr21 is something special for the PIC18F27J53. If you use another PIC you'll need to adjust this:
in the config.h you change the "#define spi_port2_conf " to something suitable for your application. Actually you just need to make sure the spi_init() functions initialize the SPI module of your PIC (you can change the function so it works with your PIC).

2) you don't need the RTCC peripheral (the rtc.c code doesn't use it). I've used timer timer 3 for generating a second and tick counter on the PIC. The rtc.c file holds a variable that tells the ammount of seconds passed since reboot (or since 1970) and a variable that holds the total number of clock cycles since reboot. I guess your PIC doesn't have a timer #3 so you'll have to use another one. It's important for TCP.c and some other stack functions to calculate timeouts.
rtc_get_time() //must return number of seconds since reboot (or since 1970 if you are able to sync it in some way).
rtc_get_tick() //number of clock ticks since reboot
rtc_get_tick_div256() //same as above but devided by 256
rtc_get_tick_64k() //same as rtc_get_tick() but devided by 0x1000

3) you can remove the ADC/comparator related stuff for my application it was needed to turn it off in order to make some pins of the chip to work as input or output (check datasheet).

Edited by tom 2007, 24 September 2012 - 05:23 PM.




Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users