Combine transceive() functionality

[GoogleCodeExporter]

We may want to consider nfc_initiator_select_tag() to be renamed to
nfc_initiator_select_target(). Where we use the "pbtInitData" parameter for 
(structs & unions) that corresponds to the active "init_modulation" type.

For DEP transactions this could hold pbtPidData/pbtNFCID3i/pbtGbData (using
structs & unions). This may improve the understanding of "pbtInitData" for
developers, since they are guided by a struct to supply additional info.

Furthermore this will bring down the total amount of "similar-code", plus
it will keep the API tight and clean.

Last but not least, we could save the current used "init_modulation", to
cut down the extra "tranceive()" functionality, since this only differs in
the command for the PN53X chipset.

Original issue reported on code.google.com by r...@libnfc.org on 30 Sep 2009 at 9:58

[GoogleCodeExporter]

Original comment by r...@libnfc.org on 30 Sep 2009 at 9:58

• Changed state: New

[GoogleCodeExporter]

What do you think about:
 - add "_t" suffix to types (defined using typedef), 
 - append "nfc_" prefix, IMHO it should be cleaner.
 - found a self-explained name for struct and typedef

i.e.:
 - init_modulation => nfc_modulation_t
 - dev_info => nfc_device_t
 - etc.

Original comment by romu...@libnfc.org on 21 Oct 2009 at 3:18

[GoogleCodeExporter]

In my opinion the "nfc_device" terminology is ambiguous because it's not clear 
if a
device is the user NFC chip or a third party NFC active device.

Original comment by emanuele.bertoldi on 28 Oct 2009 at 9:50

[GoogleCodeExporter]

Fine Zuck, what do you purpose ?

Original comment by romu...@libnfc.org on 28 Oct 2009 at 10:50

[GoogleCodeExporter]

Could "nfc_adaptor_t" be a good option?

Original comment by emanuele.bertoldi on 30 Oct 2009 at 2:02

[GoogleCodeExporter]

These two sound nice:
 - init_modulation => nfc_modulation_t
 - dev_info => nfc_adaptor_t

I will try to look into the init_modulation_t struct. It should be a straight 
forward
usable syntax.

Original comment by r...@libnfc.org on 31 Oct 2009 at 1:40

[GoogleCodeExporter]

Remember to change "nfc_device_desc_t" too:

nfc_device_desc_t => nfc_adaptor_desc_t

Original comment by emanuele.bertoldi on 2 Nov 2009 at 9:38

[GoogleCodeExporter]

init_modulation => nfc_modulation_t
is not correct.... since talk about the "initial modulation" (for 
anti-collision)
later you can boost up the speed (change modulation). This is not (yet) 
supported,
but the initial modulation will never change... (for example for a ISO14443-A 
card)

Original comment by r...@libnfc.org on 3 Nov 2009 at 1:55

[GoogleCodeExporter]

so it sould be then ?:)
init_modulation => nfc_init_modulation_t

Original comment by r...@libnfc.org on 3 Nov 2009 at 1:56

[GoogleCodeExporter]

Yes, I think you're right.

Original comment by emanuele.bertoldi on 3 Nov 2009 at 3:03

[GoogleCodeExporter]

Roel, if I understand correctly, I'm not agree with you on this point, a typedef
define a type, the nature of described thing. "initial modulation" is a 
modulation,
of course when I read your comment I understand there is a "current modulation" 
and
an "init modulation" but that seems to be variables roles, not types. I think we
should have a nfc_modulation_t type which can be ISO14443A_106, FELICA_212, 
etc. and
two variables nmInitModulation and nmCurrentModulation in the right structure.
Did I misunderstood something ?

Original comment by romu...@libnfc.org on 5 Nov 2009 at 2:53

[GoogleCodeExporter]

Original comment by romu...@libnfc.org on 14 Jan 2010 at 4:52

• Removed labels: Milestone-1.3.0

[GoogleCodeExporter]

Original comment by romu...@libnfc.org on 3 Feb 2010 at 3:12

• Added labels: Milestone-1.4.x

[GoogleCodeExporter]

Original comment by romu...@libnfc.org on 21 Apr 2010 at 1:17

• Added labels: OpSys-All

[GoogleCodeExporter]

The main idea of this issue is now fixed since r452.

Original comment by romu...@libnfc.org on 22 Jul 2010 at 2:26

• Changed state: Fixed