Using the Arduino Ethernet shield with AMICUS18 (Joint forum project?)

[HenrikOlsson]

Hi,
With this post I hope to spark the interest in what could develop into a joint forum project. The purpose of the project is to get the Arduino Ethernet shield working with the AMICUS18 board and, of course PBP.


Unfortunately the Ethernet shield isn't very directly compatible with the AMICUS18. The reason for this is that the shield picks up the SPI signals used to communicate with the W5100 ethernet chip and the onboard SD-card from the ICSP programming header on the Arduino. For apparent reasons this header does not exist on the AMICUS18. This means that Ethernet shield needs to be modifed in order to use it and this first post of mine is going to cover what and how I did to make it work with the AMICUS18.


Before I go on I'd like to point out a couple of things:
1) I'm using Ethernet shield v.6 which I got from NKC electronics, so what I describe here applies to that particular version. I do not know how it'll work with previous (or upcomming) versions of the shield.
2) Doing these modification most likely voids any warranty you might have on the Ethernet shield.
3) You do it at your own risk, don't blame me if you mess it up.

As have been said the Ethernet shield uses a SPI interface to communicate with the host CPU. Since these signals are brought to the ICSP header on the shield we need to "move" them to pins that suits us better. The 18F25K22 that is used on the AMICUS18 has its SPI signals on RC3, 4 & 5 which are the same as pins 4, 3 & 2 on the Ethernet shield. Now, moving the SPI signals from the ICSP header to RC3, 4 & 5 wouldn't be too hard but unfortunately two out of three pins (RC3 & RC5) are already in use by the shield so we need to move those signals too - before we can connect the SPI signals to these I/O's.

Pin 2 on the Ethernet shield (RC5 on the AMICUS18) carries the interrups signal from the W5100 chip. Since we might want to use this signal later on it would make sense to move it to an I/O-pin of the 18F25K22 capable of generating an interrupt. I've selected RB0 which on the Ethernet shield is labeled AREF. Fortunately AREF is not connected to anything on the shield so we're good to go there. By default the W5100 interrupt signal isn't actually connected to Pin2, instead there are two small solder pads on the back of the board which, when bridged with solder, connects the signal to Pin2. We'll use one of these pads to "hijack" the signal and re-route it to RB0 instead.

Pin4 on the Ethernet shield carries the chip select signal for the onboard micro-SD card socket. This signal is an ordinary I/O so any pin will do really. I've selected RB2 which, on the Ethernet shield, is labeled 13.

Why not RB1 you may think. It's because RB1 on the shield is GND and it would be hard to gain access to that pin without serious board surgury. This also brings up an important point: On the AMICUS18 board there's jumper that allows you the select if RB1 should "be" RB1 or if it's GND. This jumper should be in the GND location.

When these two signals are moved we can connect the SPI interface signals from the 2X3 ICSP header to pins 2, 3 and 4 on the shield. Let's start with the trickiest one, Pin4, which carries the chip select signal for the SD-Card. First we need to "disconnect" the signal from Pin4, this is done by cutting the PCB trace just where it comes out from under the Arduino logo:

With the trace cut we can turn the board over and find a good spot to "tap into" the signal:

Running a wire from the via marked SD_SC to RB2 and a wire from the pad marked W5100_INT to RB0 is all it takes to "free up" the AMICU18's SPI pins so we can use them.

In the next photo I've marked which pins in the ICSP header that we're interested in. SCK goes to RC3, MISO goes to RC4 and MOSI goes to RC5. I opted to remove the header altogether because it has a slight interference with the socket for the 18F25K20 on the AMICUS18 board.

Here's the the back of the board with the modification complete. One trace cut and five jumper wires and we should be good to go. (I guess you can't really call that "Arduino shield compatible"....)

/Henrik.

[mackrackit]

Thank you Henrik,

I promoted this to an article.
http://www.picbasic.co.uk/forum/cont...r=346-amicus18

[Heckler]

good write up on the modification Henrik,

I have always dreamed of setting up a little web connected interface for home automation type stuff. This seems like it would be a great place to start... especially if it was based on PICbasic pro.

I guess I better get me one of those amicus's and an ethernet shield.

[HenrikOlsson]

