Topics

1

NXP^TM LPC2XXX and LPC17XX / Receiving UDP packets at a rate of 10ms

« on: November 05, 2014, 02:26:01 PM »

Hi Mark,

I am facing a problem regarding the UDP reception.

So far I have been sending UDP data blocks periodically (from within the main loop) and have been receiving nonperiodic commands per UDP. That is all ok. Nothing to complain.

Now I created an additional socket to receive UDP data periodically from a sensor. The data is sent every 10ms, I could check that with WireShark. The problem is that the listener function is not called at the same interval. Instead it is called for instance 5 times every 100...200µs (1 data packet per call), but the next five data packets are delivered 50ms later. So 5 packets per 50ms is ok if one only looks at the amount of data. It seems that no data gets lost.
Obviously µTasker is optimizing how often the listener function is called.

This is how the socket is obtained:
  scUdpMotionSocket = fnGetUDP_socket(TOS_MINIMISE_DELAY,
    fnUdpMotionListener,
    0                     
    | UDP_OPT_CHECK_CS); 

I thought that the parameter TOS_MINIMISE_DELAY might have something to do with the problem, but the function description says that this parameter is not used. (I am using µTasker V1.4.)

The problem is that I need actual data.
Is there a way to "persuade" µTasker to call that special listener function immediately when data is received, i.e. every 10ms?
Or even better, to call the listener on request. I only need the most recent data package. In that  case it would not matter if 5 packets were sent as a group.


Kind regards,
Martin H.

2

utFAT / How to detect if SD card formatting has finished

« on: March 27, 2014, 11:26:20 AM »

Hi Mark,

Referring to uTasker_utFAT.pdf/V0.09 I would like to add the re-format and fformat features to a LPC2468 project.
The function utFormat() returns UTFAT_SUCCESS if the formatting/re-formatting has started successfully.
But as formatting can take some time, is there a way to find out if formatting has finished so that new files can be written?

utDeleteFile() deletes single files. I suppose this function cannot be used to delete several files in the root by specifying files using wildcards? Something like *.* or obj*.* ?

Regards,
Martin

3

NXP^TM LPC2XXX and LPC17XX / FTP access to SD card

« on: September 06, 2013, 12:15:09 PM »

Hello,

with my LPC2468 project, which is based on uTasker vs.4, I am able to update the code using ftp (BARE MINIMUM BOOTLOADER).
Now I have implemented mass_storage.c from uTasker vs.8 and I can create files and perform write and read operations to/from a 32GB SD card.

The problem is that it is no longer possible to get a FTP connection.
That means the Bare Minimum Bootloader cannot be used any longer (which was fine before) and there is no access to the SD card via FTP of course.

fnConfigureFtpServer() still is reached (invoked from the application task), but fnFTPListener() is not.
I have tracked the problem down to fnTaskEthernet():
  When the FTP connection is initiated on the client side, fnTaskEthernet() receives IP_UDP instead of IP_TCP.
   
Compared to the version that is running (ftp ok, mass_storage.c not implemented) just 'R' has been added (TASK_MASS_STORAGE):
W, A, E, T, a, R, D, d, S, X, V

Does anybody have an idea what might have gone wrong?
Any suggestions how to procede are highly appreciated!

Regards,
Martin
attached: TaskConfig.h

4

NXP^TM LPC2XXX and LPC17XX / Performance of TELNET like protocoll

« on: June 12, 2013, 02:55:52 PM »

Hi Mark,

I am currently testing the TELNET like protocol for data transfer to a TCP client. The aim is to achieve a maximum transfer rate and retransmission if necessary.

The task
  fnSendTelnetCmd(TTASKTABLE *ptrTaskTable)
is invoked periodically every 50ms.

This task checks if buffer is available
   jj = fnSendBufTCP(Tx_Telnet_Socket,(unsigned char *)&OurTask, TelTx.usLen, TCP_BUF_CHECK);

and if so it transfers the data:
  if (jj >0) {
qt = fnSendBufTCP(Tx_Telnet_Socket, (unsigned char *) &TelTx.Buf , TelTx.usLen,  (TCP_BUF_SEND  |  CP_BUF_SEND_REPORT_COPY)   );

    }

The following settings have been left unchanged:
    #define TCP_BUFFER  2800   
    #define TCP_BUFFER_FRAME      1400

Everything is ok as long as 2100 or less bytes have to be transferred, i.e. every 50ms that amount of data goes out in 2 blocks - 1 is 1400 bytes long and the other one contains the remaining bytes. For instance 2100-1400=700 bytes.
I have checked that with WireShark.

