The Godfather talking
This is god damn my place! Capisci?
Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
March 29, 2024, 03:56:29 15:56


Login with username, password and session length


Pages: [1]
Print
Author Topic: Payload Buffer Size , Length , Data  (Read 6141 times)
0 Members and 1 Guest are viewing this topic.
SANEMB
Newbie
*
Offline Offline

Posts: 27

Thank You
-Given: 3
-Receive: 0


« on: November 04, 2009, 02:04:53 02:04 »

Hi Guys,

What is meant by "reserve PAYLOAD_BUFFER_SIZE (0x0800 is defined as default value) bytes as a reception buffer" , PAYLOAD Length , Payload data. How to write the C code for this.

Can anyone please help me on this.
Logged
sam_des
Senior Member
****
Offline Offline

Posts: 253

Thank You
-Given: 124
-Receive: 146


« Reply #1 on: November 04, 2009, 04:51:21 04:51 »

Hello SANEMB,

It seems you're writing some communication code.

PAYLOAD_BUFFER_SIZE - Total amount of ram reserved as Receive Buffer
PAYLOAD Length - It's total size of 'actual data' within 1 frame.
PAYLOAD Data    - It's the actual data of interest within 1 frame.

If you've written code for communications (typically asynchronous i.e. only data is transmitted & receiver generates it's own clock as per baud) you know that -
1) Receiver can get data at any time.
2) Received data may be out-of-order, corrupted, incomplete.
3) Data may be too large to transmit in one go.
4) Receiver may not be able to cope with all the incoming data at the rate of transmission.
5) There may be more than one receiver, more than one transmitter.
etc.. etc..

So you've what are known as 'Communication Protocols'. They define the rules which are adhered to by transmitter as well as receiver to successfully communicate with each other.

Typically these communcation protocols define, How data is transmitted as FRAMES. That's chunk of data+additional data. This additional data may include receiver address, frame no., crc, time-stamp, transmitter id, data id etc. This helps receiver(s) to correctly identify data addressed only for them, decode it, ask resend if it was corrupted.

Receiver seperates data within frame as 1) PAYLOAD that's the data we actually interested in & 2) Additional data. You can see any introductory book on TCP/IP or other comm. protocols, you'll get this in much more details.

As for defining them in C it is just as array - either of simple bytes or of some struct defined. This depends on protocol you're implementing.

I may add that please be more elaborative with your questions so that you may get more detailed answers.

Hope that helps,
sam_des
Logged

Never be afraid to do something new. Remember Amateurs built the Ark, Professionals built the Titanic !
SANEMB
Newbie
*
Offline Offline

Posts: 27

Thank You
-Given: 3
-Receive: 0


« Reply #2 on: November 06, 2009, 01:18:23 13:18 »

Hello Sam,

I really Appreciate your time & effort.

Please find the attached PDF which contains the communication frame format.

Now on the Master side , receiver would be receiving the this complete frame via UART interface . So now I want to separate this frame as given in the pdf for the further computation. Is it possible to separate the frame while receiving it self by declaring the structure variable & pointer. or shall i store the recieved frame in a buffer & later proceed for the seperation.

Could you please help me on the above issue.



   

Logged
sam_des
Senior Member
****
Offline Offline

Posts: 253

Thank You
-Given: 124
-Receive: 146


« Reply #3 on: November 10, 2009, 10:30:55 10:30 »

Hi,

You can do it either way. But I prefer to have FIFO buffer(queue) so that I can just dump whatever & whenver something arrives at UART. Call a support function 'regularly' to see if complete frame has been received & it is ok to proceed. That way ISR for UART is loaded lightly & you will never miss a byte.

There are couple of things to watch...
1) FIFO Buffer length must large enough to accomodate more than 1 frames if baud rate is high or communication can have sudden bursts.
2) You must be absolutely sure about interval at which support function is called to make sure that whatever deadlines are for acting on received data are always met. You must have detailed time map for your application.

There is another way which partially decodes the frame is ISR & passes reset of the data to buffer. For example, after long silence on RX line, if first byte received is not the 'frame start flag' there is no need to check further data unless another 'frame start flag' is received. Or if communication is address oriented, then simply ignore the frames not intended for that particular receiver.
But this dependes on your ISR loading & other application specific things.

Hope that helps...
regards,
sam_des
Logged

Never be afraid to do something new. Remember Amateurs built the Ark, Professionals built the Titanic !
SANEMB
Newbie
*
Offline Offline

Posts: 27

Thank You
-Given: 3
-Receive: 0


« Reply #4 on: November 20, 2009, 10:57:57 10:57 »

Hi Sam,

It is great to see your reply.  Smiley

This frame what I was telling which is for the communication between HID Electronic Ballast & Power line Modem for the Streetlight Control application. Please find the attached complete system Architecture.

Even though I am not software development background, I am trying to build the server Web application on .net platform for this Streetlight control application. I need some below clarifications on the s/w application frame work to start with.
 
Here Wireless IP Gateway device provides the configuration facilities for Dimming, ON/OFF, Scheduling, Alarm, Astronomical Clock, Sun
Rise/Set Time, Year Calendar & Time settings which all can be configured from the web application interface by the user.It also have the facility for online commissioning of node devices from the web application interface. Gateway must be able to control the whole network and each Node device individually. So every Node device must be uniquely identified.

Clarifications required :

1. Recommendation for the protocol Framework format for the data transfer between WIP Gateway server and the Streetlight Management server Software.

2. How should be the Data exchange format between the WIP Gateway and Streetlight Management Software (i.e. SOAP / XML, RAW, CSV etc.).

3. Is there is a need to use Middle layer components such as OPC / DDE.

4. Any valuable suggestions.

Look forward for your valuable reply




Logged
SANEMB
Newbie
*
Offline Offline

Posts: 27

Thank You
-Given: 3
-Receive: 0


« Reply #5 on: November 21, 2009, 02:36:19 02:36 »

Hi Sam ,

I need clarifications for one more thing.

Currently I have written this communication frame for 8 Bit controller ( 8051) in Receiver side. But it is having only the RAM of 256 Bytes where this application needs to have the default Payload  buffer size of 0x0800.

So how can I do that. Could you please help me on that.

Have a gr8 day
Logged
mick
Active Member
***
Offline Offline

Posts: 228

Thank You
-Given: 1984
-Receive: 119


« Reply #6 on: July 18, 2010, 01:04:54 13:04 »

Use external ram for 8051 like  62256(32k) or AT89c51ED2   ca 2k RAM end eeprom
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC