NFC: ограничение длины APDU и SNEP

Я работаю над проектом, чтобы обмениваться большими данными с ПК на Android-устройство через NFC. Я использую ACR122.NFC: ограничение длины APDU и SNEP

Ниже приводится общее Exemple данных, отправленное:

// ADPU 
FF FF 00 00 00 nn // CLA, INS, P1, P2, Le, Lc 
D4 40    // TFI, PD0 
01     // (Mi), Target 

// LLCP 
13 20    // DSAP, PTYPE, SSAP 
00     // Sequence 
D4 40    // TFI, PD0 

// SNEP 
10 02    // Protocol Version, Action 
nn nn nn nn   // Total SNEP Length 

// NDEF Header 
A2     // First byte (MB = 1, ME = 0, Cf = 1, SR = 0, Il, TNF) 
22     // Type length 
mm mm mm mm   // Payload length 

// NDEF Content 
61.....65   // Type (34 bytes in that case) 
01.....01   // Payload (mm mm mm mm bytes)

Здесь я посылаю записи (не короткую запись) .so заголовка ЦНКА позволяет ввести 4 байта длину полезной нагрузки.
Окончательно, мой вопрос в том, как мы можем отправить такую большую полезную нагрузку в отношении 1-байтового APDU Lc?
Если это ограничение связано только с чипом pn532 или PS/SC, какое альтернативное оборудование вы бы предложили?

Спасибо за любые разъяснения

EDIT:
Я нашел то, что искал здесь:
Sending Extended APDU to Javacard
Это аппаратная проблема, PN532 не поддерживает расширенную APDU.

источник

2015-11-18 Inset07

Вы не можете разделить данные на куски? просто из любопытства, насколько он велик? –

Разделение в куске подразумевает указание номера последовательности (LLCP). Номер последовательности не может выйти 16 (4 бита). 16 последовательностей ~ 250 байт очень далеки от возможного значения FF FF FF FF длины полезной нагрузки SNEP. Я просто экспериментирую с NFC, но я пытаюсь отправить около 100 кб. – Inset07

Я могу просто смутить вас. но 100 k (байт) звучат как огромное количество, за которое обычно могут обрабатывать эти теги. поэтому, если я правильно понимаю, у вас недостаточно памяти для ваших требований на карте? в этом случае ваша проблема - это карта, а не вспомогательное оборудование. –

Как вы уже узнали, ACR122 не поддерживает расширенный APDU из-за ограничения чипа PN532.

Однако нет необходимости упаковывать всю передачу SNEP в один APDU. Вы можете разделить полезную нагрузку на несколько меньших кадров и отправить их один за другим. Важно только, чтобы заголовок NDEF передавался в целом в первом кадре.

источник

2015-11-19 02:51:21

Вы имеете в виду разбивку на записи chunk? Поскольку я понимаю процедуру записи фрагмента, мне нужно указать номер последовательности N (s), R (s) для каждой отправленной команды, верно? Но порядковый номер является полем 4 бит, поэтому он не может превышать 16 (десятичный). Отправка 16 последовательностей ~ 250 байтов недостаточно для того, что я хочу сделать. – Inset07

@ Inset07, не волнуйтесь, если вы достигнете кадра 16, просто оберните его и продолжите с номером кадра 0. –

@ Inset07, честно говоря, не имеет большого значения, что вы должны сами указывать числа кадров. Читатель должен следить за ними. Это часть гарантированного протокола доставки. –

ответ

Смежные вопросы