| View previous topic :: View next topic |
| Author |
Message |
wayneosdias
Joined: 26 Nov 2007
Posts: 16
|
| Ethernet non-server |
 Posted: Fri Jun 06, 2008 2:07 pm |
 |
|
Been playing around w/the picdem.net 2 board and the various versions of the TCPIP stack and reading the AN833 doc. Still I cant seem to figure out a simple way to proceed w/my project.
I want to update calibration variables of my pic based analyzer in the field using ethernet to connect to a PC connected to the internet, no web serving per say by the pic.
To put simply, I want to replace my rs232 connection w/ethernet for local connectivity of a pic to a pc connected to the internet.
Everything Ive been reading or samples Ive seen has the pic as the server, is there a way around this?
Any suggestions would be greatly appreciated.
wayne |
|
 |
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Fri Jun 06, 2008 2:23 pm |
|
|
You do not have to implement a web server but, if the PC is initiating the data transfer then you do need to implement a UDP or TCP server. Use UDP if a connectionless connection is sufficient or TCP connection if you want to establish a connection. UDP requires less resources (less program memory and RAM) but TCP provides you a reliable connection (sort of) meaning it will detect packs lost in transit and resend data.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
wayneosdias
Joined: 26 Nov 2007
Posts: 16
|
|
| Posted: Fri Jun 06, 2008 5:57 pm |
|
|
Thanks Andrew
I have been reading the EthernetComplete by JA and from what I gather TCP would be the way to go . Theoretically I feel ok, but microchip keeps updateing the stack, currently v4.5, shaking my confidence.
What do you mean by "connectionless connection"?
Do you use the ccs modified stack or did you create your own?
Thanks
wayne |
|
|
andrewg
Joined: 17 Aug 2005
Posts: 316
Location: Perth, Western Australia
|
|
| Posted: Sat Jun 07, 2008 3:36 am |
|
|
I'd recommend a TCP server on the PIC, specifically a telnet (tcp port 23) server. That way you can use any readily available telnet app to connect to your PIC.
_________________
Andrew |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sat Jun 07, 2008 7:22 am |
|
|
| wayneosdias wrote: | Thanks Andrew
Theoretically I feel ok, but microchip keeps updateing the stack, currently v4.5, shaking my confidence.
What do you mean by "connectionless connection"?
Do you use the ccs modified stack or did you create your own?
Thanks
wayne |
UDP is a connectionless datagram transport service. You send a frame and it arrives at its destination or it does not. UDP does not maintains state information about the transport - the sender (at the UDP layer) has no knowledge if the receiver is even present let alone if any frames have been lost in transit. UDP is simple to implement but it means that the application layer (end-to-end) is responsible for managing the data exchange.
TCP is a connection orientation streaming transport service. Unlike UDP which transfer frames, TCP transfers a stream of bytes. It is up to the application to perform any framing / deframing of the byte stream. TCP provides a connection orientated reliable transport layer delivery service with each byte transmitted having a sequence number associated with it. The sending TCP knows the receiving TCP has received up to byte "x" when it processes the acknowledgment sequence number from the other end. Naturally for it to do this each end must maintain state information for example what is the sequence number of the next byte i expect to send, what is the range of valid acknowledgment sequence number i am expecting to receive, what is the sequence number of the next byte I expect to receive from the other end of the connection for data it is transmitting to me and what is the next acknowledgment number i need to send back to the other end. As well as this information, TCP maintains a series of timers to manage the connection to determine if acknowledgments are missing, if the connection is active etc. If, as a result of a timer expiring, one end determines if it has not received a corresponding acknowledgment it will retransmit the stream from the point of the last acknowledged byte in the stream. This means the transmitting PIC must buffer bytes in the stream that have not yet been acknowledged which is why you ideally need to be using PICs with a large amount of RAM.
In a nutshell, UDP is packet orientation but it is up to the application to handle data flow. TCP is "reliable" but it is up to the application to deal with framing of the data. TCP requires considerably more resources on the PIC (RAM) and dictates a fairly rigid state machine implementation is required.
I use my own stack. From the point of view of adding new features, Microchips continuously updating their stack is a good thing however because they are continuously playing with driver support, and the stack APIs, I do not currently use their stack in my products. I do use their stack for customers that specifically request it but then I qualify the support I can give the customer is tied to the specific version of the stack.
You have to determine which protocol best fits your application and resources available to you. UDP and TCP are both easy to work with on the PC side, you just use the standard "sockets" interface built into the operating system.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!
Last edited by asmallri on Sat Jun 07, 2008 3:23 pm; edited 2 times in total |
|
|
wayneosdias
Joined: 26 Nov 2007
Posts: 16
|
|
| Posted: Sat Jun 07, 2008 12:53 pm |
|
|
Thanks Andrew
Excellent suggestion.
Using the microchip TCPIP wizard I was able to strip down the demo to DHCP and Telnet and com via dos cmd. I think this is the best route to pursue for our purposes.
Using the wizard my compiled code (including demo app) is ~17k, just over half the program memory of the current uC we use. I need to see if I can trim this down manually, but before I do I still need to wrap my head around incorporating our algorithim into the multitasking structure of the stack.
Aside from the Ethernet Complete text can you recommend any other resources re ethernet? Im taking the microchip TCP/IP course at the end of june, but have already run thru the labs.
Thanks again
wayne |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
