From: Toby C. <tco...@pl...> - 2008-02-11 18:37:20
|
I think you will find the problem in the c client library. In dev_rfid.c around line 100 the data is copied out of the tag into the clients tag list. This should probably use the generated copy function but at the moment it copies each component seperately. Hope this helps, Toby On 11/02/2008, Giulio Zecca <Giu...@ir...> wrote: > > Player 2.0.5 > > The problem, as pointed out from me and another guy before, is that the > structure to hold RFID data... has no field for RFID data. > So a colleague decided to modify the Fiducial interface (not so good as > approach, IMHO), another used an OpaqueProxym so he could send command > to write data on the tags, basically flipping bits. All other ideas i > heard sounded more like a hack than a good solution. > What I tried to make is a more general implementation, > adding in the player_rfid_tag_t structure in file Player.h, and > similarly in playerc_rfid_tag_t, two fields identical in type as guid > and guid_count: > data_count; > data[PLAYER_RFID_MAX_DATA]; > > so that the structures became: > > /** @brief Structure describing a single RFID tag. */ > typedef struct player_rfid_tag > { > /** Tag type. */ > uint32_t type; > /** GUID count. */ > uint32_t guid_count; > /** The Globally Unique IDentifier (GUID) of the tag. */ > char guid[PLAYER_RFID_MAX_GUID]; > /** Data count. */ > uint32_t data_count; > /** The Data stored on the tag. */ > char data[PLAYER_RFID_MAX_DATA]; > } player_rfid_tag_t; > > and > > typedef struct > { > /** Tag type. */ > uint32_t type; > /** GUID count. */ > uint32_t guid_count; > /** The Globally Unique IDentifier (GUID) of the tag. */ > uint8_t guid[PLAYERC_RFID_MAX_GUID]; > /** Data count. */ > uint32_t data_count; > /** The Data stored on the tag. */ > uint8_t data[PLAYERC_RFID_MAX_DATA]; > } playerc_rfidtag_t; > > > Where for me the PLAYER_RFID_MAX_DATA can be just 253 for technical > specifications, but still, for a more general approach i thought to > consider the most common technology for RFIDs at 1KB, or 2KB (or even up > to 4KB, bigger ones are rarely used). If someone needs less, he can just > not use that much. > > Similar structure for the RC line, where even better you defined > pointers not to have fixed size arrays. > > > So, as said, I don't want someone to do this for me, but at least some > indications. > I really can't see where the data gets lost after the XDR takes care of > its demarshalling in a correct way: > func xdr_player_rfid_tag_t OK data_count = 14 > func xdr_player_rfid_tag_t OK data = trial_String_1 > > Maybe it's some silly setting easy for you to understand, and I can't > see that cause I'm just not in the Player developer's logic. > > Thanks > > > On Sat, 2008-02-09 at 10:05 +1300, Toby Collett wrote: > > Some more specifics would be useful here, which version of player are > > you working with and which structures are you trying to modify (and also > > why you want to modify them, we might be able to point out a simpler way > > to achieve the same goal..) > > > > Toby > > > > Giulio Zecca wrote: > > > I had a similar problem, that I am now trying to solve in a different > > > manner. > > > I am adding 2 fields (uint32_t data_count, char data[1024]) in a > Struct > > > in the Player.h file, and similarly on the client side in PlayerC.h > > > file. > > > > > > I then run the playerxdrgen.py script to generate the proper XDR > > > functions, generating a pack.c and a pack.h file. > > > Since these structures are not external, I thought I do not need to > then > > > compile to generate a library, but I took the different code from > pack.h > > > and pack.c and integrated it in the playerxdr.h and playerxdr.c files. > > > > > > When executing, the Driver reads correct values: > > > data_count = 14 > > > data = trial_String_1 > > > and then it does printf them correctly in my driver code. > > > > > > However, the Client sides executes the XDR function correctly, > printing > > > data_count = 14 > > > data = trial_String_1 > > > > > > but then in my code when I launch printf on each field it returns the > > > values in the struct all correct except the added ones: > > > data count = 0 > > > data = > > > > > > I tried to understand whaat's in between the XDR and the data actually > > > sent to the Client, but with no success. > > > Any hint on that? > > > When you, developers, modify a data structure like that, are you > making > > > something I didn't think about? > > > > > > Thanks > > > PS: let me know if it is better to post this question to the > Developer's > > > list! > > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Microsoft > > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > _______________________________________________ > > > Playerstage-users mailing list > > > Pla...@li... > > > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Playerstage-users mailing list > > Pla...@li... > > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- This email is intended for the addressee only and may contain privileged and/or confidential information |