Dangerous Prototypes

Other projects => Past projects => Web platform => Topic started by: bonybrown on June 01, 2010, 03:04:40 pm

Title: New uIP code features
Post by: bonybrown on June 01, 2010, 03:04:40 pm
Hi all,

Just dropped another update to the uIP stack project to svn/trunk/web-platform/firmware/uIPStack.
Some notable changes are:

Some FYIs:
The IP address is fixed in code as 10.0.0.251. You'll need to change as desired.
Lots of debug stuff still being printed to the serial port at 115200 (8/1/none)

Good luck!
Tony.
Title: Re: New uIP code features
Post by: will_j on June 01, 2010, 10:41:56 pm
Great! but... Just tried this and two comments:

1) The serial debug messages don't sent a carriage return, only a line feed, so hard to read (I'm using Tera Term)
2) Telnet doesn't appear to echo anything back - errors in serial console:

app: connected. Ports 5888:-11004
echo: connect from 000a0100
echo: using handle 0app: newdata. Handle: 0. len=16
echo: file state 3
echo: event 1
echo: can_read 16 @ 15f8
echo: seek 0
echo: not_found seek 16

I typed 'h' - was starting to type 'help'
Title: Re: New uIP code features
Post by: bonybrown on June 02, 2010, 12:10:09 am
Ah!
Well see I'm a linux user so the linefeeds are sufficient. I hadn't thought of that. It should be a simple matter to do a bulk replacement of n with rn (or nr...I'm not sure which way round they should go )

And that probably also explains the second one - my telnet uses line mode and seems to do local echo automatically. It doesn't send the data to the device until you hit "enter", so I didn't echo back what was sent. The messages you see in the console aren't errors; just debugging stuff ( I don't have a picKit or anything like that - it's all just printf statements for debugging )

And thinking about how the parser works now, it's probably not going to work in 'one character at a time' mode. To be honest, I'm not really happy with that part of the code, so I'll have to revisit it. If you can set your telnet to line mode, it should work (if that's any consolation?)

But good feedback, thanks!
Title: Re: New uIP code features
Post by: Sjaak on June 02, 2010, 09:20:45 am
rn seems to be the common, but both should work.

There was a topic about the telnet server from microchip, in which some bugs were revealed when using different clients. ( http://dangerousprototypes.com/forum/in ... opic=501.0 (http://dangerousprototypes.com/forum/index.php?topic=501.0) ) Dunno if it helps.
Title: Re: New uIP code features
Post by: bonybrown on June 02, 2010, 11:51:23 pm
Thanks Sjaak, I'll keep that thread in mind (note that my implementation doesn't require you to "logon" at all at the moment)
Hopefully I can do some telnet option negotiation soon, and that should help improve the interoperability.

An improved telnet task was committed to svn about 10 hrs ago. It now echos ( annoyingly if your client is in character, local echo mode) and added a new command "paramcheck" as a demo of how to read parameters for commands from the line it "executes".

Todos: option negotiation for echo and line/char mode; support for backspace character in char mode; then adding some useful? commands. I have these in mind: settting the date/time; configuring ip address, mask and gateway and storing those to the flash memory chip...and of course reading them and setting up uIP on startup. Might be good to be able to set the mac address too.
Title: Re: New uIP code features
Post by: dpropicweb on June 03, 2010, 12:51:39 am
[quote author="bonybrown"]
Hopefully I can do some telnet option negotiation soon, and that should help improve the interoperability.
[/quote]

Don't waste your time on the Windows default telnet.exe - you can't get it out of char-by-char mode. It only supports the following operating parameters:

    *     WILL AUTH (NTLM Authentication)
    *     WONT AUTH
    *     WILL TERM TYPE
    *     WONT TERM TYPE
    *     LOCALECHO off
    *     LOCALECHO on

Yep, pretty much a broken client and lost cause.
Title: Re: New uIP code features
Post by: bonybrown on June 03, 2010, 05:08:59 am
Thanks for the tip Trev.
If I can get the echo state stored out, it will work sufficiently, except for the backspace key at the moment.
Title: Re: New uIP code features
Post by: will_j on June 03, 2010, 09:22:49 pm
Neat stuff.

I tried Tera Term Pro, Putty, Hyper Terminal and windows Telnet, with original code - non work properly, even if I send help, I get nothing back.
 But - Linux telnet works fine - as you expected!

Keep up the good work, once a windows telnet is working, I will try adding a 'read_adc' command for my MAX147 demo!

Thanks,

Will
Title: Re: New uIP code features
Post by: bonybrown on June 14, 2010, 11:45:59 am
Trev, good advice about using a packet sniffer for the telnet traffic. I used wireshark and it even decoded the telnet options being passed back and forth, so that helped a lot.

So the telnet server has now been updated.
I've tested it with linux, windows and mac clients ( all the OS standard "telnet" commands) and it works fine, all in character at a time mode, ie, lowest common denominator.

I've added a new command as well : [tt:]memdump [address] [count][/tt:] which will dump the memory from [address] to the telnet client. Here's a sample session:
[tt:]tony@barellan:~$ telnet 10.0.0.251
Trying 10.0.0.251...
Connected to 10.0.0.251.
Escape character is '^]'.

Web platform telnet. Enter help for commands.
>help
Configured commands:
help
echo
time
quit
memdump
>time
RTCC Date/Time: 2010-05-16 23:16:12
>memdump 0x1400 64
1400    ce de 42 9d 6f 64 f8 f5 ..B.od..
1408    d0 a6 6b f7 a3 e1 4a ad ..k...J.
1410    44 3c 4c d4 9f 07 9c 0b D1418    72 78 95 ba a9 bc 26 fa rx....&.
1420    4e fe e7 7a 56 65 7a 83 N..zVez.
1428    0b 75 a7 39 a6 0e f4 f9 .u.9....
1430    f0 c5 d3 27 74 a9 b1 7f ...'t...
1438    30 5a 90 03 1c 47 0a 6d 0Z...G.m
>quitConnection closed by foreign host.
tony@barellan:~$[/tt:]

For those interesting in implementing commands for telnet, the signature of the function you would need to implement is now:
[tt:]void telnet_command( file_handle_t handle, char** argv, unsigned int argc )[/tt:]
That is, almost exactly like a standard 'c' main(), except the return type is void, and the file handle for the tcp connection is passed in for your command to read and write from. The parameters to the command are already parsed and presented in the char* array argv, with argc items. argv[0] is the command name. argv[1] is the first param.

Regards,
Tony
Title: Re: New uIP code features
Post by: ian on June 14, 2010, 11:54:10 am
Very nice! I might have to implement a telnet Bus Pirate using the new code :)
Title: Re: New uIP code features
Post by: Sjaak on June 14, 2010, 06:02:41 pm
[quote author="ian"]
Very nice! I might have to implement a telnet Bus Pirate using the new code :)
[/quote]

Don't make it multiuser ;) Could be fun to 'help' collegaes ;)
Title: Re: New uIP code features
Post by: bonybrown on June 16, 2010, 02:30:25 pm
Another new feature: you can now read files and list directories from the SD card.
I've added the 'cat' and 'ls' commands to the telnet server (I guess that's 'type' and 'dir' to the windows' folk)

There's also a 'sddump' command that will dump sectors from the sd card in the same way that  memdump dumps memory, for troubleshooting.

Writing files is as yet untested (and there's no telnet commands that do any writing yet, anyhow), but the dosfs library does support it.

Would be good to know if it works with other people's SD cards.

Regards,
Tony.
Title: Re: New uIP code features
Post by: ian on June 16, 2010, 03:11:17 pm
I noticed you used DosFS, did it work ok for you? As I recall, there were several things I had to fix the last time I used DosFS on PIC. I had been looking at this FAT stack for a future project:
http://dangerousprototypes.com/2010/04/ ... d-library/ (http://dangerousprototypes.com/2010/04/05/mmcsdsdhc-card-library/)
Title: Re: New uIP code features
Post by: bonybrown on June 17, 2010, 01:05:32 am
I took the existing code from the dangerous prototypes SVN, so maybe I already have your fixes?

That code didn't work at first, but that was due to the SPI interface. I see lots of code that doesn't bother to read SPIBUF after a write, but on the dsPIC, doing that will lock up the SPI due to the receive overflow bit being set - so maybe that's a dsPIC specfic thing?

Once that was sorted out, I didn't seem to have any problems. Maybe I'll hit problems when I start looking at writes?
Title: Re: New uIP code features
Post by: dpropicweb on June 17, 2010, 02:22:42 pm
[quote author="bonybrown"]
Would be good to know if it works with other people's SD cards.
[/quote]

Kingston 4Gb

Code: [Select]
>ls /
Error finding partition start

>sddump 1
Error reading sector. Response code:01

A small amomaly that took me a while to figure out: 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.
Title: Re: New uIP code features
Post by: ian on June 17, 2010, 04:49:14 pm
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.
Title: Re: New uIP code features
Post by: bonybrown on June 18, 2010, 02:11:37 am
[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.
Title: Re: New uIP code features
Post by: IPenguin on June 21, 2010, 07:46:18 am
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 :)
Title: Re: New uIP code features
Post by: wimbouwh on July 10, 2010, 04:43:26 pm
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.
Title: Re: New uIP code features
Post by: IPenguin on July 10, 2010, 05:54:32 pm
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!
Title: Re: New uIP code features
Post by: ian on July 10, 2010, 07:58:24 pm
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.
Title: Re: New uIP code features
Post by: wimbouwh on July 12, 2010, 09:42:34 pm
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 (http://http://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
Title: Re: New uIP code features
Post by: IPenguin on July 12, 2010, 10:20:02 pm
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.
Title: Re: New uIP code features
Post by: bonybrown on July 13, 2010, 03:59:56 am
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.
Title: Re: New uIP code features
Post by: IPenguin on July 14, 2010, 07:43:59 am
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. :)
Title: Re: New uIP code features
Post by: rhyde on July 27, 2010, 05:07:49 am
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.
Title: Re: New uIP code features
Post by: rhyde on July 27, 2010, 06:55:50 am
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.
Title: Re: New uIP code features
Post by: ian on July 27, 2010, 08:45:43 am
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 (http://www.tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.shtml)
Title: Re: New uIP code features
Post by: coolnicks on September 04, 2010, 02:20:49 pm
[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 (http://www.tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.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 (http://www.nuelectronics.com/estore/?p=12) and is horribly basic

Second code from here (v1.1) http://blog.thiseldo.co.uk/?p=344 (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 (http://www.tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.shtml) does indeed have newer versions and features :)

Must give it a try...

Nick
Title: Re: New uIP code features
Post by: rhyde on November 24, 2010, 01:38:39 am
@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?
Title: Re: New uIP code features
Post by: trygvis on January 12, 2011, 01:51:01 pm
[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 (http://www.tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.shtml)
[/quote]

The FreeRTOS+uIP port from Eric (and possible the other port too) comes with a working HTTPD.

--
Trygve
Title: Re: New uIP code features
Post by: marcov on August 18, 2011, 10:22:53 pm
Hello,

I'm a dspic coder and got a webplatform board to play a bit with uip, mostly because of its DMA capabilities.

My current efforts are based on r219, before the introduction of timesharing (that doesn't agree with some of my intended purpose).

However I'm stuck getting my main interest UDP to run. Does anybody have demoes where usage of UDP (client and server)in this particular uip version could be extracted from? I tried to look into newer UDP but there the (e.g. DHCP) demoes use BIND and LISTEN that miss for udp in this version.  The older uip's only seem to have a resolver lib (client) to demonstrate UDP.
Title: Re: New uIP code features
Post by: shuckc on September 01, 2011, 05:21:51 pm
Probably best to start a new topic on this, but I had UDP send and receive working fine to sync the RTC with NTP.

I can drag out the source code as another member was asking about it too.  I've given up on FreeRTOS on the webplatform, hit too many hard-to-debug limits with stack size, and gone back to uip-only.