Кто-нибудь програмил несколько AVRов по UART-у ? - Страница 2

GEN_4 · 08.12.2006, 16:05

Так используйте Modbus RTU:
данные передаютяс не символ/полубайт а
непосредственно байтами.
Посмотрите вот здесь:
http://www.fractal.com.ru/_pdf/description/4_22.pdf
тут реализована почти полноценная BIOS.
А в Вашем случае протокол Modbus можно упростить за
счет изъятия из запроса адреса внутри контроллера
и заменить его несколькими командами, в которых
он будет defaul-том по смыслу команды. Например
запрос на чтение данных:
‹CID›‹0x70›‹ADR_Hi›‹ADR_Lo›‹DIG‹CRC16_Hi›‹CRC16_Lo ›
можно заменить на
‹CID›‹0x70›‹DIG‹CRC16_Hi›‹CRC16_Lo›
если известно что данные всегда читаются с адреса
наприер 0x1000
И т.д.
Куда уж проще.

nml · 08.12.2006, 17:11

Сообщение от GEN_4

Так используйте Modbus RTU:
данные передаютяс не символ/полубайт а
непосредственно байтами.

Ну тот протокол о котором говорил я - по сути, и есть то же самое. Только без умного названия. Ну и я не использую CRC16 - явное излишество, CRC8 более чем достаточно.

Цитата:

тут реализована почти полноценная BIOS.

... ну а городить "BIOS" для таких микроконтроллеров - IMHO, то же самое, что прицеплять "зубренок" к мопеду. Для чего нужна та "базовая прошивка"? Для программирования? А что мешает пользоваться просто программатором? И ради этого по сути отказаться от прерываний и возможности писать программу на ЯВУ? Не, наверное, я просто чего-то недопонял.

GEN_4 · 12.12.2006, 11:48

Цитата:

... ну а городить "BIOS" для таких микроконтроллеров - IMHO, то же самое, что прицеплять "зубренок" к мопеду. Для чего нужна та "базовая прошивка"? Для программирования? А что мешает пользоваться просто программатором? И ради этого по сути отказаться от прерываний и возможности писать программу на ЯВУ? Не, наверное, я просто чего-то недопонял.

Согласен с Вами, что описание базовой прошивки
не очень читабельно. Я говорил об этом автору, но видимо он сильно занят.

"Базовая прошивка" является ядром или основой для
разработки Soft большой гаммы управляющих контрол-леров. При этом программист может сосредоточиться на
решении своей специфической задачи и избавлен от
рутинной необходимости написания и отладки обработ-
чиков стандартных интерфейсов. Что касается програм-
мирования, то RS-485 легко развязыавется оптически
от Host машины (т.е. PC)=› использование ноутбука
без боязни "спалить" его. Далее, в прошивке есть
команды обращения к поддерживаемуму каналу i2c.
Если на i2c сидит контроллер с такой же прошивкой,
то не составит труда "заливать" программу и в него
используя контроллер сидящий на RS-485 как "шлюз"
(какой программатор это сможет обеспечить?)

nml · 12.12.2006, 12:37

Сообщение от GEN_4

"Базовая прошивка" является ядром или основой для разработки Soft большой гаммы управляющих контрол-леров. При этом программист может сосредоточиться на решении своей специфической задачи и избавлен от
рутинной необходимости написания и отладки обработ-
чиков стандартных интерфейсов.

В том случае, если эта "широкая гамма" не-реалтаймовых задач. А вот мне, например, частенько приходится обрабатывать хитрый датчик положения двигателя - три линии типа "трещотка", причем из-за особенностей изготовления часто перекрывающихся. Для этого нужно прерывание таймера ~80 мкс. Или, например, мне нужен ШИМ. Или...

Да я могу написать вам несколько десятков случаев, когда этот "БИОС" ляжет программисту поперек дороги.

Ну а "рутина обработки стандартных интерфейсов" - тоже не совсем соответствует действительности. Например, у меня есть отлаженный модуль обработки приема ранее обсуждаемого псевдо-MODBUS. И никакой рутины - просто я этот модуль использую и в других разработках. При этом - если есть необходимость - изменяя где надо (например протокол поменялся). Уверяю, времени это особо не отнимает.

