chipKIT® Development Platform

Inspired by Arduino™

Any chance of insertion to the wiki?

Created Tue, 17 Jul 2012 10:13:28 +0000 by majenko

majenko

Tue, 17 Jul 2012 10:13:28 +0000

Any chance my libraries could be added under the contributed libraries section of the Wiki?

Network [url]https://sourceforge.net/projects/chipkitnetwork[/url]

GLCD [url]https://sourceforge.net/projects/chipkitglcd[/url]

Change Notification [url]https://sourceforge.net/projects/chipkitcn[/url]

RTCC [url]https://sourceforge.net/projects/chipkitrtcc[/url]

I'd add it myself but it's a closed wiki :(

Jacob Christ

Sat, 11 Aug 2012 05:28:41 +0000

Can you give me a description to put in the wiki page as well?

They have been added here:

http://chipkit.org/wiki/index.php?title=Library_Status#Network

Jacob

majenko

Sat, 11 Aug 2012 09:49:53 +0000

Can you give me a description to put in the wiki page as well? Jacob

Network Fully object oriented IP stack, currently supporting the ENC28J60 chip, but can be expanded to support other interface chips and methods. Multiple concurrent sockets, connections and chips supported.

GLCD Double buffered graphical LCD library for the KS0108 and similar 128x64 LCD displays.

Change Notification Access the Change Notification pins as standard interrupts with attachInterrupt() and detachInterrupt(). Supports RISING, FALLING and CHANGE. Also has the ability to attach different interrupts to different edges.

RTCC Real-Time Clock & Calendar. Access the internal RTCC of the PIC32 chips using a simple object interface. Can also drive an interrupt when alarms occur.

Cheers

=M=

Jacob Christ

Mon, 13 Aug 2012 14:30:50 +0000

Done.

Jacob

dangeljs

Mon, 10 Dec 2012 15:30:16 +0000

@majenko What version of MPIDE does your network library support? I'm having trouble getting it to compile, with error:

In file included from C:\Users\Chrissy\OLD Dropbox\mpide-0023-windows-20120429-test\.\hardware\pic32\libraries\Network/Network.h:34:0,
                 from WebServer.cpp:2:
c:\users\chrissy\old dropbox\mpide-0023-windows-20120429-test\hardware\pic32\compiler\pic32-tools\bin\../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/include/sys/endian.h:54:22: fatal error: sys/swap.h: No such file or directory
compilation terminated.

I've tried other version (all windows based) to no avail:\

Thanks in advance for any assistance.

martinayotte

Thu, 13 Dec 2012 19:45:16 +0000

Hi Majenko,

I have the same error either with Network-r5.zip or Network-r7.zip using Linux MPIDE :

/home/martin/mpide-0023-linux-20120903/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/include/sys/endian.h:54:22: fatal error: sys/swap.h: No such file or directory

Could you explain how to fix that ?

Thanks in advance,

jasonk

Thu, 13 Dec 2012 19:57:13 +0000

Attached is a copy of the missing swap.h file. Drop it into the sys directory as shown in the error message. We lost this file when we moved to the Newlib libc instead of the proprietary MIPS libc. Sorry for the inconvenience, we will see about getting it added back into the mpide distribution.

majenko

Fri, 14 Dec 2012 00:01:06 +0000

I worked around it by using my own htons() et al, but thanks for that.

martinayotte

Fri, 14 Dec 2012 01:51:54 +0000

Hi Jason,

If I understand, this missing file is should have been part of MPIDE. Thanks for the attachment, but unfortunately, although it get further, it lead to another error :

/home/martin/mpide-0023-linux-20120903/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.1/../../../../pic32mx/include/sys/endian.h:100:1: error: 'u_int32_t' does not name a type

Is there any plan for a new MPIDE release soon ?

Thanks, Martin.

majenko

Fri, 14 Dec 2012 10:10:51 +0000

Anything from Network-r7 and up has removed the dependency on endian.h (and thus swap.h). If you still see this error with r7 or r8 then there must be something else that is including endian.h as a requirement of its own - something not under my control.

If that is the case, you might try including <sys/types.h> first before anything else.

martinayotte

Fri, 14 Dec 2012 14:09:52 +0000

Hi Majenko,

Thanks a lot ! I got it : there was another copy of R5 sitting in my library folder ... Now, it compiles fine.

dangeljs

Fri, 14 Dec 2012 15:10:44 +0000

That fixed my problem. Thank you!

martinayotte

Sun, 16 Dec 2012 15:45:20 +0000

Hi again Majenko,

I got your WebServer example working fine. I decided to start my own with a method that should stream a file located on a SD card. It worked fine if the file is quite small, but it seems that only the first block is transmitted when the file is bigger, probably the first TCP_BUF_SIZE. I've tried to insert a "c->flush()" on every 2000 bytes in my streaming loop, but no chance, only the first 4800 bytes seems to be transmitted, although the streaming loop continue to do its "c->print()" until the end of file.

Do you have any clues to make sure the whole streaming reach the client ?

Thanks in advance, Martin.

majenko

Sun, 16 Dec 2012 16:29:57 +0000

The print routine (utility/tcp.cpp) is supposed to queue the output in a circular buffer until it reaches the "mss" size (1440 bytes), at which point it should dispatch a packet. The same happens with flush(), it just forces the despatching of a packet with whatever is in the circular buffer.

The circular buffer code was pretty much lifted verbatim from the circular buffer of the HardwareSerial.

Unfortunately I don't have anything set up at the moment for testing, but if you can do a little testing for me that'd be great.

Can you confirm if the packets are actually not being sent, or if they are corrupted in some way? Maybe using some network sniffing software (I use tcpdump under linux) to see if there are packets arriving that are in fact being rejected, and maybe why, that'd be fantastic.

martinayotte

Sun, 16 Dec 2012 17:47:32 +0000

Thanks for the hints. The packets are actually transmitted, but for some reasons, the client probably reject some, I'm not very fluent with tcpdump. The client(s) are actually browsers, Firefox on Ubuntu, Firefox on Windows or IE, they all stopping showing the file, a JPG from the SD card, after few pixel's rows, only 1/10 of the picture shows up. But tcpdump shows that the remaining are actually transmitted. I've then tried a different image, same thing occurred, although the amounts of good pixels aren't the same between images, but they are across browsers for the same image. Also, I've discovered that after several "getfile", I have to reset the Max32 since it doesn't responding to any urls.