Микроконтроллеры

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Микроконтроллеры » Всё остальное » Пятничное » Многоканальный энкодер-декодер кода Морзе


Пятничное » Многоканальный энкодер-декодер кода Морзе

Сообщений 31 страница 60 из 74

1

Простая по постановке задачка, но [наверно] не простая по реализации

Многоканальный энкодер-декодер кода Морзе
N каналов-пинов [пусть будет, например, 4], каждый может быть и передатчиком, и приёмником
По uart-у принимаются текстовые сообщения в формате "<номер канала><пробел><текст><перевод строки>"
Текст передаётся морзянкой по соответствующему каналу
И наоборот - при приёме морзянки по любому каналу, по uart-у передаётся соответствующее сообщение
Длительность точки в общем случае произвольная, но пусть будет, например, 100 мс плюс-минус 20%
Длительности остальных элементов - производные от длительности точки [по стандарту]
Для проверки работы к uart-у подключается терминал, а каналы коммутируются друг с другом

На каком мк и как это проще всего сделать, какие идеи?

31

MasterElectric написал(а):

если кол-во каналов не велико то конечно на прием захват таймером + ДМА

ОК, пусть тогда будет снова только 4 канала и тогда получается все за [ну или по крайней мере не против] dma и да будет dma )
Но два dma тогда получаются - на приём и на передачу, соотв два таймера, два порта и объединение соотв входных и выходных пинов снаружи мк, так?
Если длительность точки снова 100 мс +-20% [всё как в первоначальной постановке], то какие взять частоты выборки входов и выходов и какие размеры буферов?
И по входам двойная буферизация как Eddy_Em предлагал?

Закрепил первый пост топика сверху каждой страницы, есть в этом форуме такая фича

Отредактировано vt (2018-11-04 20:47:36)

32

10 мс тик таймера будет нормальным для декодирования, а вот как придумать автоматически определять конец символа не знаю)

33

MasterElectric написал(а):

а вот как придумать автоматически определять конец символа не знаю)

Я посмотрел несколько реализаций декодеров из любопытства
Все они одноканальные конечно
Вот, на мой вкус, как бы это выразиться - самая неплохая )
https://github.com/edgar-bonet/tiny-morse-decoder

34

vt клонит к тому... чтобы взять плату "метр на метр, как витрина магазина продовольственного"... усадить туда десяток МК... типа 51-х от узкобратьев... Ну что же... может тоже вариант... а для меня так не спортивно...

35

HHIMERA написал(а):

vt клонит к тому... чтобы взять плату "метр на метр, как витрина магазина продовольственного"... усадить туда десяток МК... типа 51-х от узкобратьев...

Не, в этот раз строго наоборот
Влупить как можно больше [но в пределах пятничного] функционала в одну программу и значит в один мк
И чтоб поэффектней, потому что для развлечения, но типа - сказка ложь, и далее по тексту )

Ну и заодно потыкать острой палкой в stm32, потому что я не могу уже спокойно смотреть на повсеместные бесконечные уморительно-серьёзные разборки с ними
Хотя у нас тут ещё ничего, гораздо лучше, чем в среднем по больнице инету )

Отредактировано vt (2018-11-04 22:10:06)

36

Эффекты... это для совсем маленьких... остальные просто не оценят...
Тут ещё вопрос кворума... кому это интересно до злободневности... а то все так и затихнет в общих фразах... Начни с передачи... хоть понимание придёт...

37

А зачем тебе многоканальную морзянку?
Вообще, действительно, если МК кроме морзянки ничего делать не будет, то можно вот как сделать: systick пущай миллисекунды отсчитывает, в бесконечном цикле в main проверяем счетчик, если новая миллисекунда - проверяем порты; правда, хреново в этом случае защиту от дребезга делать, но можно тремя-пятью миллисекундами пожертвовать, думаю (а то и всеми десятью, если морзянка должна быть человекопонимаемой). Ну и по мере появления данных набиваем буферы - здесь отлично подойдет КА.

38

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

39

А он не различает КА протокола от общего КА...

40

Eddy_Em написал(а):

А зачем тебе многоканальную морзянку?

В утилитарном смысле?
Ты заставил меня задуматься )
Или в смысле для какого девайса?
Для любого, которому подойдёт выбранный мк
А с учёчтом того, что Reflector говорил, что подойдёт любой мк, получается, что вообще для любого )

По-настоящему хардварный декодер - на verilog-e - cs.toronto.edu/~milic/csc258/report.pdf
Определение символа по коду не с помощью таблицы, а тоже как автомат [состояния - символы]

41

Если говорить о передатчике я бы взял простенький таймер, настроил на период точки и данные для передачи упаковал бы для каждого тика в последовательность которую нужно передать для морзе как раз хватает 32 бит. Например '2' это будет ..--- слово будет выглядеть как 101011101110111000 (учитывая паузу длинной в 3 точки) передача от старшего к младшему. Это для "ногодрыга". Так меньше манипуляций нужно проводить с данными.

42

Идея DMA, как я понимаю, испарилась

От спасительной простоты частностей к туманной сложности общностей )

Структуры данных:
Входной буфер uart-a, выходной [кольцевой?] буфер uart-a
N входных и N выходных буферов символов
N входных и N выходных битовых буферов элементов кода Морзе
Для всех входных буфера указатели текущего положения, для выходных - ещё и размер
Таблицы кодирования и декодирования
Что ещё или как-то по-другому?

Блоки кода:
Таймер приёма и N автоматов приёма
Таймер передачи и N автоматов передачи
[Автоматы в соотв обработчиках прерываний таймеров?]
Обработчик прерывания uart, парсер и форматер текста [прямо в обработчике?]
Что ещё или как-то по-другому?

43

Лично я решаю эту задачу с 1 мс на точку и 16 каналами на прием/передачу так намного интереснее, ну и ДМА тут не очень удобно использовать, да и с периодом в 1мс неуспеть сложно.

Раз терминалка специфичная, я бы сделал буфер на строку в 255 байт на канал, а когда мы все передадим делать типа запрос есть ли данные для передачи. Передавать в терминалку по идее можно в реальном времени.

А какая все-таки реальная цель создать учебную законченную программу, окуда можно потом выдирать куски кода?

44

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

45

Мне, кстати, пару недель назад товарищ занудил почему мой ЛА не умеет произвольные сигналы генерить и я прикрутил к нему простой генератор. В частности для нашей '1' можно написать "0 1 0 111 0 111 0 111 0 111 000" и задать интервал в 1000 us, или даже сразу на 4 канала вывести коды для 1/2/3/4, получится так: F0F1F2F5FAF572311000. И сразу можно захватить:

Свернутый текст

https://cdn3.savepice.ru/uploads/2018/11/5/96b57fadf9dd1c36d0e3733dcdeca78d-full.png

46

MasterElectric написал(а):

Раз терминалка специфичная, я бы сделал буфер на строку в 255 байт на канал, а когда мы все передадим делать типа запрос есть ли данные для передачи.

Терминалка не специфичная - обычный любой текстовый терминал [то есть эмулятор терминала на пк]

MasterElectric написал(а):

А какая все-таки реальная цель создать учебную законченную программу, окуда можно потом выдирать куски кода?

Да почему учебную, хоть какую-то, но программу, а не пример/тест/фрагмент/набросок
Ну и три дня выходных впереди было

47

MasterElectric написал(а):

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

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

48

Кстати, подобная хреновина вполне пригодилась бы для дешифровки морзянки в радиоэфире. А еще, собрав элементарный искровой передатчик (а моща у него может быть вполне приличной) и прикрутив антеннку для приема, можно с кем-нибудь общаться морзянкой, нехило так засирая всем остальным эфир! =D
На ЕГЭ детишкам ответы фигачить: ни одна глушилка не попрет против искрового передатчика!

49

Кстати кто-нибудь работал с FTDI на Delphi через их модуль? а не как с виртуальным Com портом. Хотелось бы пожевее передавать данные и минимизировать время между пакетами.

50

MasterElectric написал(а):

Кстати кто-нибудь работал с FTDI на Delphi через их модуль? а не как с виртуальным Com портом. Хотелось бы пожевее передавать данные и минимизировать время между пакетами.

Если узнаете, как их библиотеку (для MSVC только) пере-конвертировать для другого компилятора (в частности интересует GCC MinGW), поделитесь рецептом ;)
А так - там ничего сложного нет, все описано в их доках. Ну по крайней мере лет 10 назад так было :)

Отредактировано MasterAlexei (2018-11-06 08:41:28)

51

vt написал(а):

Да почему учебную, хоть какую-то, но программу, а не пример/тест/фрагмент/набросок

Хотя в каком то смысле может быть и учебную, но в смысле метода, не кода
Метод называется timed automata [в русской литературе - таймированные автоматы]
Суть в том, что в отличие от конечных автоматов, подсчитываются и используются такты пребывания автомата в том или ином состоянии [состояниях]
Логика таких автоматов завязана со временем, но не зависит от частоты тактирования, поэтому задачи реального времени проще моделируются на компе

52

Я что-то совсем разочаровался в попытках писать библиотеки, никогда не получалось удобно и универсально. Сейчас пишу работу с USART под F429 в рамках пятничного проекта, планирую ДМА в оба направления + таймер на таймаут, никиой универсальности совсем уже не хочеться, это только мега замедляет процесс разработки.

53

MasterElectric написал(а):

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

мне тоже так кажется.

54

MasterElectric написал(а):

ДМА в оба направления

Нет никакого смысла делать DMA на прием: лучше в прерывании по получению очередного символа проверять этот символ и заполнять буфер с контролем переполнения (туда же контроль таймаута можно воткнуть). Ну, а когда все ОК, менять буфер на следующий, а для этого выставлять флаг готовности. Вот отправлять с DMA удобно, это да.

55

Еще нужно с периодом в 100мкс (это если точка 1мс) считывать и обрабатывать 16 каналов по приему морзянки. Пусть себе в фоне принимает, контроль по переполнению и так есть, таймер попробую запускать по IDLE. Вот как примет буфер тогда смотрим какой канал перекидываем указатель на него, а на прием новый буфер. Если нужна сверх надежность КС добавить и ответ послать что приняли пакет нормально.

56

Проблема не в том, чтобы написать программу [ф-цию, модуль и т.п.], которая работает [вроде бы, где-то, как-то] , а в том, чтобы доказать [и себе, и другим], что она работает правильно
Иначе в программировании нет объективного смысла - результата, а есть [может быть] только субъективный - процесс )

57

Не задумывался... не страдаю этим... просто получаю удовольствие от решения задач своими способами, написания программ, отвлекаюсь от основной работы... мечтаю написать что-то значимое)

58

уже пиликает))
http://sd.uploads.ru/t/hEDLl.png
это первый результат работа продолжаеться

59

думал как проверить многоканальность, оказалось стандартная терминалка умеет со скриптами работать.
http://s3.uploads.ru/t/fvzGs.png
SOS по 6 каналам

60

А можно ли такими передатчиками проверить приёмники, которые должны работать в диапазоне +-20% ?
Если нет, то придётся придумывать какой-то другой способ проверки приёмников


Вы здесь » Микроконтроллеры » Всё остальное » Пятничное » Многоканальный энкодер-декодер кода Морзе