You can definitely use the EM202 or one of Tibbos other modules, or you can use theXPort or perhaps something from Netburner, or maby the EZWebLynx or the DigiConnectMe. Or you might want to go "low level / hardcore" and use the ENC28J60 or ENC424J600 or some other ethernet control and write the TCP/IP stack yourself. There are many ways of doing it.

But this thread wasn't supposed to be about other ways of doing it, it was meant to be about how to do it with the Wiznet W5100 which is what is being used on the Ethernet shield.

By the way, I've got PING working....and I've got to a point where I can see the HTTP Get request in the W5100 Receive memory buffer :-)

/Henrik.

[ScaleRobotics]

For those wanting to follow along, but maybe not wanting to invest in the shield and Amicus18 right now, there is a $25 solution that uses the same W5100 ethernet chip. http://www.sparkfun.com/products/9473

[lester]

My applogies to Henrick, quite right, this thread was (is) about using Arduino shields on the Amicus18. My post was out of order, promoting an alternative , was incorrect.

Henrick, i stand corrected, I hope you accept my appology, thread hijacking is unacceptable. i've removed my post and those related to it.

[Heckler]

Henrick,

Keep us posted on your progress on this... I have absolutely no experience getting into the "nuts and volts" of ethernet protocol... but, as I mentioned earlier, would love to have a little web interface to some home automation capability.

Thanks for your efforts.

[HenrikOlsson]

Hi,
I don't know what the "best" way to aproach this actually is. I don't think me posting hundreds or thousands of lines of code is going to actually help others that much and I don't think I'll get much out of it either.

Instead I think I'll post snippets and routines, explaining what they do (or at least intend to do) and why. This way I think it's easier to tag along, one step at the time and, which is important, we can discuss suggestions on improvements and alternative ways of doing the same thing. In the end we will hopefully have a set of routines which can be used to build a working application.

Before we go on I just have to point out that this is new territory for me too. I don't know much about ethernet, UDP, TCP, sockets, HTTP, HTML etc so this is very much a learning experience for me as well. Please feel free to correct any statements I make in error and please do bring suggestions on how to do things differently and, hopefully, better.


