Уважаемые, помогите решить проблему!
Внешнее прерывание INT0 от одной дорожки магнитной карты. Прерывание настроено по любому изменению.
В обработчике тупо счетчик считает количество возникших прерываний и выдает по юарту.
Кто сталкивался с магнитными картами, в курсе, что на 1 дорожке как минимум 240 перепадов уровня - это я округлила. Но почему то с каждой карты счетчик упорно выдает от 35-45 - не больше.
В чем может быть проблема? С электроникой всё в порядке, на осцилографе видна четкая картина данных в виде миандра.
МК - atmega16U4, таймер пока в сторонке не юзается.

Код программы в прикреплённом файле...

Похоже, что интервал между прерываниями гораздо меньше времени на передачу одного байта в УАРТ. Нужно сделать примерно так -
1. Организовать буфер передачи в ОЗУ;
2. Организовать прерывания по окончанию передачи байта в УАРТ;
3. По прерыванию INT данные для передачи просто писать в буфер;
4. По прерываниям УАРТА проверять пустой ли буфер, и если не пустой то брать очередной байт и толкать на передачу.

Да, спасибо огромное!

Проблему решила следующим образом:
данные записываю в массив, по переполнению таймера проверяю наличие данных и если есть - передаю по уарту.

к сожалению, основной проблемы это не решило ...
Возможно вы сможете помочь?

Программа для кард-ридера написана под atmega8 c кварцем 7,3 , я её переделываю под atmega16u4 c кварцем 8.
Сама программа по сути универсальная, то есть её алгоритмы, но она упорно не хочет правильно работать. Каждый раз выдает ошибку проверки LRC.

Весь проект крепить не буду, смысла нет. Только основное - файл magestripe, настройка таймеров, юарта, файл с переменными (board.txt) ну и мейн (avr_cunit)...

Буду очень благодарна за любые предположения!!!

Где-то в софте косяк. Сперва нужно убедиться, что ваш ридер выдает в том формате, который вы ожидаете. В чистом виде это ф2ф, но может быть встроенный преобраз клокдата. Допустим ф2ф. Сначала нужно научиться принимать данные. Настройте программу, чтобы выдавала данные, которые считала без проверки битов паритета и лрц. Считайте допустим банковскую карту. Обычно сначала валят нули, потом тетрада B, в конце F. Добейтесь чтобы четко выдавало B. Если с приемом все в норме, значит некорректно считает лрц. лрц = B xor x1 xor...xor F.

Еще раз повторю - у Вас драгоценное процессорное время тратится на программный опрос готовности УАРТА! Сделайте передачу/прием по прерываниям так как я выше говорил, и половина проблем скорее всего пропадет=)

_Голову_ ! Так вот, не надо страдать ерундой - если так хочется передавать на обработку сырые времянки - то Бога ради. Семплируем, считаем, сохраняем (у камешка килобайт на это дело, по байту на смену уровня это более чем достаточно). Закончили (по таймауту или заполнению) - отдали пакет времянок хосту. Причем пакет, оформленный по-человечески - какая-то преамбула, времянки, контрольная сумма. Тогда надо следить лишь за flow-control при обмене, если хост может тормозить.
Но так делать - вообще-то извращение. По-хорошему, надо писать полноценный декодер, и отдавать хосту уже готовые данные.



+1024. Решение на микроконтроллере и проще, и гибче, и дешевле. Работа совершенно ерундовая.

Разговоры не по теме скрыл.
Модератор.

Уважаемый rx3apf, я очень благодарна за внимание к моей проблеме, но не могли бы вы изъясняться более простыми словами. Я в программировании еще новичок и ваш сленг понимаю отчасти, из-за чего общий смысл поста вообще утерян ))
По поводу программы, так сказать, свежие новости. Поочередно отключив считывание то одной, то второй дорожки, было обнаружено, что они таки корректно считываются, декодируются и даже проходят все проверки! Не каждый раз конечно, это тоже проблема... Хотя временные интервалы правильны каждый раз.
Но только по отдельности, при отключенном втором внешнем прерывании... Как бы это решить?
Юарт запихнула по переполнению таймера, так что он не влияет на прием данных.

Снова прошу вашего совета!

функция f2f явно не успевает обработатывать прерывания, из-за чего и ошибку выдает. Создала массив из 300 unsigned short int (2 байта) для хранения временных интервалов с трека 2. Но на 900 интервалов с трека 1 памяти уже естественно не хватает...

как же поступить теперь? может можно как-нибудь сократить f2f, что бы меньше времени на обработку уходило? я пока не нашла выхода...

А зачем двухбайтовые счетчики ? Отмасштабировать до одного байта, с учетом возможных длительностей и вариации скоростей протяжки...

