[Loreleja 0]

Уважаемые, помогите решить проблему!

Внешнее прерывание INT0 от одной дорожки магнитной карты. Прерывание настроено по любому изменению.

В обработчике тупо счетчик считает количество возникших прерываний и выдает по юарту.

Кто сталкивался с магнитными картами, в курсе, что на 1 дорожке как минимум 240 перепадов уровня - это я округлила. Но почему то с каждой карты счетчик упорно выдает от 35-45 - не больше.

В чем может быть проблема? С электроникой всё в порядке, на осцилографе видна четкая картина данных в виде миандра.

МК - atmega16U4, таймер пока в сторонке не юзается.

 

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

code.txt

[andrewkrot 0]

Похоже, что интервал между прерываниями гораздо меньше времени на передачу одного байта в УАРТ. Нужно сделать примерно так -

1. Организовать буфер передачи в ОЗУ;

2. Организовать прерывания по окончанию передачи байта в УАРТ;

3. По прерыванию INT данные для передачи просто писать в буфер;

4. По прерываниям УАРТА проверять пустой ли буфер, и если не пустой то брать очередной байт и толкать на передачу.

[Loreleja 0]

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

 

Проблему решила следующим образом:

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

 

к сожалению, основной проблемы это не решило :( ...

Возможно вы сможете помочь?

 

Программа для кард-ридера написана под atmega8 c кварцем 7,3 , я её переделываю под atmega16u4 c кварцем 8.

Сама программа по сути универсальная, то есть её алгоритмы, но она упорно не хочет правильно работать. Каждый раз выдает ошибку проверки LRC.

 

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

 

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

magstripe.txt

timer.txt

uart.txt

board.txt

avr_cunit.txt

[vesago 0]

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

[andrewkrot 0]

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

[rx3apf 0]

видимо не очень уважаемые... а зачем? ведь можно нагрузить программиста голову поломать...

:smile3046:

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

Но так делать - вообще-то извращение. По-хорошему, надо писать полноценный декодер, и отдавать хосту уже готовые данные.

 

 

Задача эта элементарно решается без всяких дополнительных ис.

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

[IgorKossak 0]

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

Модератор.

[Loreleja 0]

Уважаемый rx3apf, я очень благодарна за внимание к моей проблеме, но не могли бы вы изъясняться более простыми словами. Я в программировании еще новичок и ваш сленг понимаю отчасти, из-за чего общий смысл поста вообще утерян ))

По поводу программы, так сказать, свежие новости. Поочередно отключив считывание то одной, то второй дорожки, было обнаружено, что они таки корректно считываются, декодируются и даже проходят все проверки! Не каждый раз конечно, это тоже проблема... Хотя временные интервалы правильны каждый раз.

Но только по отдельности, при отключенном втором внешнем прерывании... Как бы это решить?

Юарт запихнула по переполнению таймера, так что он не влияет на прием данных.

[Loreleja 0]

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

 

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

 

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

[rx3apf 0]

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

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

[Loreleja 0]

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

 

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

 

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

[vesago 0]

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

 

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

[Loreleja 0]

Loreleja, может у Вас в принципе алгоритм декодирования не очень? Каков он?

 

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

я в замешательстве :(

[rx3apf 0]

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

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

[Loreleja 0]

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

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

 

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