Right, the Wiznet W5100 ethernet chip (which is used on the Ethernet shield) is controlled by reading and writing to its internal registers. There are quite a few registers and instead of using a bunch of 'magic numbers' (ie the adress of the register in the W5100's memory) I've put together a file (W5100_defs.pbp) containing the name and memory adress for the registers as well as a couple of other constants we might need. Attached to this post is v1.0 of that file (remove .txt extenstion), there might be newer versions in the posts to come.

I've set up my AMICUS18 board to use the hardware USART at 115200 baud for debugging purposes. Then I set up the TRISB and TRISC registers to match the pinout of the modified Ethernet shield:

' By default the AMICUS18 board uses the PIC18F25K20, make sure to
' set up MCSP or whatever IDE is being used to compile for the
' correct device.
 
DEFINE OSC 64
DEFINE LOADER_USED 1            ' We're using a bootloader.
DEFINE HSER_RCSTA 90h           ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h           ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1           ' Clear overflow automatically
DEFINE HSER_SPBRG 138           ' 115200 Baud @ 64MHz, -0,08%
 
SPBRGH = 0
BAUDCON.3 = 1                   ' Enable 16 bit baudrate generator
 
TRISC = %10010111
' RC7: USART RX
' RC6: USART TX
' RC5: ETHERNET SPI Data out (SDO/MOSI)
' RC4: ETHERNET SPI Data in (SDI/MISO)
' RC3: ETHERNET SPI clock (SCK) set to INPUT according to datasheet....
' RC2: N/U - currently
' RC2: N/U - currently
' RC1: N/U - currently
 
TRISB = %11011011
' RB7: N/U - currently
' RB6: N/U - currently
' RB5: ETHERNET Chip select line to W5100
' RB4: N/U - currently
' RB3: N/U - currently
' RB2: ETHERNET Chip select line to SD-Card
' RB1: N/U and can not be used with the Ethernet shield
' RB0: ETHERNET Interrupt pin from W5100

Then I pretty much cut'n'pasted the register definition/aliases for the MSSP module from the SPI master example on MELABS web site. However, I had to change the CKE bit from 0 to 1 in order to get reliable communications with the W5100. This feels a bit awkward but since doing that it has been rock solid so it must be right - right?

' Aliases for the MSSP module status and control bits.
SSPEN   VAR     SSPCON1.5   ' SSP Enable bit  
CKP     VAR     SSPCON1.4   ' Clock Polarity Select  
SMP     VAR     SSPSTAT.7   ' Data input sample phase  
CKE     VAR     SSPSTAT.6   ' Clock Edge Select bit  
SSPIF   VAR     PIR1.3      ' SPI interrupt flag
 
'Set up the MSSP module.
CKP = 0                     ' Clock idles low  
CKE = 1                     ' Transmit on active to idle transition.  
SSPIF = 0                   ' Clear buffer full status  
SMP = 0                     ' Sample in middle of data 
SSPEN = 1                   ' Enable SPI pins
SSPCON1.0 = 1              'Slow down SPI clock to Fosc/16 for now.

I also had to slow down the SPI clock from the default (Fosc/4) to Fosc/16 in order to get reliable communication. The AMICUS18 defaults to 64MHz so with Fosc/16 the SPI clock is running at 4Mhz which isn't directly slow but well below what the W5100 is capable of (if I read the datasheet correctly that would be ~14Mhz). However, the modification done to the shield and the fact that W5100 is on a separate board from the 18F25K20 may have an impact on the maximum speed achievable. Anyway, I'll leave it at Fosc/16 for now.

Finally I included the file with all the register definitions for the W5100:

INCLUDE "W5100_defs.pbp"        ' Register definitions and constants for the W5100.

That's all for this post.

/Henrik.

[pedja089]

I am interested in this project. For now, I have no hardware, no time to make it. So for now I'll watch and learn

[ScaleRobotics]

Henrik, I just wanted to thank you for the excellent job you are doing. Very exciting! You have made it so easy for the rest of us. I just received my Wiznet module, the WIZ811MJ, which contains a W5100. So I hope to join the fun when time permits.

Thanks again.

[HenrikOlsson]

Thanks Walter!
And please do join the fun!

Perhaps we should emphasise, in case that isn't 100% clear, that it's not needed to have an AMICUS18 board and Ethernet shield, it just happens to be my personal development setup. As long as you have a W5100 connected to a PIC via SPI you're all set - like a WIZ811MJ and your favourite PIC on a piece of perfboard.

You can even re-write the Read_W5100 and Write_W5100 subroutines if you want to use shiftout/shiftin instead (it'll be kind of slow though....) or if you want to go to the more traditional adress/data interface (requires a boatload of I/O). That's all you'd need to change, all the other routines go "thru" those two so should work just the same.

What I'm not happy with so far is that all posted code has been hardcoded for socket 0. I have changed it, as discussed in an earlier post, but decided to keep these initial examples hardcoded to keep it easier. Also, I'm NOT happy with the way ArrayWrite literally EATS the codespace, we'd have to come up with a SD card routine or perhaps one of the strings in codespace routines mixed with a couple of ArrayWrite for the dynamic data.

Oh well, one step at a time...

/Henrik.

PS. DHCP is now working nicely, with proper handling of leasetime and renewal of lease. Very cool but it adds about 3kB and 42 bytes of RAM to the total footprint when included, I'll try to get that down a bit further.

[HenrikOlsson]

Hi everyone,
Time for an update. As I wrote in the previous post I've had DHCP working nicely and today I thought it was time to show you how it can be used. However, for this to work nicely, there had to be some changes made to the overall structure of the package of files used. It gets easier to USE but a tad more complicated to maintain. I won't go into specific details, just give you the overall picture.


First of all, the code now requires PBP3. This is beacuse I've added a bunch of conditional debug statements in the code making use of the wonderful conditional compilation feature of PBP3. For example, you can add #W5100_DEBUG_LEVEL 1 to the top of the code and you'll get a whole bunch of data sent over the USART, if you want even more details do #W5100_DEBUG_LEVEL 2. Do note though that these takes up a lot of program space so if the application grows they might not fit when "activated".


The main include file for using the W5100 is called W5100.pbp and that's what you should included from the main program/application. It is also in THIS file that you may need to make some changes to match your project:

1) BufferLenght CON 256 - This is the length of the local buffer (array) that gets declared, you can change this to match your needs. Don't make it too small though, the DHCP routines - if you're going to use those, requires a lenght of ~48 minimum.

2) MAC-adress - This is the hardware adress of the device, change as needed - and please DO change it, don't use mine! As can be seen the MAC adress is defined as constants and can therefor currently not be changed at runtime - this MAY change or you can change it yourself.