Greater payloads lead to jj=0 (check for  available buffer size). jj then is 0 for several periods. No data is sent.

The decision whether or not to return 0 is made here in fnSendBufTCP():

#ifdef WAKE_BLOCKED_TCP_BUF 
if (tcp_tx->usWaitingSize + tcp_tx->usPacketSize + usDataLen > TCP_BUFFER) {
            tcp_tx->WakeTask = *ptrBuf;                // mark task to wake when buffer free
            return 0;                                       // not enough space to send intended buffer
        }
        else { …}
 }
 #endif

where
  tcp_tx ->usWaitingSize = 0
  tcp_tx->usPacketSize = 900 = 0x384
  usDataLen = 2300

tcp_tx->usPacketSize seems to be the second block that not yet has been sent.
What could be the reason for that?
Is it a missing ACK? How should that be handled?

I could try to run fnSendTxBuf() several times with usDataLen<=1400, i.e. activate the Task and run uTaskerSchedule() several times
But is that really the recommended procedure?


Regards,
Martin

5

NXP^TM LPC2XXX and LPC17XX / TCP_WINDOW_UPDATE received by FTP listener

« on: June 03, 2013, 10:21:16 AM »

Hi Mark,

we are using uTasker's ftp-server to update the embedded application. Together with TotalCommander this does a good and reliable job.
Now we intend to integrate TotalCommander's part into the application that runs under Windows using the Indy ftp-client from C++ Builder XE4.
That does not work.
I compared the events received by fnFTPListener() and found that our Windows application (created by C++ Builder, i.e.the Indy ftp-client) sends
event 0x0B (TCP_WINDOW_UPDATE), which TotalCommander does not do.
This happens at a very early stage:
   events received
   08   TCP_EVENT_CONREQ
   02   TCP_EVENT_ACK
   04   TCP_EVENT_DATA
   0b   TCP_WINDOW_UPDATE
   ...
Indy's documentation offers several settings for the ftp-client but it is very unprecise about which one to chose.

Ignoring this event on uTasker's side by adding 'case TCP_WINDOW_UPDATE: break;' to the event listener did not help.

I understand that this event is used for flow control between the peers, but the question remains how uTasker should react.
Or - as 0x0B obviously is not required - perhaps somebody knows (or could give some hints) what settings are required for creating the ftp-client.

Regards,
Martin H.

6

NXP^TM LPC2XXX and LPC17XX / SD card: Boot sector not readable

« on: March 20, 2013, 02:24:03 PM »

Hello,

I am just trying to adapt parts of mass_storage.c from version 8 to my project (derived from version 4, LPC2468).
The SD card I am using is a Kingston SDHC 4GB class 4 card.
MCIClk has been raised to 18MHz. The card shall run in 4-bit-mode, no DMA so far.

The problem is that the bootsector cannot be read.
In _fnGetSector() the condition
    (MCIStatus & RxDataAvailbl)
never is met, which results in an infinite loop.

The SDHC card has been formatted (FAT32) by WINDOWS, hence it has no password and is not locked I should think.

The initialisation phase is passed without obvious problems.

Coming to Cmd16, I found that the command array is
static const unsigned char ucSET_BLOCK_LENGTH_CMD16[5]  = {SET_BLOCKLEN_CMD16, 0x00, 0x02, 0x00, 0x02};
It seems that the block size here is >512 bytes which results in setting the BLOCK_LEN_ERROR bit.
But as SDHC cards always use a block size of 512 bytes this may not be important.

READ_SINGLE_BLOCK_CMD17 is passed with ucresult==0.
But with the following function
fnGetSector(ptr_utDisk->ptrSectorData)
the infinite loop in _fnGetSector() is reached.

Can anybody thing of a reason why the boot sector cannot be read?

Regards,
Martin

7

NXP^TM LPC2XXX and LPC17XX / Ethernet DMA for LPC23XX project

« on: November 08, 2012, 09:17:05 AM »

Hello,

we are using the LPC23XX project to transfer data via ethernet (UDP protocol). Now that the amount of data has increased we are looking for a way to speed up transfer.
As a first step checksum calculation in fnSendUDP() has been cancelled.
That led to a transfer rate of 2,93ms per 11060 bytes, i.e. 265ns/byte as an average.

The next idea is to use DMA for transfering the data.
Has such an ethernet DMA transfer ever been realized with that LPC2XXX project?
Does anybody know of an appropriate project or can give some hints where to start?
Any comment would be welcome.

Martin H.