Shop OBEX P1 Docs P2 Docs Learn Events
Spinneret code almost working? — Parallax Forums

Spinneret code almost working?

AKruzelAKruzel Posts: 25
edited 2011-09-10 08:57 in Accessories
Hello all,
I’ve been working on writing my own code for the spinneret and I’m feeling very close to achieving my goal of reading data sent from web browser after I type my IP address into the web browser and establish a socket. After reading the data in the RX memory successfully, I’m trying to send a string from the propeller to the web browser and having it appear on the screen but I’m not getting it to work. Not sure where I’m going wrong.


Here’s a simple list of instructions for using my code. This is what I’m doing so perhaps I’m approaching this the wrong way?:

1. Change IP address, MAC address, etc to fit to your spinneret. You’ll see these in the INIT function of my code

2. Program it into propeller using prop plug on spinneret

3. The program will go ahead and initialize the common registers and then will prompt you to hit W for write, R for Read, Z for reset or E for Exit. This is meant to be a “LIVE” interface so I can quickly write and read certain registers using the terminal. Just hit E for exit for now and it will go through setting the mode for the socket, etc and setting it to listen.

4. Type in the IP address with the necessary port (I have port set as 5555 in my code) into your web browser and try to connect

5. The terminal should now be prompting you to make another selection of typing, W,R,Z or E. Type E and it will go through establishing the socket and reading data from the RX memory.

6. This is the part that’s tripping me up. After reading the memory, I want it to write a string back to the web server and have it appear on the screen. Not sure if it’s something I have written incorrectly in the string or the sequence and timing of the SEND, DISCON and then CLOSE commands.

I appreciate anyone who’ll take the time to test this out and see where I may be going wrong!

[FONT=&quot]Thanks,[/FONT]