3) W5100_Select VAR PortB.5 - this is the PIC-pin to which ChipSelect pin of the W5100 is connected. My modified Arduino Ethernet Shield uses PortB.5

This file (W5100.pbp) then includes two more files - W5100_defs.pbp (which we've looked at before) and W5100_subs.pbp which contains several of the routines discussed in earlier posts as well as others. Neither of these files 'should' need to be edited.


In previous "exercises" we've hardcoded the IP-adress, netmask and gateway address of the W5100 - for DHCP to work properly this can't be done. So I've declared three arrays (in W5100_subs.pbp) called W5100_IP, W5100_Netmask and W5100_Gateway - all 4 bytes long. To set the network parameters of the W5100 we can now do something like:

W5100_IP[0] = 192
W5100_IP[1] = 168
W5100_IP[2] = 1
W5100_IP[3] = 100

W5100_NetMask[0] = 255
W5100_NetMask[1] = 255
W5100_NetMask[2] = 255
W5100_NetMask[3] = 0

W5100_Gateway[0] = 192
W5100_Gateway[1] = 168
W5100_Gateway[2] = 1
W5100_Gateway[3] = 254

GOSUB Init_W5100

The Init_W5100 subroutine uses the above arrays and sets the parameters of the W5100 accordingly.

To be continued in the next post....

[HenrikOlsson]

...continued from previous post.

OK, Dynamic Host Configuration Protocol - DHCP.
DHCP is used to automatically configure a networkdevice without actually knowing anything about the network it's attached to. There are hundreds and hundreds of pages to read about how it works so I won't cover it in much detials, just give a basic overview.


The process starts with the client sending out what's called a DHCP Discover message. This is sent as a brodcast message meaning it's addressed to any and all DHCP servers on the current subnet. One, or more, servers(s) will respond with a DHCP Offer message containing an offer for a lease of a specific IP adress for a specific amount of time. The client can then selects one of these offers and sends a DHCP request message, still as a broadcast message but it has now filled in the server it wants to use in a specific field in the message. If everything goes well the server responds with a DHCP Ack message meaning that it has now reserved the IP-adress for the amount of time specified and the client is free to use it. The client is NOT allowed to start using the IP-adress untill a valid DHCP Ack message is received. Along with the IP adress the server also provides other important setting such as the netmask and the gateway adress.

Like I said, this is just the basic outline of the process - there are alot of details to get into, which we don't have to do right now.


The DHCP implementation for the W5100/PBP3 is supplied as three files. The main file to include in your project is DHCP.pbp It's also in this file that a change or two may be needed. At the top, you'll find this:

HostNameLength          CON     6           ' <- Change this to match the length of the name.
HostName                VAR     BYTE[HostNameLength]
HostName[0] = "A"
HostName[1] = "m"
HostName[2] = "i"
HostName[3] = "c"
HostName[4] = "u"
HostName[5] = "s"

This is the host name that is supplied to DHCP server. It then (if it has the functionallity) passes it on the DNS server and the end-result is that the client device can be accessed by name, ie you can browse to http://amicus instead of trying to remeber the IP-adress. What you need to change is the HostNameLenght so that it matches exactly the lenght of the array containing the name you want to use. As in the example above the name is 6 bytes long therefor HostNameLenght is 6.

The DHCP.pbp file then includes two more files, DHCP_subs.pbp and DHCP_defs.pbp - neither of which 'should' need any editing for normal use.

As with the main "driver" files for the W5100 I've added a while bunch of debug-messages to the DHCP code. These can be enabled by adding a #DEFINE DHCP_DEBUG_LEVEL 1 or #DEFINE DHCP_DEBUG_LEVEL 2 to the application. Again, these adds quite a bit of code.

When the DHCP process is complete we can get the network setting to use from the arrays DHCP_IP, DHCP_NetMask and DHCP_GateWay and use these to initilise the W5100.

To be continued in the next post....

[HenrikOlsson]

...continued from previous post...

OK, lets write some code....(finally)....

The first thing to do, as always is to set up the hardware. I'm using the AMICUS18 and the modifed Arduino Ethernet Shield, here's the first part of the code:

DEFINE OSC 64                       ' Default oscillator speed on the AMICUS18 is 16*4MHz
DEFINE LOADER_USED 1                ' We're using a bootloader.
DEFINE HSER_RCSTA 90h               ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h               ' Enable transmit, BRGH = 1
DEFINE HSER_CLROERR 1               ' Clear overflow automatically
DEFINE HSER_SPBRG 138               ' 115200 Baud @ 64MHz, -0,08%

SPBRGH = 0
BAUDCON.3 = 1                       ' Enable 16 bit baudrate generator

TRISC = %10010110                   ' RX, TX, MOSI, MISO, SCK, N/U, N/U, LED 
TRISB = %11011011                   ' N/U, N/U, W5100_CS, N/U, N/U, SD_CS, N/U, W5100_Interrupt

' Aliases for the MSSP module status and control bits.
SSPEN           VAR SSPCON1.5       ' SSP Enable bit  
CKP             VAR SSPCON1.4       ' Clock Polarity Select  
SMP             VAR SSPSTAT.7       ' Data input sample phase  
CKE             VAR SSPSTAT.6       ' Clock Edge Select bit  
SSPIF           VAR PIR1.3          ' SPI interrupt flag

milliseconds    VAR WORD            ' Timer variable, used in the ISR.
TMR1_Temp       VAR WORD            ' Used when reloading the timer in the ISR
i               VAR BYTE            ' General purpose.

CLEAR

' Set up the MSSP module.
CKP = 0                             ' Clock idles low  
CKE = 1                             ' Transmit on active to idle transition.  
SSPIF = 0                           ' Clear buffer full status  
SMP = 0                             ' Sample in middle of data 
SSPEN = 1                           ' Enable SPI pins
SSPCON1.0 = 1                       ' Slow down SPI clock to Fosc/16 for now.

Then we need some what to keep track of time. The DHCP server leases us an IP-adress for a finite (usually) amount of time and we need to keep track of that time so we can renew the lease before the time runs out. For this purpose I'm using Darrels DT-Ints so I'm including his files and while I'm at it I'll also include the W5100.pbp and the DHCP.pbp files and the set up an interrupt to trip when TMR1 overflows:

INCLUDE "DT_Ints-18.bas"            ' <- Darrel Taylores interupt engine
INCLUDE "ReEnterPBP-18.bas"         ' <- Part of Darrels interrupt engine.
INCLUDE "W5100.pbp"                 ' <- Main W5100 "driver" and auxiallary routines.
INCLUDE "DHCP.pbp"                  ' <- Main file for the DHCP engine.

'--- Set up TMR1 interupt.
ASM
INT_LIST  macro    ; IntSource,     Label,       Type, ResetFlag?
        INT_Handler     TMR1_INT, _Tick,    PBP,   yes
    endm
    INT_CREATE               ; Creates the interrupt processor
ENDASM

TMR1_Reload CON 25539                           ' Reload value for 200Hz @64MHz, 1:2 prescaler
T1CON.0 = %00010001                             ' Start timer 1, 1:2 prescaler
@ INT_ENABLE TMR1_INT

I've put my TMR1 Interrupt service routine at the end of the program but to keep the disussion on track I'll show it here:

' This is the TMR1 interrupt service routine.
Tick:
    milliseconds = milliseconds + 5

    If milliseconds => 1000 THEN
        DHCP_Seconds = DHCP_Seconds + 1
        milliseconds = 0
    ENDIF

    T1CON.0 = 0

    TMR1_Temp.HighByte = TMR1H
    TMR1_Temp.LowByte = TMR1L
    TMR1_Temp = TMR1_Temp + TMR1_Reload
    TMR1H = TMR1_Temp.HighByte
    TMR1L = TMR1_Temp:LowByte

    T1CON.0 = 1
@ INT_RETURN

This runs at ~200Hz, each time it increments the millisecond variable by 5 and when it reaches 1000 (1 second) the variable DHCP_Seconds is incremented - and this is the important thing. The DHCP code must be called periodically, even after an IP-adress had been recieved. This is because it has to keep track of the lease time which it does by subtracting the number of seconds on DHCP_Seconds from the total lease time given to us by the server. It then resets DHCP_Seconds to 0.

So, "we" must make sure that DHCP_Seconds contains "true time" and GOSUB DHCP periodically. We don't have to increment DHCP_Seconds at exactly 1Hz, we can increment it by 10 every 10 seconds or whatever but it's impotant that it's fairly close to real time. Likewise, we don't have to GOSUB DHCP every second or even every minute but because DHCP_Seconds is a BYTE variable we must atleast do it once per 4 minutes or there abouts.

Next we initilise the W5100 and set the network parameters to "all zeros":

Begin:
    HSEROUT["Program start...", 13]
    ' A substantial pause is needed for the W5100 to start up and establish
    ' a link with the network. 
    Pause 2000                                  
   
    ' We don't know any network parameters so these should all be set to 0
    ' when using DHCP.
    HSEROUT["Clearing IP, Netmask and Gateway adress",13]
    For i = 0 to 3
        W5100_IP[i] = 0         ' Set our IP adress to 0.0.0.0
        W5100_Netmask[i] = 0    ' Set our netmask to 0.0.0.0
        W5100_GateWay[i] = 0    ' Set gatway adress to 0.0.0.0
    NEXT
    ' Now initilise the W5100 with the above parameters.
    GOSUB Init_W5100

There's a bit variable called DHCP_Enabled which should be set to 1 if DHCP is to be used. There might be ocations where we want to have the abbility to use DHCP but also to turn it off, this flag makes sure that the DHCP code doesn't execute, even if called, if not specifically "enabled". Then we must tell the DHCP code which of the W5100's four sockets to use, this is done thru the DHCP_Socket variable. Finally we set the state of the DHCP state machine (it's all implemented as a big state machine by the way) to DHCP_State_Start.

