Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
06/13/06 08:56
Read: times


 
#118203 - Buffer management optimalization
Hi everyone,

I am having a 8052 MCU core chip and I am working with ultra-low power application.
I am implementing the physical layer of an air communication protocol and there I would need some help.

The MCU receives different packages with different sizes and different structure. To ensure reliable transfer, each package is sent several times and also it is received several times. Repetation of the same package we could call repeatepackage. The time constant between sending repeatpackages is random to avoid collision in the air from different senders.

The packages have the following structure:

__________________
|..................| 4bytes
------------------

__________________________
|.........................| 5bytes
---------------------------

________________________________
|................................| 6bytes
--------------------------------

________________________________
|................................| 9bytes
--------------------------------


The problem I am having is with the storage and the management of these packages in a buffer:
The solution what I am using is the follwing:

I am having 5x buffer storage space with size 13 bytes.
The first 3 bytes are flags showing the status of the buffer:
1. free-flag - wether the buffer is free or not
2. timeout - how long should we wait for repetition package
3. repetition - how many times did the repeat package arrived

When a new package is received it's checked wether it exists in aby of the 5 buffer. This check is made in a form that each byte of the received package is compared whit those stored in the buffer. If the same package is found the repetition number is increased. There is a certain timelimit that repetition packages can arrive if this time limit ellapses the package is not more valid and the clear flag is set.

The curent solution is easy to implement, to debug but I guess it's unneficient.
It has several drawbacks.
1. When a package with size 4bytes arrives and I put it to the 13byte buffer I am loosing memory
Another solution would be to use a chained list and not hard allocate the buffers, but than I will have fragmentation problems.
I.e. When a 4byte package is not more valid and another 9bytes package arrives which I need to put in the middle of the buffer.

2. Each time a new package arrives I have to compare it to all the buffers to find wether it exists or not.
A solution would be a hash-table but I couldn't find an apropriate algorithm which would be faster than comparing all the bytes.

3. If a new package type with size 15bytes will be defined I have to change the default buffer size.

So I would appritiate any ideas how could I handle the package management more efficient. My problem is I have really
few energy, so I have to be as fast as possible. Also I am limited with the memory, I am using the upper 128 bytes
of IDATA of the 8052 architecture for the buffers.

Thank you very much,

greetings

Attila

List of 21 messages in thread
TopicAuthorDate
Buffer management optimalization            01/01/70 00:00      
   Simple things first ...            01/01/70 00:00      
   You can use circular buffer            01/01/70 00:00      
      Fragmentation problem...            01/01/70 00:00      
         all methods have some problems            01/01/70 00:00      
         Start of package or End of package            01/01/70 00:00      
            Packages explanation            01/01/70 00:00      
               Individual buffers            01/01/70 00:00      
                  Good Idea            01/01/70 00:00      
   New packages            01/01/70 00:00      
      hash table unefective            01/01/70 00:00      
         why keep that many            01/01/70 00:00      
            Reason of 5 or more buffer            01/01/70 00:00      
               Protocol specifics            01/01/70 00:00      
                  One way protocol            01/01/70 00:00      
                     One way protocol            01/01/70 00:00      
                        never            01/01/70 00:00      
                           Definition of need            01/01/70 00:00      
                              Grant, I agree with what you post re thi            01/01/70 00:00      
                        Simply reason why one way transmission            01/01/70 00:00      
                           then why not just do it the easy way            01/01/70 00:00      

Back to Subject List