Recursion in the Wiznet I/O library

[allenhuffman]

I am in the process of porting the current Wiznet library over:

https://github.com/Wiznet/ioLibrary_Driver/tree/master

We had a port done a few years ago, and I've been replicating the steps we made to do that. But, new functions have been added, new chip(s) supported, etc. so there are some differences.

Now when I build, I am getting recursion warnings:

[Ttelmah]

I think that is just a call to reg_rd. So possibly look at this, Problem is that
the issue could be something in how you are loading the library, and/or
how you have adapted it. Look carefully at all names used in it for something
like a CCS reserved keyword, or something that is just being loaded in the
wrong order.
As has been pointed out here before (many times), the problem is that
the CCS error checking has a nasty habit at erroring at something that
is not actually the fault many lines after what is actually wrong. It's parser
gets confused and carries on reading and getting more confused, until it
eventually displays an error. So I'm afraid you have a lot of diagnosis to do,

[jeremiah]

Also keep in mind that by default, the CCS compiler is not case sensitive, so you'll want to use

[allenhuffman]

I've been burned by that so much now #case is the first thing I add ;-) It baffles me that this is not a default. There is a union in Wiznet called "IF" and that won't work without #case.

I checked the functions and they seem identical to the version we ported a few years ago, but other routines have changed. The burst read/write has default "if 1" code that calls the byte routines in a for/next loop, for example. Seeing core things like that change really makes me wish we had checked in the raw files before modifying them so I could see what was done originally.

I'll be back at this on Monday and hopefully figure something out. I already diff'd the wiznet_conf.c/.h to update our changes in the new one, but there is a lot of stuff added in the new one (including support for chips that did not exist a few years ago, it seems). Maybe with a fresh eye this week I will spot something and be able to fix it.

Thanks, much.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002.

[Ttelmah]

If nothing has changed in the part erroring, it suggests it is something
in part of the earlier code triggering the error.
Thoughts:
Stream names?
Variables?.

It suggests something in your code setting up to use this, might contain
something that now clashes with the re-written newer code.

I see you remembered that old function using pointers oddity. I remember
the thread about that when you originally met this. That is an oddity
that really should have been fixed by CCS in the meantime. Worth pointing
this out to them, when you have a moment.

[jeremiah]

[allenhuffman]

Seeing changes to the core wiznet_conf files makes everything suspect. We've never ported these, only the ones from years earlier.

Back then, I did drop in the httpServer.c files and did a test with them, and have no recollection of having to do anything to those files to make it work.

But there are hundreds of changed lines in the core files, so likely there is more porting to do. As soon as I add #recursive of whichever the keyword is, I get a different set of errors.

I am back in the office today and will be doing more testing.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002.

[allenhuffman]

I have successfully gotten the "register" functions to work so I can pass in our own functions and it will use them.

But man, is it picky. Something got bumped and I spent an hour fighting a compiler error. Ended up re-making the CCS project and then it worked again. Weird.

I'll make a topic to share tidbits when I get this done. Working on the httpServer code now.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

Using: 24FJ256GA106, 24EP256GP202 and 24FJ64GA002.