Now, all we need to to is keep GOSUB'ing DHCP periodically and if everything goes well we'll have all the network parameters we need within a second or three:

    DHCP_Enabled = 1                            ' Enable DHCP. 
    DHCP_Socket = 2                             ' Use socket 2 for DHCP.
    DHCP_State = DHCP_State_Start               ' Reset the DHCP state machine.

    ' Loop around here until we recieve a valid IP adress.
    HSEROUT["Entering DHCP",13]
    While DHCP_State <> DHCP_State_Bound
        GOSUB DHCP
        Pause 500
    WEND

The key to detect when the process is finished is that the state variable (DHCP_State) is set to DHCP_State_Bound and that's what weäre using here. We keep calling DHCP untill we see the correct state. As long as we also updates DHCP_Seconds in the background the DHCP state machine will automatically issue retransmissions at specific intervals (as per the DHCP specification).

Once we see the bound state we can get the parameters from the DHCP_IP, DHCO_NetMask and DHCP_GateWay arrays and use those to re-initilise the W5100:

    ' At this point we should have received a set of valid network paramters from
    ' the DHCP server on the network. Let's start by simply printing them out.
        HSEROUT["The offered IP adress is: "]
        For i = 0 to 3
            HSEROUT[#DHCP_IP[i], "."]
        NEXT
    
        HSEROUT[13,"The gateway is: "]
        For i = 0 to 3
            HSEROUT[#DHCP_Gateway_IP[i], "."]
        NEXT
    
        HSEROUT[13, "The netmask is: "]
            For i = 0 to 3
            HSEROUT[#DHCP_NetMask[i], "."]
        NEXT
    
    ' The DHCP engine does NOT actually SET the IP adress for us, it just TELLS
    ' us what to use. We must make the changes ourselves:
    HSEROUT[13,"Setting the W5100 parameters..."]
    For i = 0 to 3
        W5100_IP[i] = DHCP_IP[i]
        W5100_GateWay[i] = DHCP_GateWay_IP[i]
        W5100_NetMask[i] = DHCP_NetMask[i]
    NEXT


    ' Now re-initilise the W5100 with the new network parameters.
    GOSUB Init_W5100
    HSEROUT["DONE!",13]
    HSEROUT["Try pingning by IP or name!",13]

Don't forget that we still need to have DHCP_Seconds updated in the ISR and we still have to GOSUB DHCP on a regular basis so that it can automatically renew the IP adress lease when it's about to expire:

Main:
 Toggle PortC.0
 Pause 500
 GOSUB DHCP
Goto Main

Attached to this post are all the updated files (W5100.pbp, W5100_defs.pbp, W5100_subs.pbp, DHCP.pbp, DHCP_defs.pbp, DHCP_subs.pbp and the DHCP_Demo application used to get the above results.

/Henrik.

[tayfun]

hi,

In this project, every socket been defined as 2K, but 2Kb web page is a very short size..

i want to change 8kb RX buffer and 8 Kb TX buffer, because total buffer size 16 Kb.

i was change ;
8Kb



WizAdress = W5100_TMSR : WizData = $03 : GoSub Write_W5100
WizAdress = W5100_RMSR : WizData = $03 : GoSub Write_W5100

'--------------------------------------------------------------------

W5100_S0_RX_START CON $6000 'Start adress of Socket 0 (not changeable)
W5100_S0_RX_END CON $7FF9
W5100_S0_RX_MASK CON $1FFF 'Mask value for 8k


'--------------------------------------------------------------------

W5100_S0_TX_START CON $4000 'Start adress of Socket 0 (not changeable)
W5100_S0_TX_END CON $5FFF 'End adress of Socket 0 (depends on the TMSR register)
W5100_S0_TX_MASK CON $1FFF 'Mask value for 8k



but not work :S have other configration? or I'm doing wrong in somewhere!

[HenrikOlsson]

Hi,
First of all I need to admit that I'm not sure if I've actually tested with anything except the default 2k per socket so it's quite possible something isn't correct there. The phrase but not work isn't much help though, do you have any other leads or hints, what does it do or what does it not do?

With that said, one thing I do see is

W5100_S0_RX_START CON $6000 'Start adress of Socket 0 (not changeable)
W5100_S0_RX_END CON $7FF9      ' <----- Shouldn't this be 7FFF?
W5100_S0_RX_MASK CON $1FFF 'Mask value for 8k

but I'm not sure if that IS the only problem or not.

/Henrik.

[VaGyver]

Hello Henrik!

I would like to congratulate you for your very nice work here!
You made me, buy a shield, modify the code and get it worked!
Thank you that. I prefer that to a ready solution.

What i did is i translated your code into Proton+ Compiler and made:
a) a server, a simple web page with dynamic variables and
b) a client, which loads values into cosm database (ex pachube).

So, i would like to ask two questions:
a) Do you use multisocket operation? Or only one socket? If yes, what is the basic concept? Opening all 4 sockets, set to listen and wait by looping pediocally to sockets wait for a "GET"request?
b) There is a thought of opening a thread at Proton+ Compiler's forum with OF COURSE reference to you (your name and this thread's address) with some translation of your code into Proton. But i have to have your permission first.
Take a look here:
http://www.protonbasic.co.uk/showthr...797#post476797

