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.


Messages - aersek

Pages: [1] 2
1
utFAT / Re: SD Card Performance
« on: July 03, 2012, 11:33:57 AM »
There is no problem with multiple user accesses. FAT cache is allocated in mass_storage.c file, and all accesses to disk are made trough same FAT image in RAM. It's implemented in all functions that access FAT table (fnAllocateCluster, deleteClusterChain, fnNextSector...) reading it or writing to it. Good thing is that uTasker is round-robin approach OS, so only one task is running in moment, no other tasks are stored on stack, and because of that functions from mass_storage.c can't be called at same time from different tasks.

Best regards

Andrija

2
utFAT / Re: SD Card Performance
« on: June 28, 2012, 11:06:34 AM »
Writing performance can be enhanced with additional code for caching of FAT table in RAM. Mine colleague have developed these function, with an old 256MB card speedup was 3-4 times, from 4kB/s to 15kB/s. New cards are 5 times faster. With new high capacity, high speed speed cards speedup is not so drastically because bigger cluster size, but you can get at least twice of speedup. We were developed this using CF cards on parallel bus, but I believe that same thing is possible with SD cards.

Trick is that uTasker after every data write in file on card also write FAT sector and update file size. If you keep FAT sector temporary in RAM and update just RAM image, and keep file size also in RAM, you save much of time. Just save FAT on end of file or when you need to change FAT sector, file size save just on end of file, in closeFile routine. Problem is when you turn off power while file is open, and FAT is in RAM, we solved this with saving FAT image and size in NVRAM, so on power up is checked state of NVRAM FAT sector, and saved on card if necessary.

This is our proprietary code, and I can't share it, but idea is simple and it works great.

Best regards

Andrija

3
Do you have made any inspection yet, how much effort is needed for adapting existing Luminary Micro uTasker project to Concerto ARM+DSP? Our interest here is uTasker support of just ARM part of processor for etherent communication, because we have complete developed code and enviroment for TI 28x DSP processors which we use in few of our projects. Few weeks ago we have bougth development board with Concerto processor, but didn't find yet time to play with it.

Best regards

Andrija Ersek

4
µTasker general / Re: TCP ARP resolution issue
« on: March 16, 2011, 03:17:29 PM »
Another one problem which I have for some time and can't fix it:
Using telnet board based on ColdFire processor sends large amount of data. It sends it fast and PC TCP window become small. On this wireshark log PC is 192.168.1.100 and board 192.168.1.10.
Board instead of waiting to window become larger sends to much of data. It seems that board process frame 2329 (which inform board that window is 879) after sending frame 2330 (size of frame is 971, same to window size from frame 2326). In processing of frame 2329 board updates peers window size, bit peers window size is actually smaller for size of frame 2330. Because of late processing of ACK frame it sends next frame 2331 which is 879 bytes long and overfills peers input buffer.


To avoid this situation I have changed in function fnHandleTCP next line
#ifdef SUPPORT_PEER_WINDOW
//      ptr_TCP->usTxWindowSize = rx_tcp_packet.usWindowSize;             // save the present windows size advertised by the peer
   ptr_TCP->usTxWindowSize = rx_tcp_packet.usWindowSize-(ptr_TCP->ulNextTransmissionNumber-rx_tcp_packet.ulAckNo);
#endif

With this change I don't get buffer overfill any more, but now have error in processing silly window situation.



In fnSendBufTCP routine Silly window situation is detected and then is send empty TCP frame 1473 with flags PSH and ACK. Then on retransmition call of function fnSendBufTCP(Socket, 0, 0, TCP_BUF_REP) returns 0 after which connection is closed.

5
µTasker general / Re: TCP ARP resolution issue
« on: March 16, 2011, 07:20:12 AM »
GPRS modem is connected to board using etherent cable, it is independent device which acts similar to ADSL modem router, just using GPRS. Modem and board are powered up, for first time board is accessed over internet, so modem and board have updated their ARP-s. After that happen reset on board, modem still has board MAC in ARP table, but board has empty ARP table. In that situation I access board again over internet, modem directly forward SYN to board without ARP, but board before returning SYN ACK need to resolve default gateway (modem) MAC. In this situation happen issue from first post.

Best regards

Andrija

6
µTasker general / TCP ARP resolution issue
« on: March 15, 2011, 02:49:47 PM »
Hello

We were testing our uTasker telnet implementation over internet. As internet gateway is used GPRS modem. After reset of module, on received SYNC from telnet client uTasker had sent ARP resolution to find MAC of gateway. On reception of ARP resolution from gateway uTasker didn't send SYC ACK frame. To fix this situation I have changed tcp.c code:

extern void fnTaskTCP(TTASKTABLE *ptrTaskTable)
{
    QUEUE_HANDLE PortIDInternal = ptrTaskTable->TaskID;                  // queue ID for task input
    unsigned char ucInputMessage[MEDIUM_MESSAGE];                        // reserve space for receiving messages

    while ( fnRead( PortIDInternal, ucInputMessage, HEADER_LENGTH )) {   // check input queue
        switch ( ucInputMessage[ MSG_SOURCE_TASK ] ) {
            case TIMER_EVENT:
                fnPollTCP();                                             // do TCP management on a periodic basis
                uTaskerMonoTimer( OWN_TASK, T_TCP_PERIOD, E_POLL_TCP );  // restart the timer
                break;

            case TASK_ARP:
            {
                TCP_CONTROL *ptr_TCP = tTCP;
                fnRead( PortIDInternal, ucInputMessage, ucInputMessage[MSG_CONTENT_LENGTH]);// read the contents
                switch (ucInputMessage[ 0 ]) {                           // ARP sends us either ARP resolution success or failed
                case ARP_RESOLUTION_SUCCESS:                             // a TCP socket is owner of resolved address
                    ptr_TCP += ucInputMessage[ 1 ];                      // extract the socket reference
                    if (ptr_TCP->ucTCP_state == TCP_STATE_SYN_SENT) {    // ARP resolve on connection establishment    
                        #ifdef ANNOUNCE_MAX_SEGMENT_SIZE                 // TCP socket waiting for connection
                        fnSendSyn(ptr_TCP, TCP_FLAG_SYN);                // send SYN with MSS announcement
                        #else
                        fnSendTCPControl(ptr_TCP);                       // resent because IP address has just been resolved
                        #endif
                    }
                 else if (ptr_TCP->ucTCP_state == TCP_STATE_SYN_RCVD) { // next state is SYN_RCVD where an ACK will establish the connection
                  #ifdef ANNOUNCE_MAX_SEGMENT_SIZE
                        fnSendSyn(ptr_TCP, (TCP_FLAG_SYN | TCP_FLAG_ACK));     // send SYN, ACK with MSS announcement
                  #else
                        ptr_TCP->ucSendFlags = (TCP_FLAG_SYN | TCP_FLAG_ACK);  // prepare flags to be transmitted
                        fnSendTCPControl(ptr_TCP);                             // send SYN, ACK
                  #endif  

                    }

                   else {
.
.
.


Is this correction OK? With this adaptation everything works fine.

7
µTasker general / Re: Unexpected delay in uTasker simulator
« on: April 08, 2010, 05:36:45 PM »
No, ping response times are between 4 and 15 ms, not less than ms like on target. It's from first day of using simulator but I didn't take care about it since now when I need to transfer few MB of data. I'll check Sleep function and test simulator on another PC.

Regards, Andrija Ersek

8
µTasker general / Unexpected delay in uTasker simulator
« on: April 08, 2010, 12:16:05 PM »
During testing of my application in uTasker simulator I found that data transfer between uTasker server application and client take 5 – 6 more time than same transfer between Windows server and client. I found in Wireshark log that every uTasker response (even on telnet, ping, ftp, web) happens 5 – 15 ms after received request, and that slows down data transfer speed dramatically. When I compile and download code to target processor all delays are around 1ms what is expected. I expected better response time from simulator which is running on XX GHz processor than response of 60MHz ColdFire. I understand that Windows are not real time system, but how then PC server application has immediate response and uTasker simulator has not?

Best regards

Andrija Ersek

9
I have 5282 EVB but on it I have made initial development tests of our software before usage of uTasker. I started using uTasker when I was working for half year on custom hardware and didn't work port on EVB. For all portings as I see you only need to change files in Hardware folder and some application files. If you port to similar processor (5282, 5329 ...) you need just to change bunch of definitions, some of initialization code and add some driver functions for unsupported parts of processor, but 90% of drivers will work without any change. Some porting tips you can get in this theme http://www.utasker.com/forum/index.php?topic=281.0.

Regards

Andrija Ersek

10
I'm using uTasker with MCF5282. Porting was not hard because I know from earlier very good this processor, about 3 days of work. Flash in MCF5282 is organized in 2kbyte blocks and all uTasker flash driver capabilities can be user withouth any problem, uParameterSystem and uFileSystem. I can acknowledge that flash driver operates correct without any modifications. Diferences between MCF52233, MCF52259 and MCF5282:
MCF5282 processor main specificity:
- has probably almost same FEC, UARTa, CAN, DMA timers, FLASH, SRAM, PIT, QSPI, I2C... interfaces as other ColdFire processors
- has internal 2kB cache
- has different ADC
- has different GPIO ports
- has 2 GPT timers
- has not PWM, PHY, USB, additional EdgePort
- has different power management system
- has full scale external bus interface with 7 chip-selects, 24bit address bus and 32bit data bus
- has SDRAM controller with 2 SDRAM chip selects
- has DMA controller memory map little bit different than DMA controller on MCF522XX but with almost same functionality; big disadvantage of DMA is bug in silicon because of which DMA can not be used for UART transmit directly; instead of that you need to use DMA timer with timeout period same to character send time to fire DMA controller on every character if you want DMA supported UART transmit.

To port uTasker to MCF5282 you need mainly change M5223X.h, M5223.c, app_hw_m5223x.h and config.h. You can use most of drivers withouth any changes, biggest digerence is in UART DMA, but you u can use UART in interrupt mode without any changes. In M5223X.h you need to add external bus interface registers, GPIO port registers, defin PLL frequencies, chang interrupt vector table, add PHY registers definition, add new DMA definitions, add second GPT, add SDRAM controller and defferent ADC, change interrupt vector table... Somewhere in early initialization code before any usage of uMemset, uMemcpy, uMalloc you should add this: MPARK = 0x33e100 to enable BCR24BIT and M2_P_EN.
For last few months I'm planing to send to Mark mine MCF5282 uTasker base reference project, but still I didnt, I'll send it during next week. I planed to finish it so it can be used by anybody as real reference project, but I newer finished it.

Best regards

Andrija Ersek

 

11
I didn't tried Codewarrior 7.2 but I have found few posts on freescale forum about bug and problems with compiling in CW 7.2, so for now is best to still use 7.1 version. On freescale web can be downloaded beta version of Codewarrior 10.0, it is completely new concept, it is Eclipse based IDE, maybe there are solved compile optimizations problems.

Regards

Andrija

12
Tutorial on http://www.cambridgeimaging.co.uk/whitepapers.php is not any more available. Do you have it saved? Can you please put it on uTasker forum?

Regards

Andrija

13
ColdFire UART also have possibility to disable RTS line automatically after finish of transfer.
From another forum http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=30&query.id=129543#M30

I've just been experimenting with this very feature on a MCF5213. This chip requires the following:
- When setting up the serial port, enable the TxRTS bit in UMR2 and set the bit(s) in the pin assignment register for the GPIO port that makes the pin work as a RTS output.
- When sending a group of characters, enable the transmitter by writing 0x04 to the UCR register, and manually assert RTS by writing 0x01 to the UOP1 register (RTS is active low, so this actually takes the output low) before writing anything to the transmit register.
- After writing the last character to the transmit register, disable the transmitter by writing 0x08 to the UCR register.
All of the described actions are necessary. Omitting any one of them results in the RTS output not functioning as intended.
One should be aware that the serial ports in different ColdFire derivatives aren't all identical. Sometimes there are significant differences. Read the manual carefully and don't automatically assume things will work as you're used to from another ColdFire variant.   

14
utFAT / Re: CF card support
« on: January 23, 2010, 08:28:43 PM »
As I see uTasker project is mainly oriented to let say it simple ethernet supported consumer applications. Another market also looking for low footprint easily adaptable ethernet communication software base. That are industrial control applications (my area of interest) which can use uTasker as background process of higher priority RTOS which manages main control application. In system like that uTasker is responsible for communication and non real time control. In projects on which I'm working motto is "make it as simple as possible". Because of that uCLinux and other packages like that are not option.

Currently we are planning one future project which will have mass storage capability. On hardware side are possible SPI interface (SD cards) and parallel interface (CF cards). We didn't decided which type of cards we will use, but maybe we will add CF card support in uTasker for our project if decide it. Plans are little bit long term and this discussion is part of research for possible options.

Thanks on good overview and discussion  :)

Best regards

Andrija

15
utFAT / Re: CF card support
« on: January 23, 2010, 10:18:53 AM »
Ok, I understand that main target of uTasker are small integrated processors, but it is very powerful and can also be used in higher class of processors. It's very simply to port it on other processor of similar family. Currently we use it on MCF5282 which is not supported by uTasker but in few days of adapting we get all functionality which we needed. Also I suppose that it would not be hard to port it to more powerful processors like ColdFire V3 or V4 in near future if we decide that is needed more powerful processor for our projects. I suppose that similar situation is with AVR and ARM cores supported by uTasker.

CF card interface hardware is not complicated and CPLD isn't necessary to create it. MCF5329 evaluation board from LOGICPD has CF interface realized just using standard parallel bus with one transistor and one inverter on single control line. On software side CF driver is almost absolutely portable because it used simply parallel interface and is not dependent on some processor specific interface (like SPI). Maybe would be more customers who will want to use higher performance CF interface in their projects.

Best regards

Andrija

Pages: [1] 2