А зашиваю программу в МК я до сих пор своим программатором - 5 проводков на LPT или простенькая схема Громова на COM. И через этот же шлейф отлаживаюсь (тоже, кстати, realtime).

Правда, я использую АВРки, а не PIC - последние мне категорически не понравились архитектурой. Как говорил какой-то авиаконструктор - некрасивый самолет и летать будет плохо.

GEN_4 · 12.12.2006, 16:36

Цитата:

В том случае, если эта "широкая гамма" не-реалтаймовых задач. А вот мне, например, частенько приходится обрабатывать хитрый датчик положения двигателя - три линии типа "трещотка", причем из-за особенностей изготовления часто перекрывающихся. Для этого нужно прерывание таймера ~80 мкс. Или, например, мне нужен ШИМ. Или...

Так а кто запрещает использовать встроенный таймер и
прерывания от него. Более того работу BIOS легко
блокировать/разблокировать "по ходу пьесы".
Такая система используется тогда, когда контроллер
состоит из нескольких готовых блоков/модулей
объединенный межмодульным интерфейсос i2c.
Например для управления ШД используется готовый
контроллер а перемещение и направление вращения
задает управляющий контроллер или PC (скажем
в процессе отладки).

nml · 12.12.2006, 17:39

Сообщение от GEN_4

Так а кто запрещает использовать встроенный таймер и прерывания от него.

Да, посмотрел, хоть и кривовато - но можно. Есть возможноть включения в "цепочку" проверки, что за прерывание. Кстати, эта особенность архитектуры PIC была одной из причин, почему я отказался их использовать (один вектор на несколько прерываний). По моему, отдельный вектор на каждый источник прерывания - гораздо логичнее.

Ну да бог с ним. Получить максимальное быстродействие программы может и не всегда надо. А возможно ли использование языков высокого уровня для такой системы? Мне почему-то кажется, что нет. И тогда возникает противоречие.

С одной стороны, система задумана для упрощения (читай - ускорения) разработки программ для МК. Принцип - быстренько слепить рабочую систему из кубиков. В общем, логично.

Но при этом писать свой софт придется на асме. А писать на асме для PICов (даже 18 серии) - удовольствие то еще.

Мне кажется, что используя Си, я и без наличия "BIOSа" напишу гарантированно работающую программу значительно быстрее. И при необходимости смогу выжать из МК все возможности по быстродействию.

NemoCut32 · 12.12.2006, 20:51

Ребята! Я вот например полностью согласен с nml. И сам так делаю. Нафига излишества, мы же не о пользе BIOS говорим. У него есть главный недостаток - "чужой", а значит надо городить интерфейс и т.д. Так вообще можно до RTOS допрыгаться, а надо ли это здесь.
Вообщем протокол может быть любой, лишь бы в его составе присутствовал сетевой адрес (идентификатор).
Определитесь с выбором следующих вещей:
1) наличие нескольких master (т.е. когда несколько устройств могут одновременно асинхронно инициировать обмен по шине), от этого зависит тип протокола и арбитраж шины
2) режим работы сети: симплекс, полудуплекс, дуплекс (сильно зависит от п.1.)
3) скорость обмена - т.е принципиально что требуется большая скорость или надёжность (от этого зависит тип передачи, защита, к.с.)
4) физический интерфейс и тип обмена - синхронный, асинхронный, чётность, количество бит, возможность наличия в линии ошибок
5) допустимый отклик - таймауты между байтами и между посылкой и ответом
6) логический обмен: кто кому что посылает и кто когда и как должен ответить, типы передаваемых данных
Далее из вышеперечисленного сначала разрисовывается модель сети верхнего уровня (например один запрос - один ответ + широковещательные посылки). Затем выбирается (придумывается) протокол верхнего уровня и если нужно то арбитраж, например:
M: ‹Адрес(1 байт)*›‹Команда(1 байт)›‹Запрос(1 байт)›‹Параметры(N байт)›
S: ‹Адрес(1 байт)*›‹Команда(1 байт)›‹Статус(1 байт)›‹Данные(N байт)›
*Больше 0x80: означает широковещательную посылку или маску групп.
Следующим шагом выбирается транспортный протокол, который может зависеть уже и от физики например:
M: ‹Длина данных(1 слово)›‹Данные(N байт)›
‹Контрольная сумма CRC8(1 байт)›
S: ‹Длина данных(1 слово)›‹Данные(N байт)›
‹Контрольная сумма CRC8(1 байт)›
Старт посылки - любой байт после паузы 5 мС(или сброс на начало приёма), таймаут между байтами не более 2 мС, таймаут между запросом-ответом например не более 100 мС. На неправильную ошибочную посылку слэйв не отвечает.
Остаётся выбрать тип и скотрость обмена: 115200 8N1,
вот и готовый симметричный протокол. Просто я такие больше люблю, а так например мастер может посылать запрос в одном формате, а получать ответ в другом. Физика: Один мастер много слэйвов, одна линия, симплекс, RS485 c оптической развязкой и питанием по четвёртому проводу.
Это мы прошлись сверху-вниз, иногда приходится делать снизу-вверх и обратно в зависимости от сложности задачи и технической реализации. Но прошу Вас не делайте сразу снизу-вверх (от железа к постановке задачи верхнего уровня) иначе рискуете получить уё...ный протокол, на таком же "железе" и потратить при этом уйму денег, времени и нервов. Примеров таких масса.
Желаю удачи! Если что пишите подробнее, можно придумать и что нибудь поконкретней.

nml · 13.12.2006, 01:02

NemoCut32 - спасибо за самый, пожалуй, толковый и развернутый ответ. Прям хоть в учебник

А то мы тут уже чуть ли не до уровня "чем АВР лучше ПИКа" съехали.

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

GEN_4 · 13.12.2006, 11:47

Цитата:

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

С этим трудно не согласиться: делать полинг флагов
при обработке прерывания занятие не самое приятное.
В AVR вызов свого обработчика на каждое событие -
гораздо более привлекательно, но есть и свой минус:
необходимсть сохранения контекста в RAM, поскольку
в iar c не блокируются регистры r16...r31.
Вообще, сравнивать pic и avr - дело неблагодарное
и тому немало примеров (например форум microchip.ru)

Цитата:

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

Это не так. Как раз "базовая прошивка" (БПр)
согласовывалась для работы совместно с СИ.
Я занимался "приручением" СИ для работы с БПр и
результат вот здесь:

http://www.fractal.com.ru/index.php?...x&sp=p_c&ssp=c

аналогично использование и компилятора c18 HiTech

В настоящее время мной разработана аналогичная
BIOS для AVR m128 и решен вопрос ее использования
с iar c почти в полном объеме. Здесь оказалось
удобным разместить ее в boot области а неиспользуемые
вектора прерывания делегировать в область вектров СИ.

Цитата:

С одной стороны, система задумана для упрощения (читай - ускорения) разработки программ для МК. Принцип - быстренько слепить рабочую систему из кубиков. В общем, логично.

Да, это ключевой принцип использования данной
системы. Мне пришлось сделать около десятка
проектов на БПр, скорость однажды дошла до
2.5 дня от ТЗ до готового прибора: измеритель
параметров кондиционера (10 точек измерения
температуры + 2 точки давление 0..5V + частота
вращения крыльчатки + внутренний LCD и все это
связать с PC + программа поддержки для PC)

Цитата:

Мне кажется, что используя Си, я и без наличия "BIOSа" напишу гарантированно работающую программу значительно быстрее. И при необходимости смогу выжать из МК все возможности по быстродействию.

В этом нет сомнений, но и Ваша квалификация,
я полагаю, оценивается в $ уж никак не меньше цисла
3-мя нулями на конце и не 1-ей вначале.

nml · 13.12.2006, 12:37

Сообщение от GEN_4

В этом нет сомнений, но и Ваша квалификация, я полагаю, оценивается в $ уж никак не меньше цисла 3-мя нулями на конце и не 1-ей вначале.

Увы, я живу в интересной стране Белоруссии, и вы ошиблись в оценках на один нолик

Впрочем, недеюсь, квалификация не этим меряется. Но, по моему, мы совсем отвеклись от темы. Сам себе выношу предупреждение.