[HenrikOlsson]

Hi,
Thank you, nice job on porting the code!

I'm interested in how you implemented the dynamic variables. It's been quite some time since I worked on this code but last time I did work on it (back in January) I went of on a tangent starting to implement a subset of the Microchip File System for storing the webpage content in external flash instead of in the PIC. Geez, can't even remember where I left off....

So, your two questions:
a) The code should work for multiple sockets. I've not used it for multiple connections to a web-server but I've had one socket to DHCP, one socket DNS, one socket SNTP and one socket SMTP - at the "same" time.
I don't think you should open all socket in listen mode at the same time though. If your device is acting as a server to serve up the web-page (or webpages) then you open a socket (say socket 0) and wait for a connection. When you get a connection on socket 0 you can open a second socket and wait for a connection on IT. That's probably how I'd try it as a start.

b) Sure, go ahead! (Thank you for asking, I appreciate that!) If you build upon the code and post in the Proton forum perhaps there are ideas and implementations I can "convert back" into the PBP code and so on. That was kind of the idea of this thread from the start - to build a base or "framework" (popular word) for the W5100 which others could build "applications" around (web-server, emailer, twitter client etc). Obviously I would've preferred if you did it in PBP but you can't have it all ;-)

If you do put something up please send me a link!

Damn, now you resparked my interest in this... I even got a couple of WIZ820IO with the (now no longer brand new) W5200 chip that I was going to implement in the same code. Too many projects...

/Henrik.

[VaGyver]

- About dynamic variaables:
What i did is not effective, but works. I converted the variables to strings and then i just added to the rest string, meaning the Str Buffer.
Fore example:
StrN Buffer = Str$(Dec variable_to_publish)
GoSub PutStringInTXBuffer

- About multisocket:
I am also searching this. The issue here is that i need to also pass dynamic variables as well. So, this means i must control all sockets simultanously (and my microchip chip also does other task too). Anyway, i will make some test on this and tell you the results.

- Publish your (modified for Proton+ compiler) code:
Of course i will do that (inform you). By the way, i intent, for start, only to publish a simple code that makes a web page with dynamic variables only (without DHCP). And i found out that these two compilers have very little differences.


- I would like to ask a little help for a snippet. Why you are doing this in DHCP code, because i couldn't convert it with easy way?

' Get second Bit in DHCP_LeaseTime And copy it To first Bit of Buffer And so On.

For DHCP_i = 0 To 30
Buffer.0[DHCP_i] = DHCP_LeaseTime.0[DHCP_i + 1]
Next

Thank you in advance.


Vangelis

[HenrikOlsson]

Hi,
Thanks! Actually I was more aiming at what format you used to "place" a variable in the actual HTML and how you detect that when the program parses the HTML page to replace the "dynamic variable identifier" with the actual variable value. Does that make sense?