да, была такая идея, но ни к чему на практике не привела. Даже если значение таймера будет в 1 байт, то 300+900=1200, всё равно никак не помещается...

как вариант, может переписать функцию на асме, ну я пока не надумала как это сделать...

Loreleja, может у Вас в принципе алгоритм декодирования не очень? Каков он? Если одну дорожку декодировать, то проблем нет. Для одной дорожки я бы наверное делал так. Вначале идут нули для синхронизации. Т.е. можно определить временные характеристики данного семпла измеряя время между дерганиями ноги. Как только появится перепад отличающийся соответсвенно по времени - пошла единица начала посылки - B. После этого начинаем по каждому прерыванию, зная длительности 0 и 1 складывать в буфер биты. Также контролируем таймаут. На банковской карте на дорожке порядка 40 байт.

Если сразу несколько дорожек, то сложнее. Скорость протяжки может быть разная и длительности могут быть довольно малыми. Тут надо мудрить со вложенными прерываниями. Наверное. Вейганд я сразу 4 канал декодировал, но там длительности млс. Может проц пошустрее задействовать или применить на каждую дорожку свою мегу?

вряд ли проблема в декодаровании. Ведь по отдельности дорожки отлично считываются и выдают правильную инфу. Тем более что эта програ приспокойненько себе работала на atmega8 c кварцем 7,3 , то есть скорость обработки и того была меньше. А тут получается и кварт побольше, и мега покруче, а всё равно не пашет...
я в замешательстве

Я бы, пожалуй, не стал работать с прерываниями от входного сигнала, а вместо этого просто по таймеру, с достаточным оверсемплингом, опрашивать каналы. Дискриминацию длительностей можно вообще сделать по одной дорожке. Определились со скоростями и погнали битовые потоки в накопители...

по одной дорожке никак не получится, там ведь интервалы разные. трек 2 длительность длиннее, там бит меньше...

может стоит кварц побольше поставить?

А... Я работал только с однодорожечными, значит, неправ...


Каковы длительности интервалов при максимально возможной скорости протяжки ? Ну примерно ?

если память мне не изменяет, частота на дорожке 1 около 1кГц, на дорожке 2 - 600...700 Гц.

1 kHz максимальная ? Т.е. один полупериод 0.5 mS, это почти 3700 тактов процессора @7.3728 MHz. Думаю, если писать компактно (и на ассемблере, вероятно), то все три канала удастся обработать по опросу, сделав этот опрос где-то 8...16 kHz (можно и больше, вполне хватит быстродействия). Но да, это все ж сложнее, чем считать времянки и писать их в буфер...

да уж. запихивать всё в буфер и так не получится... но что ж теперь с этим обработчиком делать?...

Ну, начнем с того, что при таких скоростях поступления данных можно, без всяких проблем, отправлять через UART (до 921600, используя, скажем, FT232), и буфер не то, что не переполнится, да и вообще не нужен - скорость обмена через UART заведомо больше, чем скорость поступающих сырых данных, даже если два байта на отсчет. Но, поскольку компьютер может и притормозить, по-хорошему надо все же следить за потоком, поэтому программный FIFO и обслуживать прерывания UART. Ну, если компьютер притормозит надолго - часть данных по-любому пропадет. Да и неправильный это путь.

А правильный - писать свой декодер (я бы делал семплирование входов по таймерным прерываниям и разбор потока). Да, это сложнее. Но - правильнее.

я пока не представляю себе как реализовать, то что вы предлагаете. Мы же калибруем длительность импульсов уже при приеме данных, там для этого вначале нули идут не информационные.

ну, в общем поставила кварц на 14 МГц, но блин, данные он то принимает, но для перезаписи перестал заходить в бутлоадер...

По ним и синхронизируемся. Нули - значит, нули. Более-менее стабилизировались длительности - приняли за ноль, вычислили порог дискриминации (там бифазное кодирование ? У меня бифазное было), используем его при дальнейшем приеме (если протяжка ручная - то по ходу дела регулируем этот порог в зависимости от длительностей поступающих импульсов). Ничего такого сложного (для трех дорожек, да еще с разными скоростями - чуть сложнее, конечно). Кончились нули, пошли данные - замечательно, наполняем буфер. Кончились данные (по таймауту, наполнению буфера и/или анализу содержимого) - проверили контрольные суммы, оформили посылку в удобный и однозначно-трактуемый формат (возможно, дополнив своей контрольной суммой и заголовком), передали в компьютер. Хорошая тема, интересная...

честно говоря, боюсь что-то кардинально менять. Мне этот проект еще переделывать потом как HID клавиатуру, что бы данные не в дебаг, а в текстовый редактор... а там еще и прерывание от usb идёт, ох...