1
µTasker general / Re: handle tcp data until a task is ready
« on: August 30, 2010, 09:39:29 AM »
Thanks again Mark, it's perfect with this technique !
News:
Nov 2020: uTasker i.MX RT V1.4.12 is productive - with complete secure loading concept.
Follow uTasker updates at www.twitter.com/uTasker !!
Online Forum registration has now been disabled. Please send an email to an address at the bottom of the home page with your preferred user name and email address if you would like an account.
Return to uTasker main site: www.utasker.com
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
µTasker general / handle tcp data until a task is ready
« on: August 27, 2010, 03:51:10 PM »
Hi Mark,
Here is my case :
I handle ethernet data from my TCP listener, then I start to analyze data to know which other task need to receive this data. I had big queues in the tasks and I limited TCP_DEF_MTU in order to make it smaller than the task buffer. So if my handler is called once, the destination task receive all data. If the ethernet data comes slowly, the destination task is still launched between every handler so everything is still good. The problem appears when data comes very quickly, the handler is launched more than once and when it try to send data to the task, the queue is full.
I need to call the handler again, with the same data, when destination task has freed it queue. I'm sure other people may have the same issue but I can't find in the docs or in the forum how easily make it wait to try again, and never lost data.
Thanks if you could give me some advice.
Here is my case :
I handle ethernet data from my TCP listener, then I start to analyze data to know which other task need to receive this data. I had big queues in the tasks and I limited TCP_DEF_MTU in order to make it smaller than the task buffer. So if my handler is called once, the destination task receive all data. If the ethernet data comes slowly, the destination task is still launched between every handler so everything is still good. The problem appears when data comes very quickly, the handler is launched more than once and when it try to send data to the task, the queue is full.
I need to call the handler again, with the same data, when destination task has freed it queue. I'm sure other people may have the same issue but I can't find in the docs or in the forum how easily make it wait to try again, and never lost data.
Thanks if you could give me some advice.
3
µTasker general / Re: TCIP
« on: August 26, 2010, 02:43:19 PM »
Thank you so much. We used to interpret PARTIAL_ACK as an ACK...so yes, your explanation help us !
4
µTasker general / Re: TCIP
« on: August 05, 2010, 04:11:39 PM »
Hello Mark,
Here is my question concerning the previous picture, according to the fact that uTasker see the TCP flow as below :
[-----------------PC-------------------] [----------------LPC2387---------------]
seq ack frame number length direction length frame number seq ack
177 25 24 133 >>>
<<< 0 25 25 310
<<< 8 27 25 310
310 25 26 133 >>>
<<< 0 28 25 443
<<< 8 29 25 443
443 33 30 0 >>>
When uTasker receive the frame 26, does it know that the seq=310 is acknowledging the frame 25 and not the 26 ? Because, we are able to check it, thanks to the next ack number counting. It should be 25+8=33 if it had acknowledging the frame 27. But here it is 25+0=25.
The problem is that in our application stack, we are waiting for a tcp ack before sending the frame 28, but we are mistaking about the TCP_EVENT_ACK interrupt (get from the 26 but concerning only the 25). Thus we thought the the TCP_EVENT_ACK is acknowledging the 27 and we send the 28 (TCP ACK for the 26) the the 29 (PUSH ACK).
On the PC side, the frame 27 is received after the 26. And the 27 is never acknowledged. Does the PC think that it is a retransmission of the 25 already acknowledged ?
Because it should check that the lenght and the TCP flag (ACK/ PUSH ACK) are different between the 25 and 27.
I hope you understand my explanation and I thank you in advance.
Here is my question concerning the previous picture, according to the fact that uTasker see the TCP flow as below :
[-----------------PC-------------------] [----------------LPC2387---------------]
seq ack frame number length direction length frame number seq ack
177 25 24 133 >>>
<<< 0 25 25 310
<<< 8 27 25 310
310 25 26 133 >>>
<<< 0 28 25 443
<<< 8 29 25 443
443 33 30 0 >>>
When uTasker receive the frame 26, does it know that the seq=310 is acknowledging the frame 25 and not the 26 ? Because, we are able to check it, thanks to the next ack number counting. It should be 25+8=33 if it had acknowledging the frame 27. But here it is 25+0=25.
The problem is that in our application stack, we are waiting for a tcp ack before sending the frame 28, but we are mistaking about the TCP_EVENT_ACK interrupt (get from the 26 but concerning only the 25). Thus we thought the the TCP_EVENT_ACK is acknowledging the 27 and we send the 28 (TCP ACK for the 26) the the 29 (PUSH ACK).
On the PC side, the frame 27 is received after the 26. And the 27 is never acknowledged. Does the PC think that it is a retransmission of the 25 already acknowledged ?
Because it should check that the lenght and the TCP flag (ACK/ PUSH ACK) are different between the 25 and 27.
I hope you understand my explanation and I thank you in advance.
5
NXPTM LPC2XXX and LPC17XX / Re: bigger files with uFileSystem
« on: May 15, 2009, 10:45:43 AM »
that's what I was missing ! If I'm right : 62 files are supported with names from "0" to "9" then from "A" to "Z" and then from "a" to "z". And in each file, it is necessary to keep 5 bytes free for header overhead, isn't it ?
Everything is ok, now I'm going to use my ATMEL SPI flash.
Thanks again.
Everything is ok, now I'm going to use my ATMEL SPI flash.
Thanks again.
6
NXPTM LPC2XXX and LPC17XX / Re: bigger files with uFileSystem
« on: May 14, 2009, 04:53:44 PM »
ok Mark, it was my mistake. UART is ok now and storing a 980kB file in my 1MB SPI flash seems to be ok.
Here is my problem : my configuration (with my STM25P80 code flash) should allow me to use 16 files up to 65536 kB or 2 files up to 512k. But, when I try to copy on the FTP the 9 webpages, it only keep the last 5. When trying to copy 2 files of 504k, it only keep the last one.
Here is my configuration :
in config.h:
-#define SPI_FILE_SYSTEM
-#define FLASH_FILE_SYSTEM
-#define SPI_FLASH_ST
-#define FILE_GRANULARITY (SPI_FLASH_BLOCK_LENGTH)
in app_he_lpc23xx.h :
--#define SPI_FLASH_SECTOR_LENGTH (256*SPI_FLASH_PAGE_LENGTH) //code flash and not data flash
-#define SPI_FLASH_BLOCK_LENGTH SPI_FLASH_SECTOR_LENGTH //64kB
-#define SPI_FLASH_START (FLASH_START_ADDRESS + SIZE_OF_FLASH)
-#define PAR_BLOCK_SIZE (2*PARAMETER_BLOCK_SIZE)
-#define uFILE_START (SPI_FLASH_START - PAR_BLOCK_SIZE) //param in internal flash
-#define SINGLE_FILE_SIZE (FILE_GRANULARITY) //64kB
-#define FILE_SYSTEM_SIZE (16*SINGLE_FILE_SIZE+ PAR_BLOCK_SIZE) //16*64kB=1024kB=1MB reserved for file system (plus parameter blocks)
Am I missing something ?
Thanks.
Here is my problem : my configuration (with my STM25P80 code flash) should allow me to use 16 files up to 65536 kB or 2 files up to 512k. But, when I try to copy on the FTP the 9 webpages, it only keep the last 5. When trying to copy 2 files of 504k, it only keep the last one.
Here is my configuration :
in config.h:
-#define SPI_FILE_SYSTEM
-#define FLASH_FILE_SYSTEM
-#define SPI_FLASH_ST
-#define FILE_GRANULARITY (SPI_FLASH_BLOCK_LENGTH)
in app_he_lpc23xx.h :
--#define SPI_FLASH_SECTOR_LENGTH (256*SPI_FLASH_PAGE_LENGTH) //code flash and not data flash
-#define SPI_FLASH_BLOCK_LENGTH SPI_FLASH_SECTOR_LENGTH //64kB
-#define SPI_FLASH_START (FLASH_START_ADDRESS + SIZE_OF_FLASH)
-#define PAR_BLOCK_SIZE (2*PARAMETER_BLOCK_SIZE)
-#define uFILE_START (SPI_FLASH_START - PAR_BLOCK_SIZE) //param in internal flash
-#define SINGLE_FILE_SIZE (FILE_GRANULARITY) //64kB
-#define FILE_SYSTEM_SIZE (16*SINGLE_FILE_SIZE+ PAR_BLOCK_SIZE) //16*64kB=1024kB=1MB reserved for file system (plus parameter blocks)
Am I missing something ?
Thanks.
7
NXPTM LPC2XXX and LPC17XX / Re: bigger files with uFileSystem
« on: May 13, 2009, 04:42:12 PM »
Mark,
uTasker is great ! I need to learn a lot about it but I succeed in using an external flash (I found a STM25P80) with my MCB2300 for storing big files. And I used telnet as a debug output. Amazing !
Now I want to use an UART as a debug output (I failed this evening) and use another SPI flash.
Sometimes I can't delete files on my SPI flash. Do you know this problem ?
Anyway, thank you so much.
Aurélien
uTasker is great ! I need to learn a lot about it but I succeed in using an external flash (I found a STM25P80) with my MCB2300 for storing big files. And I used telnet as a debug output. Amazing !
Now I want to use an UART as a debug output (I failed this evening) and use another SPI flash.
Sometimes I can't delete files on my SPI flash. Do you know this problem ?
Anyway, thank you so much.
Aurélien
8
NXPTM LPC2XXX and LPC17XX / bigger files with uFileSystem
« on: May 12, 2009, 04:28:26 PM »
First of all, I've read "uTaskerFileSystemSPI_FLASH_003.pdf", "uTaskerFileSystem_3.pdf", "FileSystemLPC23xx_336k.doc", and "FileSystemLPC23xx.doc". But there is something I'm still not understanding.
According to "uTaskerFileSystem_3.pdf", by specifying MAX_FILE_LENGTH as an unsigned long, we allow individual files larger than 64k. Then in "FileSystemLPC23xx_336k.doc", you say that "Files of multiple 4k lengths can also be saved. The final file ‘z’ can have a length of up to 136k".
But when I launch simulation, if I try to send by FTP a 128kB file "z.HTM", it failed (simulator is crashing). On my target (MCB2300 KEIL), it looks better. 137kB HTML file is quickly sent and reachable by HTTP. So it was just a bug on the simulator.
Now, I want to use my 4MB SPI flash to store and set 2 files of 1 MB. At the moment, I can't use the simulator anymore and I'm going to try with my MCB2300 and a 1MB SPI flash (AT26DF081).
So, concerning external SPI flash and according to "uTaskerFileSystemSPI_FLASH_003.pdf" :
- uFileSystem allow up to 64 files
- SINGLE_FILE_SIZE is a multiple of FILE_GRANULARITY (4096 bytes granularity in my case) and could be set to 64*FILE_GRANULARITY to allow 256kB file.
- FILE_SYSTEM_SIZE could be set to (2*SINGLE_FILE_SIZE + PAR_BLOCK_SIZE) to reserve 512MB for file system (plus parameter blocks).
In your opinion, could it work ?
Thanks, I'll give you results after performing some tests.
According to "uTaskerFileSystem_3.pdf", by specifying MAX_FILE_LENGTH as an unsigned long, we allow individual files larger than 64k. Then in "FileSystemLPC23xx_336k.doc", you say that "Files of multiple 4k lengths can also be saved. The final file ‘z’ can have a length of up to 136k".
But when I launch simulation, if I try to send by FTP a 128kB file "z.HTM", it failed (simulator is crashing). On my target (MCB2300 KEIL), it looks better. 137kB HTML file is quickly sent and reachable by HTTP. So it was just a bug on the simulator.
Now, I want to use my 4MB SPI flash to store and set 2 files of 1 MB. At the moment, I can't use the simulator anymore and I'm going to try with my MCB2300 and a 1MB SPI flash (AT26DF081).
So, concerning external SPI flash and according to "uTaskerFileSystemSPI_FLASH_003.pdf" :
- uFileSystem allow up to 64 files
- SINGLE_FILE_SIZE is a multiple of FILE_GRANULARITY (4096 bytes granularity in my case) and could be set to 64*FILE_GRANULARITY to allow 256kB file.
- FILE_SYSTEM_SIZE could be set to (2*SINGLE_FILE_SIZE + PAR_BLOCK_SIZE) to reserve 512MB for file system (plus parameter blocks).
In your opinion, could it work ?
Thanks, I'll give you results after performing some tests.
Pages: [1]