Copying string to a byte array

[Andrew S]

I'm trying to send a binary file stored on the SDCard to a webserver using HTTPCMD. Since the file could be fairly large I have to process it in pieces so I read some bytes into a byte array then send it to the webserver. The server can use a process called "chunked transfer encoding" which will allow me to make multiple HTTP PUT calls, each with a piece of the file I'm attempting to send. So far, so good.

Since chunked-mode isn't implemented in the BRX I'm 'rolling my own'. This means that I send the length of the data I want to transfer followed by a CRLF, then the data and finally another CRLF. This repeats until I'm done, when I send a final PUT with just CRLF. Certainly doable on the BRX.

Where I'm struggling is putting the pieces together to send out. My thought was to MEMCOPY the string containing the length and the initial CRLF to the front of the byte array, then copy in the data from the file, and then MEMCOPY another string with the back-end CRLF. This has presented a problem though - if I look at the front of the byte array there are additional characters in the high-order byte of the first word.

So - I'm trying to send "1000<CR><LF>" which is 49 48 48 48 13 10 in ASCII decimal notation. What I see is: 64 00 06 00 49 48 48 48 13 10

I know I could push the CRLF as values (MOVE 13 to byte array, same for 10) but I don't know how to convert the ASCII values to decimal.

I'd be grateful for ideas and/or suggestions.
Thanks, Andrew.

[franji1]

If you have all numeric integer data in ASCII, and you want binary representation, use STR2INT for each value.

[Andrew S]

The problem is that I need to stream the ASCII representation of the number, not the binary representation. I'll dig into the chunked-encoding docs some more - perhaps I missed something, but I believe I need to send the string not the integer.

[Andrew S]

I was wrong - it doesn't want the ASCII representation, it wants the length value in hex format. So I took an integer and MEMCOPY'd it to the buffer but it seems as though the bytes are reversed:
The number is 50000 which is 0xC350
The buffer shows 50 C3

What am I doing wrong?

[Andrew S]

I was able to make it work by MEMCOPYing individual bytes, but that seems like it could be messy. It's ok for the two bytes that I need for this application but is there a cleaner way to do it?

[Bolt]

There is a SWAPB instruction for swapping bytes (or words).

[Andrew S]

Definitely more elegant. Thank you.

I'm not seemingly able to make chunked-HTTP work with the BRX. Perhaps they'll add support in the future. In the meantime does anyone have any other ideas on how to send a large file to an HTTP server?

Andrew.

[BobO]

We envisioned HTTPCMD able to use the file system as a source and/or destination, time got in the way.

How big a file are you sending?

[Andrew S]

It varies. I've seen up to about 1MB but it could conceivably be larger. I'd think 5MB would be about the max.

[plcnut]

Is it a text file of some type?
I have code where I have done a bit of that.

[Andrew S]

It's a binary file. 

[BobO]

If you are just sending a file, the file content really isn't that relevant.

[Andrew S]

I can send the file in principle - I can read it in in chunks and fire HTTPCMD for those (50K) chunks. The problem appears to be that since I'm using chunked transfer-encoding there's something going on that stops the data being sent. I see the HTTP PUT on the wire and the header being sent, but not the data. Since it's chunked the webserver won't send the HTTP response until the last chunk has been sent so I suspect that there's something in the protocol negotiation that is required to allow this to work.

[BobO]

I can send the file in principle - I can read it in in chunks and fire HTTPCMD for those (50K) chunks. The problem appears to be that since I'm using chunked transfer-encoding there's something going on that stops the data being sent. I see the HTTP PUT on the wire and the header being sent, but not the data. Since it's chunked the webserver won't send the HTTP response until the last chunk has been sent so I suspect that there's something in the protocol negotiation that is required to allow this to work.

The instruction isn?t designed to be used this way and I give it a very low probability of working. You would do better to open the port and run the protocol yourself, which is what plcnut did and was offering assistance with. HTTP isn?t super complicated if you know what you are talking to.

I could see us adding file system support to HTTPCMD, but it would be sometime next year before it?s released.

[plcnut]

All you should have to do, is open the connection (TCPOPEN), and start sending your data (STREAMOUT).
The first line should contain the GET/POST/PUT header, then a space and the address to which you are sending.
There is more header info that can be added, but I don't know enough about your file type, or what you are sending it to.

You can then loop through a couple of stages that load the byte data into your buffer, and then send it out over TCP.
when you get to the end of the file, close the connection.

The client or server on the other end does not see how many "chunks" you are sending on the wire. The TCP protocol is packaging everything up and sending it in pieces anyway. 
It sounds like you may be complicating something that is actually pretty simple (been there done that).

If you need more header information, then let me know.
I do have more information stored away somewhere.