Anyway, regarding the DHCP code:
The lease time received from the DHCP server is a 32bit variable stored in the DHCP_LeaseTime array (4 bytes). The IP-adress lease must to be renewed before the lease time expires. What I do is simply divide the actual lease time in half, when that time (half of the actual lease time) expires the code triggers a renew of the lease.

The code snippet you ask about performs that divide by 2 operation by shifting the value one step to the right. It uses the Buffer array as a temporary storage for moving Bit1 in LeaseTime to Bit0 in Buffer and so on. Finally it copies the shifted result back to DHCP_LeaseTime.

The reason for doing it this way is that I wanted to avoid using LONGs (32bit variables) in PBP because it adds quite a bit of overhead. Using a LONG for the lease time and doing LeaseTime=LeaseTime/2 or LeaseTime=LeaseTime >> 1 would result in the same thing.

Looking at the code now I could probably do something like this instead of using Buffer as a temporary storage

For DHCP_i = 0 To 30
  DHCP_LeaseTime.0[DHCP_i] = DHCP_LeaseTime.0[DHCP_i + 1]
Next
DHCP_LeaseTime.0[31] = 0

Anyway, I hope that explains the what and why.

/Henrik.

[VaGyver]

I think that i understood it (the issue about dividing the time by 2).

What i will do is that i will simply rotate each byte by 2 to the right individually. So it will be divided by two. The DHCP_LeaseTime[3] by 2, then the DHCP_LeaseTime[2] by 2, ........ lastly the DHCP_LeaseTime[0].
I think it will have the same result.


For the dynamic variables:
I am not sure that i understood correctly what you are saying, but what i exactly do is placing the following html command. With this, the web page gets refreshed each 5 seconds.

Str Buffer="<meta http-equiv=\"refresh\" content=\"5\">",13,10,0 'refresh every 5 seconds
GoSub PutStringInTXBuffer


You could select other time too, if you wish.
So, the client (the person who sees your web page) will load again all the web page with the new variables (every 5 seconds). This is not quite effective since, sometimes, it makes a flashing on the page. But the data get refreshed correctly.
There is also an other (more effective) way to do that (in order to avoid the flashing), with xml requests, but i am yet enough familiar with it.

[VaGyver]

Hi,

Damn, now you resparked my interest in this... I even got a couple of WIZ820IO with the (now no longer brand new) W5200 chip that I was going to implement in the same code. Too many projects...

/Henrik.

For your info:
http://www.dacomwest.de/fileadmin/Da...0_20110923.pdf

[tayfun]

Hello,

Henrik bravo !

a wonderful project, a project I need my mail sender'm using 18F4620. I have W5100 or Amicus.


henrik can help me?

[HenrikOlsson]

Hi,
Sure, no problem, give me an hour and I'll write it up for you.
Where do you want me to send it when it's finished?

No, really. I'm trying to help as much as I can but it doesn't work like that. You give some and you get some.

With that said, getting SMTP to work is not a simple task and it will not work with SSL or any other encryption. If you haven't done anything with the W5100 previosuly, like set it up to respond to a ping, serve a simple web page etc (the stuff that already IS detailed in this thread) then forget SMTP. At least untill you HAVE done the previous stuff and know a Little bit of how it works. I'm not saying that you don't, I'm just saying that if you DO then post your effort and I or someone else might be able to help you out.

/Henrik.