Comments

  • Mike GMike G Posts: 2,702
    edited 2011-09-06 18:56
    The logic spends most of it's time in the LIVE method waiting for input on the serial line. When the client requests a socket there is nothing to service the request. The Status register goes from 0x14 -> 0x17 -> 0x1C before the user has time to press "E".

    Just comment the LIVE method in check_socket.
    PUB check_socket|socketstatus,socketstatuscheck,readsize
    'socket status register value for socket closed is $00
    'LIVE
    socketstatus := SPIREAD($04,$03)                                    'read socket status register
    serial.str(String(serial#NL,"Outside Case Socket Status is: "))
    serial.hex(socketstatus,3)
    waitcnt(clkfreq/1000 + cnt)
    
  • AKruzelAKruzel Posts: 25
    edited 2011-09-06 19:14
    Hey Mike G,

    Thanks for the response! That makes sense..i tried commenting the LIVE line so the server services the request when the socket is established but i still don't receive anything in the web browser once the data is put in the tx buffer and sent. Were you able to get the string i wrote in the DAT block to appear in the web browser? Is there something wrong with my HTML?

    Thanks again
  • Mike GMike G Posts: 2,702
    edited 2011-09-06 19:46
    I think the response takes too long and the browser times out. Try removing all those waitcnt commands.

    The HTML should look like
    DAT
    
    Response byte "HTTP/1.1 200 OK", $13, $10, "Content-Type: text/html", $13, $10, $13, $10, "<html><body><h1>Hello world</h1></body></html>", $13, $10, 0
    

    I commented all the waitcnt commands in senddata. No timeout but the browser was blank.

    I also commented this section
       $17:
         serial.str(String(serial#NL,"SOCKET ESTABLISHED!"))                         'if socket established
         'rxdatasize                                                                'read data received size
         'rxdataptr                                                                 'read data pointer
         'readdata                                                                    'read data
         readtxfreesize                                                                 'get tx freesize value
         readtxdataptr
         senddata                                                                   'send data
    
    
  • AKruzelAKruzel Posts: 25
    edited 2011-09-07 13:18
    I tried commenting the waitcnts and still can't get the HTML to appear. When the socket is established, the web browser is telling me that it is waiting on the spinneret and when i close the socket, the web browser stops trying to connect. If the web browser times out doesn't it usually notify the user? I also went through and checked the socket interrupt register while it's transmitting and it doesn't show a timeout..also after after writing the data to the TX memory, i write the send command to the command register and read the interrupt status register before disconnecting and closing the socket and it says the data was sent ok.
  • AKruzelAKruzel Posts: 25
    edited 2011-09-07 14:18
    Here's a few issues i'm discovering the more i troubleshoot:

    1. at times i'm reading the interrupt register to be $05 while sending data and $15 after sending which makes sense. But sometimes i'll read the register to be $17 the entire time which is supposed to mean that it's connected, disconnected or has received a disconnect request and has received data or data is still available for reading after recv request, and that data has been sent ok...what can this mean?

    2. my real tx memory address start is 46C9 and last address 4726 after sending data. I used strsize on my string and the string size is 92 and as you can see here the difference between the start and end addresses is 93 so i should be good. However before sending data i read TX_RR to be 40EF and after sending data to be 40E7. This doesn't seem possible since it would appear to be going backwards and isn't within the addresses where data is being sent in the TX memory.

    most recent code is attached
  • AKruzelAKruzel Posts: 25
    edited 2011-09-07 15:55
    I got html to appear on the screen but it was kind of garbled but the message in my response string was there. At times after closing the socket i get an option to save an octet stream which is a .part file so i feel like part is getting transferred. For some reason, the TX_RR value doesn't seem to do what the spec sheet says it supposed to do which is after sending, be the same value as TX_WR. At the beginning of my code i set the offaddr to be the same as TX_RR and after going through writing my data, i write the new TX_WR pointer using the offaddr that was incremented while sending data. I do this since after SEND is written to the command register, data is transmitted from TX_RR to TX_WR, however the TX_RR value doesn't end at the same place. For instance in my last code i sent, TX memory start address: 40E9 TX memory end address: 4146....now TX_RR start address: 40E9, TX_RR end address 4047

    any ideas why TX_RR doesn't end at the same address as TX_WR?! so close...
  • Mike GMike G Posts: 2,702
    edited 2011-09-07 16:54
    AKruzel wrote:
    i get an option to save an octet stream which is a .part file
    That usually means that the content-type header line has a problem.
    AKruzel wrote:
    any ideas why TX_RR doesn't end at the same address as TX_WR?! so close...
    I think you are referring to memory buffers. If so, the calculation is in the W5100 datasheet.
  • AKruzelAKruzel Posts: 25
    edited 2011-09-07 20:13
    TX_RR and TX_WR are pointers, turns out TX_RR just goes from 0000 to 00FF and rolls back to 0000. This may be just in my case where i'm using 2KB for 1 socket. This is what i've concluded after trying to connect to my webserver several times and the amount it increments is equal to the length of my string.

    I don't know what would be wrong with my content-type header line, seems like it's a pretty basic thing to send. I'm not too familiar with HTML so if you have any recommendations for a simpler string to send let me know.

    It appears from the spec sheet that TX_RR isn't even really used in sending data even though it mentions that when the SEND command is written, data is written from TX_RR to TX_WR. There doesn't appear to be any calculation necessary for TX_RR and from how i see that it functions not sure what would work. The code to write data to the TX buffer and write the command to SEND seems pretty basic but i'm at a loss, don't know what i'm missing.
  • AKruzelAKruzel Posts: 25
    edited 2011-09-09 14:44
    I was messing around with Mike G's code for a bit trying to understand it and see where i was going wrong with my code and when i programmed my code back into the prop and tried to connect through the web browser i received a screen as shown in the attachment. You can see my message imbedded in the garble at the bottom of each paragraph, i believe it is MY header, content type and the message i've been trying to send "hey baby!" (trying to get something to pop up for my g/f)..in mike's tutorial he tells us to program his program in EEPROM so it seemed like our two were somehow working together because when i programmed my code into EEPROM, i stopped getting the message shown in the attachment.

    This is telling me that i am writing correctly to the TX memory buffer and indeed sending it to the web browser. However as i mentioned earlier, after i wrote over mike's code in the EEPROM, all the web page does is just linger until i close the socket and it stops trying to connect, never really times out.

    if someone has any idea on what i may be doing wrong i'd appreciate it. I feel it's something to do with my HTML... i've spent a while working on my own SPI driver that's all in spin and i feel like i'm on the 5 yard line and just can't punch it in.

    THanks,

    P.S. does anyone know of another simple SPI driver that is around that doesn't depend on assembly or on the SPI and Indirect Driver already posted?
    1024 x 640 - 143K
  • Mike GMike G Posts: 2,702
    edited 2011-09-10 07:30
    Repeated content is an indication that the socket is not closed. The code is looping flushing the same buffer over and over... I've this situation many times.

    The garbled text indicates writing an unexpected block of EEPROM to the Tx buffer, probably a pointer issue.

    The Content-Type: header tells the browser what kind of content to expect; image, text, JavaScript... In my experience, Content-Type errors show as unexpected formatting or the browser asking to save a file.
  • AKruzelAKruzel Posts: 25
    edited 2011-09-10 08:54
    GOT IT WORKING!! issue was that for CRLF, i accidently had $13 and $10 instead of 10 and 13 in the string in the DAT file. I had to pull up a TCP test program to see what was being sent from the spinneret and that was it. This is a working but incomplete SPI driver that does NOT include assembly and requires ONLY the parallax terminal to function, no need to download several spin files or one of the SPI or Indirect drivers that requires executing assembly in SPIN. There is no checking for overflow in the memory registers and probably missing a few other things, i do realize there is a bit more to be done and i plan on addressing that, but if you want to get an idea of how to interface with the W5100 IC and read information from the internet and post simple HTML, this should do the trick.

    Here are a few notes:

    1. After sending data you can execute the LIVE function which is a function that lets you read and write to registers and helps with troubleshooting. There is a waitcnt command after sending so once you punch in your IP address and port into a web browser, you can quickly enable your terminal and read additional information.

    2. Reading information is currently commented out but if you want to see what is sent when typing into a web browser, you can uncomment it out.



    any questions, please feel free to ask and comment!
  • Mike GMike G Posts: 2,702
    edited 2011-09-10 08:57
    i accidently had $13 and $10 instead of 10 and 13
    Sorry, that was my fault :(
Sign In or Register to comment.