I need some code samples for the PN5180 reader. For example the following example describing the Anticollosion phase (https://www.nxp.com/design/software:SOFTWARE-CENTER#/home/query/pn5180/~filter~/relevance/0 -> Anticollision register layer for PN5180 (REV 1.1) ))
But for PN5180, "Half-Duplex Block Transmission Protocol"
I need an example of the " layer. This layer deals with communication after sending a RATS and PPS command to the PICC. For example sending a DESELECT command to the PICC after this step or sending an APDU wrapped with a PCB (1byte) and EDC(2 bytes) It is related to.
In short, how is the "Half-Duplex Block Transmission Protocol" described in EMV-D adapted for PN5180? Can you share a pseudocode about it? (The PICC here is an ISO-14443-A type.)
Note:
For EMV-D Half-Duplex Block Transmission Protocol: https://www.emvco.com/wp-content/uploads/2017/04/D_EMV_Contactless_Communication_Protocol_v2.6_20160... ( page: 217)
Related
I started reading into the topic of NFC/Smartcard-Communication and I found many different standards and commands depending on the Tag type (for example see here)
I also came across the APDU-commands which seem universal to the communication of nfc/smartcards?
Does this mean, that these higher level protocols are all based on apdu and can be translated?
As an example, I found NFC 14443-A commands implemented with the android.nfc.tech.NfcA library, such as:
Action
Byte
Read
0x30
Write
0xA2
And APDU commands like these:
Action
CLA
INS
P1
P2
LC
READ BINARY
0xFF
0xB0
...
...
...
UPDATE BINARY
0xFF
0xD6
...
...
...
GET DATA
0xFF
0xCA
...
...
...
MIFARE CLASSIC READ
0xFF
0xF3
...
...
...
MIFARE CLASSIC WRITE
0xFF
0xF4
...
...
...
The commands seem to be completely different.
It would also help alot, if someone could point to good documentation on the topic
Documentation I have found so far:
The Android documentation on nfca (Link)
APDU description on wikipedia Link
(The german version contains some return codes)
APDU commands (by a card-reader manufacturer) Link
You have it a bit wrong, 14443-3A is lower level that APDU's which come from the higher level ISO 7816 protocol.
But the Byte's ( 0x30 and 0xA2) you reference as NFC 14443-A are not from NFC 14443-A but look like vendor specific Mifare Ultralight protocol commands which are again above NFC 14443-A
There is also a complication and probably the reason you are confused with APDU's you listed according to the ISO 7816 spec, all the APDU's you specified have a CLA of 0xFF are "invalid".
The reason for this is that a USB readers also use ISO 7816 for the host CPU to talk the NFC chip to work mainly with NFC Type 4 Tags, because 0xFF are invalid for ISO 7816 the reader uses them for other non ISO 7816 things the NFC chip can do, e.g. communicate to non standard Mifare classic commands, turn on/off the LED's on the USB reader, etc
So really CLA's of 0xFF are just a way to wrap other commands.
Or in a rough pictorial form
I would read as much of the Standard specification documents shown in the Stackoverflow you linked to and I wrote. There are a lot of specifications used/part used
I know that they are really pay for items but they are out there on the Internet.
e.g.
http://www.emutag.com/iso/14443-3.pdf
http://www.emutag.com/iso/14443-4.pdf
For the higher level NDEF stuff https://github.com/haldean/ndef/tree/master/docs
For the Various NFC Forum Standards
Google Index of the 4 Types
I have a Xilinx Zybo board. I followed the instructions here and created a custom multiplier over the AXI bus. The multiplier shown on the website processes one input and generates one output. How can I modify it such that it can process streaming inputs sort of like a pipeline. Any hints?
In the tutorial, at Step 5 of "Create the custom IP", select AXI Stream interface rather than AXI Lite. Then modify the HDL source to have the proper signals for a streaming interface (mainly VALID, READY, and DATA). Then follow the rest of the steps to add the IP into your design in Vivado.
Note you'll have to create 2 streaming interfaces, one for input and one for output. Unlike AXI Lite where you can read/write a single register, a Stream is a one-directional flow of data.
EDIT: this doesn't address the way you'd test/stim from the SW side. The example will only work with an AXI Lite interface. You'd need a custom driver to work with the Streaming IF(s)
With an ACR122U I know you can transmit direct messages to the NFC controller (PN532) by using the direct transmit command: 0xff 0x00 0x00 0x00....
When I read the manual of the ACR1251U it say: The reader's peripherals control commands are implemented by using the PC_to_RDR_Escape.
What does this exacly mean? Does this mean it isn't possible to send direct messages to the NFC controller? If it is possible, where can you find which NFC controller it use?
Any information is welcome!
Thanks in advance.
The "direct transmit command" is an APDU format that permits you to send native commands to the PN532 NFC controller embedded in the ACR122U reader device. So this basically defines the wrapping to fit native commands into the APDU-based protocol that you talk to the reader over PC/SC (& CCID):
0xFF 0x00 0x00 0x00 <Lc> <DATA>
where <DATA> is actually a command for the PN532.
PC_to_RDR_Escape is the CCID message (device class/protocol that is spoken over USB) that is invoked by the PC/SC stack when you send an escape command. For instance, if you use the Java SmartcardIO API's Card.transmitControlCommand() method, the PC/SC stack will send a PC_to_RDR_Escape message over USB. THe reader answers this message with a RDR_to_PC_Escape response.
Similarly if you use the method CardChannel.transmit() method, this cause the PS/SC stack to issue one (or more?) PC_to_RDR_XfrBlock messages over USB.
As you found out in this answer, it seems as if you would use the APDU format of the "direct transmit command" for both command exchange methods.
Whether you need to use the escape command or the transmit command seems to depend on the firmware version of the reader. For instance, for firmware version 101, 102 (and 103?) you would typically only need the transmit command, but the next generation versions (2xx) seem to prefer/require (if they don't emulate an ATR) the escape command approach.
i want to send a ethernet frame from FPGA to my PC for wireshark to receive
i pass payload into CRC generator to get the CRC result, but i guess CRC error as wireshark not received any thing which is my payload
i got 2 ideas
1. find a ethernet frame in hex code in internet and copy to VHDL to send in order to make sure no CRC error and check whether it send or not? could you post a correct ethernet frame in hex code here?
1b. any free CRC generator code in VHDL available in internet? and any free CRC generator code in C++ language or C# language or Java language for hard code CRC in ethernet frame?
2. use layer 2 programming in ubuntu to send a ethernet frame to another computer,
whether i can send and display the ethernet frame which i send in ubuntu or i need to capture with wireshark in another computer?
Use your FPGA tools to create an Ethernet core. This will usually create a testbench for you too. Run that testbench, note down the values of the data produced.
As another alternative, there are some Python libraries I've used in the past to create Ethernet packets.
http://code.google.com/p/dpkt/source/browse/trunk/dpkt/ethernet.py
I've never used this, but it looks like it might be helpful:
http://packeth.sourceforge.net/packeth/Home.html
I want to learn and implement CAN BUS protocol. I have implemented UART,SPI,I2C and One Wire Bus protocol using MSP430 Launchpad in software. Now I want to learn about CAN Bus protocol. I have mBed LPC 1768 Cortex M3 Development board. mBed has Can Bus Library but I want to write my own library so that I can learn it in detail, i.e. the way I did for other communication protocols.
I am not able to find suitable resources to start with and the material appears to be scattered on net. Can any one guide how do i write and implement CAN Bus protocol with the development boards available with me.
Thanks
Developing CAN library is relatively easy as compared to I2C or SPI. This is because CAN Controller of your Cortex will take care of most of complex things.
To transmit the data, You have to write ID and Data in designated registers and set bit to transmit data.
This Application note from NXP can be very useful for you.
I would recommend you to implement following functions:
InitCAN - This should set specified Baud Rate of CAN.
SetFilters - Most CAN Controllers come with Acceptance Filters, So it's good to have that
SendData - Make sure you accept Parameters like ID_Type and RTRs etc.
RecieveData - This can be blocking or Interrupt based.
Before beginning, do read CAN Basics to understand. Application notes AN713 and AN754 from Microchip is a good source. Also Vector's site and Wikipedia Article.
Plus, You can always post your doubts here or on Electronics.StackExchange.com :)
Okay so this post is quite old but people may look at it again so:
First of all Can bus is not user friendly protocol like USART or IC2 at all so you have to be very precise about your can bit timing there are tools for that but I suggest you to calculate them by hand. For a microcontroller I would suggest STM32 and be away from PIC series in my opinion. If it's only CAN-BUS without higher level protocols such as SAE J1939, steps are pretty simple and straight forward:
1)Initialize Can
2)Put CAN to configuration mode and remember that you can set baudrate, mask and filters only in configuration mode!
3) Set the baud rate registers.
4) Set the mask and filters. If you need to receive all messages just simply set mask to 0x00. Then filter will be do not care.
5) Set the CAN to the normal or loopback mode. (loopback mode is used for debugging purposes mostly.)
Some remarkable points people try to implement can at the beginning may miss:
*** You need at least 2 working CAN nodes for successfull transmission. (of course with matching baud rate). So if you want to send some data via CAN with 1 node it will not be succesfull. Because your transmitter node will not receive ACK.
*** Most likely you will need a CAN tranciever. Do not forget to put a 100 ohm or similar value resistor between Tx and Rx pins of your tranciever.
I used the software canking to talk to a mcp25050 when I learned how to implement can protocol using an hcs12 dragonboard. It helped a lot because canking will initialize everything for you when u go on the bus and all you have to do is learn how to write and recieve. If you want to learn how to initialize the steps are:
Enables can bus by setting bit on CAN Control Register 1
Enable can initialization Control Register 0
wait until can bus is in initialization mode by checking control register 1 bit
Enables can bus by setting bit on CAN Control Register 1 again and set clock source - Ethier bus clock or eclock
set prescaler baudrate and Tq with Bus timing register
set sample time and prop_seg1, prop_seg2, and phase_seg
set acceptance id on Identifier acceptance register 0-3 or 0-7 - to set your can to recieve everything set those to 00 because when doing a compare the can bus does a ones complement compare with the id coming in
set Identifier mask register 0-3 or 0-7, if you want to not care about any of the bits set them all to FF
set identifier acceptance control register to 32 bit extended or 11 bit - i use 32
set Control Register 0 back to normal mode
wait until bus is normal mode by checking Control Register 1
after this you can start changing registers or reading data to do this you must select the empty can buffer, write your id to write or request data, and then input the address, mask, and value in the 3 transmitter registers if writing and then specify the dlc (3 if writing and 8-1 if reading). to transmit the id and data you then have to set the can transmit flag to equal the can Transmit buffer selection.
** depending on what id you use bit shifting can be tedious so if you are having a problem I would suggest debugging and looking at what your Transmit buffer selection registers are holding. I had this error because i did not shift correctly when i was sending messages to the mcp25050
If your MCU supports CAN Bus, you should start from the related datasheet.