* Add support of Wiegand card reader @ 2018-04-09 14:05 Gaëtan Carlier 2018-04-09 23:26 ` Matt Ranostay 0 siblings, 1 reply; 12+ messages in thread From: Gaëtan Carlier @ 2018-04-09 14:05 UTC (permalink / raw) To: linux-iio Hello, I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? Thank you for your help? Best regards, Gaëtan. [1] https://en.wikipedia.org/wiki/Wiegand_interface ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-09 14:05 Add support of Wiegand card reader Gaëtan Carlier @ 2018-04-09 23:26 ` Matt Ranostay 2018-04-10 8:57 ` Gaëtan Carlier 0 siblings, 1 reply; 12+ messages in thread From: Matt Ranostay @ 2018-04-09 23:26 UTC (permalink / raw) To: Gaëtan Carlier; +Cc: linux-iio On Mon, Apr 9, 2018 at 7:05 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com> wro= te: > Hello, > I would like to add support of Wiegand card reader [1]. Where can I place= it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? Question here is why is this ideal for iio versus using the input subsystem= ? Also a few issues/points: * What is the interface to the Wiegand data? If it is inputting on a GPIO that is for sure not going to be real time enough to get valid data * Aren't there multiple Wiegand transport standards? * Most keyreaders I've seen are emulated as keyboard devices so they use the input subsystem. * Also if the data being output is ASCII data, then I'm not sure that fits anywhere in iio - Matt > > Thank you for your help? > Best regards, > Ga=C3=ABtan. > > [1] https://en.wikipedia.org/wiki/Wiegand_interface > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-09 23:26 ` Matt Ranostay @ 2018-04-10 8:57 ` Gaëtan Carlier 2018-04-11 3:37 ` Matt Ranostay 0 siblings, 1 reply; 12+ messages in thread From: Gaëtan Carlier @ 2018-04-10 8:57 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio Hello, Thank you for your reply. On 04/10/2018 01:26 AM, Matt Ranostay wrote: > On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >> Hello, >> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? > > Question here is why is this ideal for iio versus using the input subsystem? What can I send to userspace from a bitstream using Input subsystem ? Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... My idea is to send a structure with * number of bits read * if two parity bits are valid * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. I already start writting driver based on humidity/dht11.c that uses similar timings. > > Also a few issues/points: > > * What is the interface to the Wiegand data? If it is inputting on a > GPIO that is for sure not going to be real time enough to get valid > data Wiegand protocol uses two data lines. Both data lines are pulled-up. When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is set low. D0 and D1 line can never be set low at the same time. Reader will convert ID of the card into binary data flow of 26, 34, .... 60 bits. The length of a data flow is configured in the reader and all readers connected on the same Wiegand bus have generally the same length. > * Aren't there multiple Wiegand transport standards? Yes they are several data length. > * Most keyreaders I've seen are emulated as keyboard devices so they > use the input subsystem. If they are emulated as keyboard, they don't use Wiegand anymore ! Wiegand is still often used for hotels, ... > * Also if the data being output is ASCII data, then I'm not sure that > fits anywhere in iioData received from Wiegand bus are bits. They are not packed in 8 bits or any other size. > > - Matt > > >> >> Thank you for your help? >> Best regards, >> Gaëtan. >> >> [1] https://en.wikipedia.org/wiki/Wiegand_interface >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Gaëtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-10 8:57 ` Gaëtan Carlier @ 2018-04-11 3:37 ` Matt Ranostay 2018-04-11 8:36 ` Gaëtan Carlier 0 siblings, 1 reply; 12+ messages in thread From: Matt Ranostay @ 2018-04-11 3:37 UTC (permalink / raw) To: Gaëtan Carlier; +Cc: linux-iio On Tue, Apr 10, 2018 at 1:57 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com> wr= ote: > Hello, > Thank you for your reply. > > On 04/10/2018 01:26 AM, Matt Ranostay wrote: >> On Mon, Apr 9, 2018 at 7:05 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com> = wrote: >>> Hello, >>> I would like to add support of Wiegand card reader [1]. Where can I pla= ce it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >> >> Question here is why is this ideal for iio versus using the input subsys= tem? > What can I send to userspace from a bitstream using Input subsystem ? > Datas on Wiegand depend on readers used/setup. The best is to send bitstr= eam directly to userspace and let user split bitstream into facilty/area co= de, card ID, ... > My idea is to send a structure with > * number of bits read > * if two parity bits are valid > * the bitstream itself saved in a 64 bit unsigned integer (or a buffe= r of chars) including or not the parity bits (I still have to decide). I do= n't see readers with more than 60 bits. > > I already start writting driver based on humidity/dht11.c that uses simil= ar timings. Another question is what would your struct iio_chan_spec definition look like? Namely the .type assignments > >> >> Also a few issues/points: >> >> * What is the interface to the Wiegand data? If it is inputting on a >> GPIO that is for sure not going to be real time enough to get valid >> data > Wiegand protocol uses two data lines. Both data lines are pulled-up. When= a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is se= t low. D0 and D1 line can never be set low at the same time. Reader will co= nvert ID of the card into binary data flow of 26, 34, .... 60 bits. > The length of a data flow is configured in the reader and all readers con= nected on the same Wiegand bus have generally the same length. > >> * Aren't there multiple Wiegand transport standards? > Yes they are several data length. > >> * Most keyreaders I've seen are emulated as keyboard devices so they >> use the input subsystem. > If they are emulated as keyboard, they don't use Wiegand anymore ! Wiegan= d is still often used for hotels, ... > >> * Also if the data being output is ASCII data, then I'm not sure that >> fits anywhere in iioData received from Wiegand bus are bits. They are no= t packed in 8 bits or any other size. > >> >> - Matt >> >> >>> >>> Thank you for your help? >>> Best regards, >>> Ga=C3=ABtan. >>> >>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Regards, > Ga=C3=ABtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-11 3:37 ` Matt Ranostay @ 2018-04-11 8:36 ` Gaëtan Carlier 2018-04-12 3:41 ` Matt Ranostay 0 siblings, 1 reply; 12+ messages in thread From: Gaëtan Carlier @ 2018-04-11 8:36 UTC (permalink / raw) To: Matt Ranostay; +Cc: linux-iio On 04/11/2018 05:37 AM, Matt Ranostay wrote: > On Tue, Apr 10, 2018 at 1:57 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >> Hello, >> Thank you for your reply. >> >> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>> On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>> Hello, >>>> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >>> >>> Question here is why is this ideal for iio versus using the input subsystem? >> What can I send to userspace from a bitstream using Input subsystem ? >> Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... >> My idea is to send a structure with >> * number of bits read >> * if two parity bits are valid >> * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. >> >> I already start writting driver based on humidity/dht11.c that uses similar timings. > > Another question is what would your struct iio_chan_spec definition > look like? Namely the .type assignments > For now, I did not have define any channels and num_channels in struct iio_dev in probe function. That is what I have to investigate today : study how buffers work for IIO subsystem. The idea is to have a blocking call from the userspace and every time a card is read, the buffer is filled and pushed to userspace. Userspace application will be unblocked and the buffer will be read. Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? >> >>> >>> Also a few issues/points: >>> >>> * What is the interface to the Wiegand data? If it is inputting on a >>> GPIO that is for sure not going to be real time enough to get valid >>> data >> Wiegand protocol uses two data lines. Both data lines are pulled-up. When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is set low. D0 and D1 line can never be set low at the same time. Reader will convert ID of the card into binary data flow of 26, 34, .... 60 bits. >> The length of a data flow is configured in the reader and all readers connected on the same Wiegand bus have generally the same length. >> >>> * Aren't there multiple Wiegand transport standards? >> Yes they are several data length. >> >>> * Most keyreaders I've seen are emulated as keyboard devices so they >>> use the input subsystem. >> If they are emulated as keyboard, they don't use Wiegand anymore ! Wiegand is still often used for hotels, ... >> >>> * Also if the data being output is ASCII data, then I'm not sure that >>> fits anywhere in iioData received from Wiegand bus are bits. They are not packed in 8 bits or any other size. >> >>> >>> - Matt >>> >>> >>>> >>>> Thank you for your help? >>>> Best regards, >>>> Gaëtan. >>>> >>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> Regards, >> Gaëtan. Thank you, Regards, Gaëtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-11 8:36 ` Gaëtan Carlier @ 2018-04-12 3:41 ` Matt Ranostay 2018-04-12 11:24 ` Jonathan Cameron 0 siblings, 1 reply; 12+ messages in thread From: Matt Ranostay @ 2018-04-12 3:41 UTC (permalink / raw) To: Gaëtan Carlier, Jonathan Cameron, Lars-Peter Clausen; +Cc: linux-iio On Wed, Apr 11, 2018 at 1:36 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com> wr= ote: > On 04/11/2018 05:37 AM, Matt Ranostay wrote: >> On Tue, Apr 10, 2018 at 1:57 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com>= wrote: >>> Hello, >>> Thank you for your reply. >>> >>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>> On Mon, Apr 9, 2018 at 7:05 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com= > wrote: >>>>> Hello, >>>>> I would like to add support of Wiegand card reader [1]. Where can I p= lace it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >>>> >>>> Question here is why is this ideal for iio versus using the input subs= ystem? >>> What can I send to userspace from a bitstream using Input subsystem ? >>> Datas on Wiegand depend on readers used/setup. The best is to send bits= tream directly to userspace and let user split bitstream into facilty/area = code, card ID, ... >>> My idea is to send a structure with >>> * number of bits read >>> * if two parity bits are valid >>> * the bitstream itself saved in a 64 bit unsigned integer (or a buf= fer of chars) including or not the parity bits (I still have to decide). I = don't see readers with more than 60 bits. >>> >>> I already start writting driver based on humidity/dht11.c that uses sim= ilar timings. >> >> Another question is what would your struct iio_chan_spec definition >> look like? Namely the .type assignments >> > For now, I did not have define any channels and num_channels in struct ii= o_dev in probe function. > That is what I have to investigate today : study how buffers work for IIO= subsystem. > The idea is to have a blocking call from the userspace and every time a c= ard is read, the buffer is filled and pushed to userspace. Userspace applic= ation will be unblocked and the buffer will be read. > Yeah buffers need to work independent of userspace and can't be blocking at= all. > Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? > Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI unit or similar. Maybe Jonathan has some thoughts on this >>> >>>> >>>> Also a few issues/points: >>>> >>>> * What is the interface to the Wiegand data? If it is inputting on a >>>> GPIO that is for sure not going to be real time enough to get valid >>>> data >>> Wiegand protocol uses two data lines. Both data lines are pulled-up. Wh= en a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is = set low. D0 and D1 line can never be set low at the same time. Reader will = convert ID of the card into binary data flow of 26, 34, .... 60 bits. >>> The length of a data flow is configured in the reader and all readers c= onnected on the same Wiegand bus have generally the same length. >>> >>>> * Aren't there multiple Wiegand transport standards? >>> Yes they are several data length. >>> >>>> * Most keyreaders I've seen are emulated as keyboard devices so they >>>> use the input subsystem. >>> If they are emulated as keyboard, they don't use Wiegand anymore ! Wieg= and is still often used for hotels, ... >>> >>>> * Also if the data being output is ASCII data, then I'm not sure that >>>> fits anywhere in iioData received from Wiegand bus are bits. They are = not packed in 8 bits or any other size. >>> >>>> >>>> - Matt >>>> >>>> >>>>> >>>>> Thank you for your help? >>>>> Best regards, >>>>> Ga=C3=ABtan. >>>>> >>>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" = in >>>>> the body of a message to majordomo@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> Regards, >>> Ga=C3=ABtan. > > Thank you, > Regards, > Ga=C3=ABtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-12 3:41 ` Matt Ranostay @ 2018-04-12 11:24 ` Jonathan Cameron 2018-04-12 11:30 ` Lars-Peter Clausen 2018-04-12 12:20 ` Gaëtan Carlier 0 siblings, 2 replies; 12+ messages in thread From: Jonathan Cameron @ 2018-04-12 11:24 UTC (permalink / raw) To: Matt Ranostay Cc: Gaëtan Carlier, Jonathan Cameron, Lars-Peter Clausen, linux-iio On Wed, 11 Apr 2018 20:41:30 -0700 Matt Ranostay <matt.ranostay@konsulko.com> wrote: > On Wed, Apr 11, 2018 at 1:36 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: > > On 04/11/2018 05:37 AM, Matt Ranostay wrote: > >> On Tue, Apr 10, 2018 at 1:57 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: > >>> Hello, > >>> Thank you for your reply. > >>> > >>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: > >>>> On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: > >>>>> Hello, > >>>>> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? > >>>> > >>>> Question here is why is this ideal for iio versus using the input subsystem? > >>> What can I send to userspace from a bitstream using Input subsystem ? > >>> Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... > >>> My idea is to send a structure with > >>> * number of bits read > >>> * if two parity bits are valid > >>> * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. > >>> > >>> I already start writting driver based on humidity/dht11.c that uses similar timings. > >> > >> Another question is what would your struct iio_chan_spec definition > >> look like? Namely the .type assignments > >> > > For now, I did not have define any channels and num_channels in struct iio_dev in probe function. > > That is what I have to investigate today : study how buffers work for IIO subsystem. > > The idea is to have a blocking call from the userspace and every time a card is read, the buffer is filled and pushed to userspace. Userspace application will be unblocked and the buffer will be read. > > > > Yeah buffers need to work independent of userspace and can't be blocking at all. > > > Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? > > > > Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI > unit or similar. Maybe Jonathan has some thoughts on this I'll confess I'm not sure this is really a good fit for IIO. It's kind of similar to some of the things like fingerprint readers that generate a block of data in some cryptic format that needs a userspace library to interpret it. We have talked in the past about optimal storage for binary data (GPI signals on devices that scan them in groups). This is kind of like that I guess. So, Gaetan, what were you thinking the actual data layout in the buffer would be? > > >>> > >>>> > >>>> Also a few issues/points: > >>>> > >>>> * What is the interface to the Wiegand data? If it is inputting on a > >>>> GPIO that is for sure not going to be real time enough to get valid > >>>> data > >>> Wiegand protocol uses two data lines. Both data lines are pulled-up. When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is set low. D0 and D1 line can never be set low at the same time. Reader will convert ID of the card into binary data flow of 26, 34, .... 60 bits. > >>> The length of a data flow is configured in the reader and all readers connected on the same Wiegand bus have generally the same length. > >>> > >>>> * Aren't there multiple Wiegand transport standards? > >>> Yes they are several data length. > >>> > >>>> * Most keyreaders I've seen are emulated as keyboard devices so they > >>>> use the input subsystem. > >>> If they are emulated as keyboard, they don't use Wiegand anymore ! Wiegand is still often used for hotels, ... > >>> > >>>> * Also if the data being output is ASCII data, then I'm not sure that > >>>> fits anywhere in iioData received from Wiegand bus are bits. They are not packed in 8 bits or any other size. > >>> > >>>> > >>>> - Matt > >>>> > >>>> > >>>>> > >>>>> Thank you for your help? > >>>>> Best regards, > >>>>> Gaëtan. > >>>>> > >>>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface > >>>>> -- > >>>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in > >>>>> the body of a message to majordomo@vger.kernel.org > >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >>> > >>> Regards, > >>> Gaëtan. > > > > Thank you, > > Regards, > > Gaëtan. > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-12 11:24 ` Jonathan Cameron @ 2018-04-12 11:30 ` Lars-Peter Clausen 2018-04-12 12:20 ` Gaëtan Carlier 1 sibling, 0 replies; 12+ messages in thread From: Lars-Peter Clausen @ 2018-04-12 11:30 UTC (permalink / raw) To: Jonathan Cameron, Matt Ranostay Cc: Gaëtan Carlier, Jonathan Cameron, linux-iio On 04/12/2018 01:24 PM, Jonathan Cameron wrote: > On Wed, 11 Apr 2018 20:41:30 -0700 > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > >> On Wed, Apr 11, 2018 at 1:36 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>> On 04/11/2018 05:37 AM, Matt Ranostay wrote: >>>> On Tue, Apr 10, 2018 at 1:57 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>> Hello, >>>>> Thank you for your reply. >>>>> >>>>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>>>> On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>>>> Hello, >>>>>>> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >>>>>> >>>>>> Question here is why is this ideal for iio versus using the input subsystem? >>>>> What can I send to userspace from a bitstream using Input subsystem ? >>>>> Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... >>>>> My idea is to send a structure with >>>>> * number of bits read >>>>> * if two parity bits are valid >>>>> * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. >>>>> >>>>> I already start writting driver based on humidity/dht11.c that uses similar timings. >>>> >>>> Another question is what would your struct iio_chan_spec definition >>>> look like? Namely the .type assignments >>>> >>> For now, I did not have define any channels and num_channels in struct iio_dev in probe function. >>> That is what I have to investigate today : study how buffers work for IIO subsystem. >>> The idea is to have a blocking call from the userspace and every time a card is read, the buffer is filled and pushed to userspace. Userspace application will be unblocked and the buffer will be read. >>> >> >> Yeah buffers need to work independent of userspace and can't be blocking at all. >> >>> Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? >>> >> >> Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI >> unit or similar. Maybe Jonathan has some thoughts on this > > I'll confess I'm not sure this is really a good fit for IIO. It's kind > of similar to some of the things like fingerprint readers that generate > a block of data in some cryptic format that needs a userspace library to > interpret it. It looks like we are removing the frame from framework ;) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-12 11:24 ` Jonathan Cameron 2018-04-12 11:30 ` Lars-Peter Clausen @ 2018-04-12 12:20 ` Gaëtan Carlier 2018-04-12 20:59 ` Matt Ranostay 1 sibling, 1 reply; 12+ messages in thread From: Gaëtan Carlier @ 2018-04-12 12:20 UTC (permalink / raw) To: Jonathan Cameron, Matt Ranostay Cc: Jonathan Cameron, Lars-Peter Clausen, linux-iio Hi, On 04/12/2018 01:24 PM, Jonathan Cameron wrote: > On Wed, 11 Apr 2018 20:41:30 -0700 > Matt Ranostay <matt.ranostay@konsulko.com> wrote: > >> On Wed, Apr 11, 2018 at 1:36 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>> On 04/11/2018 05:37 AM, Matt Ranostay wrote: >>>> On Tue, Apr 10, 2018 at 1:57 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>> Hello, >>>>> Thank you for your reply. >>>>> >>>>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>>>> On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>>>> Hello, >>>>>>> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >>>>>> >>>>>> Question here is why is this ideal for iio versus using the input subsystem? >>>>> What can I send to userspace from a bitstream using Input subsystem ? >>>>> Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... >>>>> My idea is to send a structure with >>>>> * number of bits read >>>>> * if two parity bits are valid >>>>> * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. >>>>> >>>>> I already start writting driver based on humidity/dht11.c that uses similar timings. >>>> >>>> Another question is what would your struct iio_chan_spec definition >>>> look like? Namely the .type assignments >>>> >>> For now, I did not have define any channels and num_channels in struct iio_dev in probe function. >>> That is what I have to investigate today : study how buffers work for IIO subsystem. >>> The idea is to have a blocking call from the userspace and every time a card is read, the buffer is filled and pushed to userspace. Userspace application will be unblocked and the buffer will be read. >>> >> >> Yeah buffers need to work independent of userspace and can't be blocking at all. >> >>> Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? >>> >> >> Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI >> unit or similar. Maybe Jonathan has some thoughts on this > > I'll confess I'm not sure this is really a good fit for IIO. It's kind > of similar to some of the things like fingerprint readers that generate > a block of data in some cryptic format that needs a userspace library to > interpret it. > > We have talked in the past about optimal storage for binary data (GPI signals > on devices that scan them in groups). This is kind of like that I guess. > > So, Gaetan, what were you thinking the actual data layout in the buffer > would be? > The buffer will contain : a u64 variable, a counter that will tell how much bits in u64 variables a used (wiegand is generally 26 bits or 34 bits but it can rise upto 60 bits but this situation is really rare). Initially, I though that IIO subsystem was done for this kind of interface but after more reading it is only suited for ADC/DAC devices. Unfortunately, I can not use input subsystem because, I need raw data that must not be converted to Key code, ... So I am little lost. Where can I place my code ? Even is Wiegand is a very old/unsecured/... protocol, it is still used a lot. And with pulse of some microseconds, it is difficult to handle them via exported GPIO on sysfs and do all the stuff in userspace. I clearly understand (now) that Wiegand can not stay in IIO but do you have any lead for me please ? > >> >>>>> >>>>>> >>>>>> Also a few issues/points: >>>>>> >>>>>> * What is the interface to the Wiegand data? If it is inputting on a >>>>>> GPIO that is for sure not going to be real time enough to get valid >>>>>> data >>>>> Wiegand protocol uses two data lines. Both data lines are pulled-up. When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is set low. D0 and D1 line can never be set low at the same time. Reader will convert ID of the card into binary data flow of 26, 34, .... 60 bits. >>>>> The length of a data flow is configured in the reader and all readers connected on the same Wiegand bus have generally the same length. >>>>> >>>>>> * Aren't there multiple Wiegand transport standards? >>>>> Yes they are several data length. >>>>> >>>>>> * Most keyreaders I've seen are emulated as keyboard devices so they >>>>>> use the input subsystem. >>>>> If they are emulated as keyboard, they don't use Wiegand anymore ! Wiegand is still often used for hotels, ... >>>>> >>>>>> * Also if the data being output is ASCII data, then I'm not sure that >>>>>> fits anywhere in iioData received from Wiegand bus are bits. They are not packed in 8 bits or any other size. >>>>> >>>>>> >>>>>> - Matt >>>>>> >>>>>> >>>>>>> >>>>>>> Thank you for your help? >>>>>>> Best regards, >>>>>>> Gaëtan. >>>>>>> >>>>>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>>>>>> -- >>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>>>>>> the body of a message to majordomo@vger.kernel.org >>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>> >>>>> Regards, >>>>> Gaëtan. >>> >>> Thank you, >>> Regards, >>> Gaëtan. >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > Thank you. Regards, Gaëtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-12 12:20 ` Gaëtan Carlier @ 2018-04-12 20:59 ` Matt Ranostay 2018-04-13 8:11 ` Gaëtan Carlier 0 siblings, 1 reply; 12+ messages in thread From: Matt Ranostay @ 2018-04-12 20:59 UTC (permalink / raw) To: Gaëtan Carlier Cc: Jonathan Cameron, Jonathan Cameron, Lars-Peter Clausen, linux-iio On Thu, Apr 12, 2018 at 5:20 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com> wr= ote: > Hi, > On 04/12/2018 01:24 PM, Jonathan Cameron wrote: >> On Wed, 11 Apr 2018 20:41:30 -0700 >> Matt Ranostay <matt.ranostay@konsulko.com> wrote: >> >>> On Wed, Apr 11, 2018 at 1:36 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com= > wrote: >>>> On 04/11/2018 05:37 AM, Matt Ranostay wrote: >>>>> On Tue, Apr 10, 2018 at 1:57 AM, Ga=C3=ABtan Carlier <gcembed@gmail.c= om> wrote: >>>>>> Hello, >>>>>> Thank you for your reply. >>>>>> >>>>>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>>>>> On Mon, Apr 9, 2018 at 7:05 AM, Ga=C3=ABtan Carlier <gcembed@gmail.= com> wrote: >>>>>>>> Hello, >>>>>>>> I would like to add support of Wiegand card reader [1]. Where can = I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c= ? >>>>>>> >>>>>>> Question here is why is this ideal for iio versus using the input s= ubsystem? >>>>>> What can I send to userspace from a bitstream using Input subsystem = ? >>>>>> Datas on Wiegand depend on readers used/setup. The best is to send b= itstream directly to userspace and let user split bitstream into facilty/ar= ea code, card ID, ... >>>>>> My idea is to send a structure with >>>>>> * number of bits read >>>>>> * if two parity bits are valid >>>>>> * the bitstream itself saved in a 64 bit unsigned integer (or a = buffer of chars) including or not the parity bits (I still have to decide).= I don't see readers with more than 60 bits. >>>>>> >>>>>> I already start writting driver based on humidity/dht11.c that uses = similar timings. >>>>> >>>>> Another question is what would your struct iio_chan_spec definition >>>>> look like? Namely the .type assignments >>>>> >>>> For now, I did not have define any channels and num_channels in struct= iio_dev in probe function. >>>> That is what I have to investigate today : study how buffers work for = IIO subsystem. >>>> The idea is to have a blocking call from the userspace and every time = a card is read, the buffer is filled and pushed to userspace. Userspace app= lication will be unblocked and the buffer will be read. >>>> >>> >>> Yeah buffers need to work independent of userspace and can't be blockin= g at all. >>> >>>> Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? >>>> >>> >>> Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI >>> unit or similar. Maybe Jonathan has some thoughts on this >> >> I'll confess I'm not sure this is really a good fit for IIO. It's kind >> of similar to some of the things like fingerprint readers that generate >> a block of data in some cryptic format that needs a userspace library to >> interpret it. >> >> We have talked in the past about optimal storage for binary data (GPI si= gnals >> on devices that scan them in groups). This is kind of like that I guess. >> >> So, Gaetan, what were you thinking the actual data layout in the buffer >> would be? >> > The buffer will contain : a u64 variable, a counter that will tell how mu= ch bits in u64 variables a used (wiegand is generally 26 bits or 34 bits bu= t it can rise upto 60 bits but this situation is really rare). > > Initially, I though that IIO subsystem was done for this kind of interfac= e but after more reading it is only suited for ADC/DAC devices. > Unfortunately, I can not use input subsystem because, I need raw data tha= t must not be converted to Key code, ... > So I am little lost. Where can I place my code ? Even is Wiegand is a ver= y old/unsecured/... protocol, it is still used a lot. > And with pulse of some microseconds, it is difficult to handle them via e= xported GPIO on sysfs and do all the stuff in userspace. Yeah in userspace that would totally wrong way to do it. One issue you probably going to have is you can't really be that deterministic with sampling the GPIO input esp if you dont' have many cores. Then again I'm not sure how sensitive Wiegand is to timing. > > I clearly understand (now) that Wiegand can not stay in IIO but do you ha= ve any lead for me please ? > Which platform are you using for this? >> >>> >>>>>> >>>>>>> >>>>>>> Also a few issues/points: >>>>>>> >>>>>>> * What is the interface to the Wiegand data? If it is inputting on = a >>>>>>> GPIO that is for sure not going to be real time enough to get valid >>>>>>> data >>>>>> Wiegand protocol uses two data lines. Both data lines are pulled-up.= When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line = is set low. D0 and D1 line can never be set low at the same time. Reader wi= ll convert ID of the card into binary data flow of 26, 34, .... 60 bits. >>>>>> The length of a data flow is configured in the reader and all reader= s connected on the same Wiegand bus have generally the same length. >>>>>> >>>>>>> * Aren't there multiple Wiegand transport standards? >>>>>> Yes they are several data length. >>>>>> >>>>>>> * Most keyreaders I've seen are emulated as keyboard devices so the= y >>>>>>> use the input subsystem. >>>>>> If they are emulated as keyboard, they don't use Wiegand anymore ! W= iegand is still often used for hotels, ... >>>>>> >>>>>>> * Also if the data being output is ASCII data, then I'm not sure th= at >>>>>>> fits anywhere in iioData received from Wiegand bus are bits. They a= re not packed in 8 bits or any other size. >>>>>> >>>>>>> >>>>>>> - Matt >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thank you for your help? >>>>>>>> Best regards, >>>>>>>> Ga=C3=ABtan. >>>>>>>> >>>>>>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>>>>>>> -- >>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-ii= o" in >>>>>>>> the body of a message to majordomo@vger.kernel.org >>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>> >>>>>> Regards, >>>>>> Ga=C3=ABtan. >>>> >>>> Thank you, >>>> Regards, >>>> Ga=C3=ABtan. >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > Thank you. > Regards, > Ga=C3=ABtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-12 20:59 ` Matt Ranostay @ 2018-04-13 8:11 ` Gaëtan Carlier 2018-04-13 18:44 ` Matt Ranostay 0 siblings, 1 reply; 12+ messages in thread From: Gaëtan Carlier @ 2018-04-13 8:11 UTC (permalink / raw) To: Matt Ranostay Cc: Jonathan Cameron, Jonathan Cameron, Lars-Peter Clausen, linux-iio On 04/12/2018 10:59 PM, Matt Ranostay wrote: > On Thu, Apr 12, 2018 at 5:20 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >> Hi, >> On 04/12/2018 01:24 PM, Jonathan Cameron wrote: >>> On Wed, 11 Apr 2018 20:41:30 -0700 >>> Matt Ranostay <matt.ranostay@konsulko.com> wrote: >>> >>>> On Wed, Apr 11, 2018 at 1:36 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>> On 04/11/2018 05:37 AM, Matt Ranostay wrote: >>>>>> On Tue, Apr 10, 2018 at 1:57 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>>>> Hello, >>>>>>> Thank you for your reply. >>>>>>> >>>>>>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>>>>>> On Mon, Apr 9, 2018 at 7:05 AM, Gaëtan Carlier <gcembed@gmail.com> wrote: >>>>>>>>> Hello, >>>>>>>>> I would like to add support of Wiegand card reader [1]. Where can I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand.c? >>>>>>>> >>>>>>>> Question here is why is this ideal for iio versus using the input subsystem? >>>>>>> What can I send to userspace from a bitstream using Input subsystem ? >>>>>>> Datas on Wiegand depend on readers used/setup. The best is to send bitstream directly to userspace and let user split bitstream into facilty/area code, card ID, ... >>>>>>> My idea is to send a structure with >>>>>>> * number of bits read >>>>>>> * if two parity bits are valid >>>>>>> * the bitstream itself saved in a 64 bit unsigned integer (or a buffer of chars) including or not the parity bits (I still have to decide). I don't see readers with more than 60 bits. >>>>>>> >>>>>>> I already start writting driver based on humidity/dht11.c that uses similar timings. >>>>>> >>>>>> Another question is what would your struct iio_chan_spec definition >>>>>> look like? Namely the .type assignments >>>>>> >>>>> For now, I did not have define any channels and num_channels in struct iio_dev in probe function. >>>>> That is what I have to investigate today : study how buffers work for IIO subsystem. >>>>> The idea is to have a blocking call from the userspace and every time a card is read, the buffer is filled and pushed to userspace. Userspace application will be unblocked and the buffer will be read. >>>>> >>>> >>>> Yeah buffers need to work independent of userspace and can't be blocking at all. >>>> >>>>> Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC) ? >>>>> >>>> >>>> Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI >>>> unit or similar. Maybe Jonathan has some thoughts on this >>> >>> I'll confess I'm not sure this is really a good fit for IIO. It's kind >>> of similar to some of the things like fingerprint readers that generate >>> a block of data in some cryptic format that needs a userspace library to >>> interpret it. >>> >>> We have talked in the past about optimal storage for binary data (GPI signals >>> on devices that scan them in groups). This is kind of like that I guess. >>> >>> So, Gaetan, what were you thinking the actual data layout in the buffer >>> would be? >>> >> The buffer will contain : a u64 variable, a counter that will tell how much bits in u64 variables a used (wiegand is generally 26 bits or 34 bits but it can rise upto 60 bits but this situation is really rare). >> >> Initially, I though that IIO subsystem was done for this kind of interface but after more reading it is only suited for ADC/DAC devices. >> Unfortunately, I can not use input subsystem because, I need raw data that must not be converted to Key code, ... >> So I am little lost. Where can I place my code ? Even is Wiegand is a very old/unsecured/... protocol, it is still used a lot. >> And with pulse of some microseconds, it is difficult to handle them via exported GPIO on sysfs and do all the stuff in userspace. > > Yeah in userspace that would totally wrong way to do it. One issue > you probably going to have is you can't really be that deterministic > with sampling the GPIO input > esp if you dont' have many cores. Then again I'm not sure how > sensitive Wiegand is to timing. > A valid frame must follows these specs: - (negative) pulse width : from 30us to 200us - pause between two pulses : from 500us to 10ms. In my case, Each time I receive a (falling) interrupt on one of two GPIOs (D1 or D0), I reload a timer of 20ms (mod_timer). If the timer overflows, this means that all bits have been receeived, I check the parity and data is ready to be forwarded to userspace : the number of bit received (depends on the reader), the bitstream stored in a 64-bit variable, a "valid" flag sets if parity bits are OK. Normally Wiegand data is between 26 and 60 bits. >> >> I clearly understand (now) that Wiegand can not stay in IIO but do you have any lead for me please ? >> > > Which platform are you using for this? > I am working with an ARM Freescale i.MX286 >>> >>>> >>>>>>> >>>>>>>> >>>>>>>> Also a few issues/points: >>>>>>>> >>>>>>>> * What is the interface to the Wiegand data? If it is inputting on a >>>>>>>> GPIO that is for sure not going to be real time enough to get valid >>>>>>>> data >>>>>>> Wiegand protocol uses two data lines. Both data lines are pulled-up. When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 line is set low. D0 and D1 line can never be set low at the same time. Reader will convert ID of the card into binary data flow of 26, 34, .... 60 bits. >>>>>>> The length of a data flow is configured in the reader and all readers connected on the same Wiegand bus have generally the same length. >>>>>>> >>>>>>>> * Aren't there multiple Wiegand transport standards? >>>>>>> Yes they are several data length. >>>>>>> >>>>>>>> * Most keyreaders I've seen are emulated as keyboard devices so they >>>>>>>> use the input subsystem. >>>>>>> If they are emulated as keyboard, they don't use Wiegand anymore ! Wiegand is still often used for hotels, ... >>>>>>> >>>>>>>> * Also if the data being output is ASCII data, then I'm not sure that >>>>>>>> fits anywhere in iioData received from Wiegand bus are bits. They are not packed in 8 bits or any other size. >>>>>>> >>>>>>>> >>>>>>>> - Matt >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thank you for your help? >>>>>>>>> Best regards, >>>>>>>>> Gaëtan. >>>>>>>>> >>>>>>>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>>>>>>>> -- >>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>>>>>>>> the body of a message to majordomo@vger.kernel.org >>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>>> >>>>>>> Regards, >>>>>>> Gaëtan. >>>>> >>>>> Thank you, >>>>> Regards, >>>>> Gaëtan. >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> Thank you. >> Regards, >> Gaëtan. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Add support of Wiegand card reader 2018-04-13 8:11 ` Gaëtan Carlier @ 2018-04-13 18:44 ` Matt Ranostay 0 siblings, 0 replies; 12+ messages in thread From: Matt Ranostay @ 2018-04-13 18:44 UTC (permalink / raw) To: Gaëtan Carlier Cc: Jonathan Cameron, Jonathan Cameron, Lars-Peter Clausen, linux-iio On Fri, Apr 13, 2018 at 1:11 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com> wr= ote: > On 04/12/2018 10:59 PM, Matt Ranostay wrote: >> On Thu, Apr 12, 2018 at 5:20 AM, Ga=C3=ABtan Carlier <gcembed@gmail.com>= wrote: >>> Hi, >>> On 04/12/2018 01:24 PM, Jonathan Cameron wrote: >>>> On Wed, 11 Apr 2018 20:41:30 -0700 >>>> Matt Ranostay <matt.ranostay@konsulko.com> wrote: >>>> >>>>> On Wed, Apr 11, 2018 at 1:36 AM, Ga=C3=ABtan Carlier <gcembed@gmail.c= om> wrote: >>>>>> On 04/11/2018 05:37 AM, Matt Ranostay wrote: >>>>>>> On Tue, Apr 10, 2018 at 1:57 AM, Ga=C3=ABtan Carlier <gcembed@gmail= .com> wrote: >>>>>>>> Hello, >>>>>>>> Thank you for your reply. >>>>>>>> >>>>>>>> On 04/10/2018 01:26 AM, Matt Ranostay wrote: >>>>>>>>> On Mon, Apr 9, 2018 at 7:05 AM, Ga=C3=ABtan Carlier <gcembed@gmai= l.com> wrote: >>>>>>>>>> Hello, >>>>>>>>>> I would like to add support of Wiegand card reader [1]. Where ca= n I place it : drivers/iio/access/wiegand.c or drivers/iio/security/wiegand= .c? >>>>>>>>> >>>>>>>>> Question here is why is this ideal for iio versus using the input= subsystem? >>>>>>>> What can I send to userspace from a bitstream using Input subsyste= m ? >>>>>>>> Datas on Wiegand depend on readers used/setup. The best is to send= bitstream directly to userspace and let user split bitstream into facilty/= area code, card ID, ... >>>>>>>> My idea is to send a structure with >>>>>>>> * number of bits read >>>>>>>> * if two parity bits are valid >>>>>>>> * the bitstream itself saved in a 64 bit unsigned integer (or = a buffer of chars) including or not the parity bits (I still have to decide= ). I don't see readers with more than 60 bits. >>>>>>>> >>>>>>>> I already start writting driver based on humidity/dht11.c that use= s similar timings. >>>>>>> >>>>>>> Another question is what would your struct iio_chan_spec definition >>>>>>> look like? Namely the .type assignments >>>>>>> >>>>>> For now, I did not have define any channels and num_channels in stru= ct iio_dev in probe function. >>>>>> That is what I have to investigate today : study how buffers work fo= r IIO subsystem. >>>>>> The idea is to have a blocking call from the userspace and every tim= e a card is read, the buffer is filled and pushed to userspace. Userspace a= pplication will be unblocked and the buffer will be read. >>>>>> >>>>> >>>>> Yeah buffers need to work independent of userspace and can't be block= ing at all. >>>>> >>>>>> Couldn't I create a new iio_chan_type IIO_ID (or even IIO_BIOMETRIC)= ? >>>>>> >>>>> >>>>> Yeah IIO_BIOMETRIC or even IIO_ID is a bit odd since it isn't an SI >>>>> unit or similar. Maybe Jonathan has some thoughts on this >>>> >>>> I'll confess I'm not sure this is really a good fit for IIO. It's kind >>>> of similar to some of the things like fingerprint readers that generat= e >>>> a block of data in some cryptic format that needs a userspace library = to >>>> interpret it. >>>> >>>> We have talked in the past about optimal storage for binary data (GPI = signals >>>> on devices that scan them in groups). This is kind of like that I gues= s. >>>> >>>> So, Gaetan, what were you thinking the actual data layout in the buffe= r >>>> would be? >>>> >>> The buffer will contain : a u64 variable, a counter that will tell how = much bits in u64 variables a used (wiegand is generally 26 bits or 34 bits = but it can rise upto 60 bits but this situation is really rare). >>> >>> Initially, I though that IIO subsystem was done for this kind of interf= ace but after more reading it is only suited for ADC/DAC devices. >>> Unfortunately, I can not use input subsystem because, I need raw data t= hat must not be converted to Key code, ... >>> So I am little lost. Where can I place my code ? Even is Wiegand is a v= ery old/unsecured/... protocol, it is still used a lot. >>> And with pulse of some microseconds, it is difficult to handle them via= exported GPIO on sysfs and do all the stuff in userspace. >> >> Yeah in userspace that would totally wrong way to do it. One issue >> you probably going to have is you can't really be that deterministic >> with sampling the GPIO input >> esp if you dont' have many cores. Then again I'm not sure how >> sensitive Wiegand is to timing. >> > A valid frame must follows these specs: > - (negative) pulse width : from 30us to 200us > - pause between two pulses : from 500us to 10ms. > > In my case, Each time I receive a (falling) interrupt on one of two GPIOs > (D1 or D0), I reload a timer of 20ms (mod_timer). If the timer overflows, > this means that all bits have been receeived, I check the parity and data > is ready to be forwarded to userspace : the number of bit received (depen= ds > on the reader), the bitstream stored in a 64-bit variable, a "valid" flag > sets if parity bits are OK. Normally Wiegand data is between 26 and 60 bi= ts. > Personally I think you overly optimistic that this would work with 100% of card swipes (propagation delay of the interrupt and scheduler would be an issue), and it wouldn't be fully in spec. Any reason not to use a Wiegand to RS232 converter? >>> >>> I clearly understand (now) that Wiegand can not stay in IIO but do you = have any lead for me please ? >>> >> >> Which platform are you using for this? >> > I am working with an ARM Freescale i.MX286 > >>>> >>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Also a few issues/points: >>>>>>>>> >>>>>>>>> * What is the interface to the Wiegand data? If it is inputting o= n a >>>>>>>>> GPIO that is for sure not going to be real time enough to get val= id >>>>>>>>> data >>>>>>>> Wiegand protocol uses two data lines. Both data lines are pulled-u= p. When a 0 must be send, D0 line is set low, when a 1 must be sent, D1 lin= e is set low. D0 and D1 line can never be set low at the same time. Reader = will convert ID of the card into binary data flow of 26, 34, .... 60 bits. >>>>>>>> The length of a data flow is configured in the reader and all read= ers connected on the same Wiegand bus have generally the same length. >>>>>>>> >>>>>>>>> * Aren't there multiple Wiegand transport standards? >>>>>>>> Yes they are several data length. >>>>>>>> >>>>>>>>> * Most keyreaders I've seen are emulated as keyboard devices so t= hey >>>>>>>>> use the input subsystem. >>>>>>>> If they are emulated as keyboard, they don't use Wiegand anymore != Wiegand is still often used for hotels, ... >>>>>>>> >>>>>>>>> * Also if the data being output is ASCII data, then I'm not sure = that >>>>>>>>> fits anywhere in iioData received from Wiegand bus are bits. They= are not packed in 8 bits or any other size. >>>>>>>> >>>>>>>>> >>>>>>>>> - Matt >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you for your help? >>>>>>>>>> Best regards, >>>>>>>>>> Ga=C3=ABtan. >>>>>>>>>> >>>>>>>>>> [1] https://en.wikipedia.org/wiki/Wiegand_interface >>>>>>>>>> -- >>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-= iio" in >>>>>>>>>> the body of a message to majordomo@vger.kernel.org >>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.ht= ml >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ga=C3=ABtan. >>>>>> >>>>>> Thank you, >>>>>> Regards, >>>>>> Ga=C3=ABtan. >>>>> -- >>>>> To unsubscribe from this list: send the line "unsubscribe linux-iio" = in >>>>> the body of a message to majordomo@vger.kernel.org >>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >>> >>> Thank you. >>> Regards, >>> Ga=C3=ABtan. > ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-04-13 18:44 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-09 14:05 Add support of Wiegand card reader Gaëtan Carlier 2018-04-09 23:26 ` Matt Ranostay 2018-04-10 8:57 ` Gaëtan Carlier 2018-04-11 3:37 ` Matt Ranostay 2018-04-11 8:36 ` Gaëtan Carlier 2018-04-12 3:41 ` Matt Ranostay 2018-04-12 11:24 ` Jonathan Cameron 2018-04-12 11:30 ` Lars-Peter Clausen 2018-04-12 12:20 ` Gaëtan Carlier 2018-04-12 20:59 ` Matt Ranostay 2018-04-13 8:11 ` Gaëtan Carlier 2018-04-13 18:44 ` Matt Ranostay
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.