Skip to main content
Topic: New uIP code features (Read 41841 times) previous topic - next topic

Re: New uIP code features

Reply #15
VA7DB wrote to inquire about the announce feature on the Microchip stack. I'm going to try to add an announce compatible server to uIP because it is a nice feature. I have a DHCP client I wrote a few years ago that might be good to add at the same time.
Got a question? Please ask in the forum for the fastest answers.

Re: New uIP code features

Reply #16
[quote author="Trev"]
... the uIP stack fails to initialise (ie it hangs immediately after "timer init" and a blank line) if I use the reset button or after a firmware upload. The heartbeat LED is on solid. The only way to get it to work is to remove the power and then it's fine.
[/quote]
Hmm, that doesn't happen here, but after "timer init" is printed, SDInit is called...so it's something in there causing it to hang.

I have spotted a bug in there where it sets the SPI Primary and Secondary pre-scalers (or rather, where it's NOT setting them) that's causing the transfers to and from the card to be clocked at 64kHz, instead of the >100 and < 400 kHz that the spec says should be used for the card initialisation. Once the initalisation is done, the spec says we can step up to 25MHz (but I think the PIC will only go to 10MHz). I've got that change locally, and it improves the SD card performance hugely (as you'd expect). I'll commit that as soon as I can.

Failing that, I'll have to modify the initialisation routine to  "give up" after a set number of attempts, and report the error. That should help track it down. I guess we'll need that anyway for people using this without an SD card inserted.

Thanks for giving it a go.
Tony.

Re: New uIP code features

Reply #17
Not really, for me it works just fine without a SD card inserted. So I modified some other parts of the code, I did not touch dosFS.

Thank you for putting your version of the uIP port for the WebPlatform up on the DangerousPrototypes SVN repository ... it's an interesting alternative to the Microchip TCP/IP stack :)

Re: New uIP code features

Reply #18
Hello everyone,

I bought the web-platform a few months ago, and i was trying the new features of the UipStack
software by downloading the SVN project (r316), building it and download it into web-platform
hardware. Everything went fine, except one thing, the RTCC clock won't run. See below:

Web platform telnet. Enter help for commands.
>
>time
RTCC Date/Time: 2010-05-16 15:34:00
>
>time
RTCC Date/Time: 2010-05-16 15:34:00

My question is, can this be a hardware problem, or is it something in this revision R316 of the uipstack, so other people
faces the same problem.

Re: New uIP code features

Reply #19
I have observed the same (I changed date/time in my code to 2010/06/20 - 15:33, so don't get confused by my screenshots above). I don't think it's a hardware problem ... the time is set to a valid date during init in main.c:

Code: [Select]
int main(void){

InitHardware();
rtcc_init();

//TODO: set some sensible rtcc defaults until we can do NTP
struct tm time;
time.tm_year = 2010 - 1900;
time.tm_mon = 5;
time.tm_mday = 16;
time.tm_hour = 15;
time.tm_min = 34;
time.tm_sec = 0;
time.tm_wday = 0;
rtcc_set_tm( time );
...

but will not update for some reason. I haven't bothered to look into this and the specific part of the code (hardware/rtcc.c) yet.

Since I have no web platform where I am right now, I can't check if the RTC crystal is populated or not. Maybe our units shipped without the RTC crystal ... check if Q2 (32.768khz crystal) is populated before looking into the code as the RTC requires the external 32.768khz clock crystal!

Re: New uIP code features

Reply #20
Also check that Q2 is the correct orientation. Seeed said that some might have gone out with a backwards crystal, but as far as I can tell it never actually happened. The boards they inspected were ok, they just weren't 100% sure a few of the first 20-30 boards were right because they already shipped. Most should be ok, but it's definitely something to check.
Got a question? Please ask in the forum for the fastest answers.

Re: New uIP code features

Reply #21
Hello everyone,

Thank you for the tip to check the 32k crystal Q2.
And indeed after checking the spechttp://cfm.citizen.co.jp/english/crystal/xdcr/CM200C_250C.pdf
the device was mounted in the wrong position. I will try to remove Q2 and replace it
in the right position, hopefully the web-platform is not damaged by this issue.
SMD soldering is not something for me, but anyway thank you all.
 
Greetings from Holland

Re: New uIP code features

Reply #22
Ian lives in Holland, too ... not that it is up to me to point you in his direction  ... but I think he might be willing to swap/turn the oscillator around for you ... I would do it too, but I live in Germany ;)

You could contact Seeed as well as they assembled the web platforms ... or you take this as an opportunity and get yourself a pair of tweezers - they are a "must have" gadget if you get into prototype SMD soldering/modding.

I will get my fingers on my web platform a little later and check if the crystal is the source of the same problem I have encountered.

/EDIT/ Mounting the crystal unit the wrong way around should not damage the PIC, it will just not provide the oscillating signal.

Re: New uIP code features

Reply #23
Ah, so that's why the discussion about crystal orientation!!
I was certain that crystals were non-polarised components, and that is true; it's the pinout of the 4 pins on the package the crystal is in that makes the orientation important. (the two pins at one end of the package don't connect to the crystal internally)

Thanks for the link to the datasheet. Hope you're able to get it working. Currently, the RTCC half-second interrupt is used for the uIP periodic processing, so if the RTCC isn't running, the periodic processing won't either.

Tony.

Re: New uIP code features

Reply #24
The web platform I used for playing around with the uIP stack had the 32.768kHz crystal mounted the wrong way around as well! After taking Q2 off and putting it back on with the correct orientation the RTC works now. :)

Re: New uIP code features

Reply #25
I had a backward crystal, we will see if I can switch it.  Is the currently checked in code stable?  Any comments on how to properly build it?

I broke down and got a pickit 3 so programming it will not be an issue, if I can figure out the right build.

Re: New uIP code features

Reply #26
Okay I set the IP address staticly so I can now telnet to the board.

So I can build and load.  Now questions.
Is there an http server yet ported?  (I have little desire to bring one up if it already has been done.)  Ultimately I want to get a substuting sd card based server that can blink lights and read switches.

Any pointers into where to go next would be appreciated.

Re: New uIP code features

Reply #27
There isn't an HTTP server for the uIP stack yet, but there are a bunch of open source embedded server projects that implement a full or partial HTTP server. It looks like they have a new version since I last saw it, with a bunch of new features and good documentation:
http://www.tuxgraphics.org/electronics/ ... tack.shtml
Got a question? Please ask in the forum for the fastest answers.

Re: New uIP code features

Reply #28
[quote author="ian"]
There isn't an HTTP server for the uIP stack yet, but there are a bunch of open source embedded server projects that implement a full or partial HTTP server. It looks like they have a new version since I last saw it, with a bunch of new features and good documentation:
http://www.tuxgraphics.org/electronics/ ... tack.shtml
[/quote]

Ian, that is a VERY useful link, thank you. I roll my own AVR + ENC28J60 boards for projects, and that's the 3rd source of code I've found for it, and they all seem to be based off the same thing - its amazing how code travels.

For anybody else interested:

The first code I used was from http://www.nuelectronics.com/estore/?p=12 and is horribly basic

Second code from here (v1.1) http://blog.thiseldo.co.uk/?p=344 and is pretty good, and seems to be based on an older version of the code from the link Ian gave

However http://www.tuxgraphics.org/electronics/ ... tack.shtml does indeed have newer versions and features :)

Must give it a try...

Nick

Re: New uIP code features

Reply #29
@coolnicks:  Did you manage to get a port of a reasonable http server up for the web platform? 

I have to decide whether it is time to break down and do one, or figure out how to get the original closed source server to work for my needs?  I have a couple of applications I need to finish up and this is an obvious platform to use as I already have a few.  I just don't really feel enthused about debugging a complete port from scratch.  The time I have available is already over allocated and if someone is actively got one up, or did it in the past that would be a better starting point than an AVR source.   I would prefer to use an open source one, or maybe this is a good excuse to play with the new development system on my mac.  I guess I could try MPLabx on the mac with the old sources.   So I am open to suggestions as to which way to go?