Администрация форума не несёт ответственности за достоверность информации и оставляет за собой право редактировать или в особых случаях даже удалять посты без предупреждения. Спасибо за понимание.

Программирование ATMEL в BASCOM.

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

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


Вы здесь » Программирование ATMEL в BASCOM. » Вопросы - ответы » Как оценить загрузку ядра, или сколько потянет?


Как оценить загрузку ядра, или сколько потянет?

Сообщений 1 страница 5 из 5

1

Хай товарищи! Задача такого плана буферизатор с N количеством портов. Работа с с девайсами по UART на скоростях 19200.
Работа с ПК как угодно уже. Задача направлять пакеты от девайсов на ПК то есть с портов, с ПК на девайсы по адресам или без (с отправкой пакетов всем портам по очереди но так лучше не делать), составление списка девайсов автоматически и вручную.
Меня вот что интересует сколько портов получится слушать одновременно на такой скорости на Xmega на максимальной частоте.
По факту работа с девайсами симплекс, а вот с ПК дукплекс, передачи с девайсов 0 уровня не чем не координируются они могут передавать когда угодно. Остальные 1 уровня передают только после обращения сервера но не слушать их пока не было обращения не получится после старта любой девайс обращается к серверу до тех пора пока не получит что ему надо.

Со стороны буферизатора требуется передача по любому из портов + слушать все порты кроме симплексных на который идёт передача.
Разбор пакетов дело не спешное и трафик не большой
Кратко поясню симплексные порты для однопроводной линии малоактивных девайсов соединяются в большую простую сеть. В идеале мне надо 3 порта для 0 уровня, и 2 порта для 1 уровня но и 1 хватило бы пока.

Да ясно дело что 2-3 порта потянет думаю НО вот каждый порт это достаточно геморно как порт гальванически развязан или даже оптически, конопатить плату на 10 портов и собирать и получить потом 3-4 не совсем хочется!

Какие у кого предложения по поводу реализации?

Отредактировано RadioHAM-433 (2016-05-30 07:57:53)

0

2

XMega? Ну бери камень с тем количеством аппаратных портов, что тебе нужно. Далее делаешь всё через буфера (только не запутайся). Вся работа с портами будет асинхронная (между портами, не в самом порте (хотя и это зависит от настроек). Тут главное с буферами не переборщить.
На счет взаимодействия, я так не понял, придется самому тебе продумывать протокол обмена или как-то внешне управлять с пинов...
Если надо обрабатывать на лету пакеты с кучи портов и как-то реагировать или всё пихать в один (но тут прямая зависимость уже от скорости самого порта, если скажем входят два порта 19200, а данные надо отправить в 1 порт, то тут придется увеличивать скорость в разы, чтобы буфер приёма не переполнился только из-за этого, т.е. использовать обмен с компом на макс, а тут следовательно надо ставить кратный кварц МК, чтобы не было потерь при постоянной нагрузке).

0

3

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

Скорость в разы больше в строну ПК можно но не обязательно, время между пакетами задаётся на лету так что на ПК передать успеет.
Да все пакеты надо пихать в один порт, но траффик как я сказал маленький просто есть система с внешним получением данных ждать своей очереди на передачу неприемлемо потому как надо данные отправить сразу отправляет, и не редко бывает коллизия в другими девайсами. Для системы управления повторные передачи это почти провал как задержки будут порядка 1с, и так всё идёт через сервер задержка ~200-300мс но это нормально. Да еще и если на 1 ядре то есть МК то с эфира приёма не будет запущен пока сервер не разрешит что можно пропустить след передачи, загрузка ядра там по полной частота шума с приёмника 15-20Кгц с учётом что прерывание возникают и по спаду и по фронту то в 2 раза выше, хотя во время передачи данных загрузка снижается в разы. Потому такой режим не используется, передачи с эфира важнее.
Потеря пакетов от девайсой 1 уровня не страшна совсем будет повтор обращение там нет требований на время обмена, главное от 0 уровня не терять, так что если 0 уровень буфер забил то 1 уровень можно пропустить. Если сервер обратился не получит того что запрашивал еще обратился.
Вот что меня и интересовало это ресурсы сколько будет тратиться на передачу и на какой скорости. Запутаться с чего бы подобные вещи давно реализованы. Вопрос сколько портов получится слушать при передачи по одному. Может есть какие то данные про то сколько тактов тратится на какое действие? Я думаю лучше приём хранить в Byte массиве чем в String так меньше будет тратиться времени добавление принятого или нет String в принципе тоже 1 байт.

Но у Xmega много памяти на борту так что хватит буферизировать с 10-к передач. Кратко размер пакета не больше 255 Байт, от системы управления пакеты редко больше 50 байт но дублируются (в принципе все параметры настраиваются на лету), как прошла одна передача остальные можно не слушать, ясно дело каждая передача имеет свой номер так что всегда ясно дубль это или новая правда требуется разобрать поле системных данных они в конце но или не разбирая тупо перенаправить всё. Будет приоритет а на порты 0 они будут передаваться в первую очередь из буфера а 1 уровень уже после в любом случае, даже если в буфере будет уже лежать 10 передач 1 уровня и добавится 0 то след переда пойдёт 0 уровня в сторону ПК, после каждого добавления буфер сортируется.

Отредактировано RadioHAM-433 (2016-05-31 09:58:27)

0

4

RadioHAM-433 написал(а):

лучше приём хранить в Byte массиве чем в String так меньше будет тратиться времени добавление принятого

это вообще не принципиально, используй оверлей и учитывай длину стринга (на 1 байт больше, ибо он заканчивается всегда нулём)

RadioHAM-433 написал(а):

интересовало это ресурсы сколько будет тратиться на передачу и на какой скорости

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

зы: я в своё время писал, что ХМега на штатном RC 32МГц легко передавала/принимала данные в районе 8МБ/сек, всё зависит от реализации в железе и протоколе обмена (и это ещё не разогнанная).

0

5

Количество девайсов на одной шине не оговаривается, если 1 уровень то бесконечно, работа идёт разделёно по времени, тоесть есть мин время которое надо выждать на отправку пакетов на другой адрес, то есть после того как было принято свой адрес приём прекращается на определённое время так же как и не своего адреса. У меня сейчас 14 девайсов на одном порту, но не все в запаралелены конечно но на уровне данных 1 порт, на уровне физического подключения порты 4 порта гальванически развязаны.
Передачу слышать все девайсы, сервер слышит передачу всех девайсов, между портами связи нет, девайсы на 1 порту все слышат всех если однопроводная линия, а для 1 уровня как раз 1 проводная.
Мне нужен был протокол для 1 проводного подключения на длине кабеля гарантированно 15м с чем UART на 19200 справляется идеально, миним затрат времени на сборку а тут и сложность плату имеет значение, для фирменной многослойной платы не актуально а для домашней очень даже!
Задержки синхронизации странно не чё подобного не замечал.
Но а какой протокол будет рассчитан?
Нужно лишь сделать нормальную работу девайсов 0 уровня.
Производительность МК хаба тут само важное! Именно сколько портов он сможет слушать, но как я понял мы говорим на разных языках про разные вещи я думаю смысла продолжать нет.

Отредактировано RadioHAM-433 (2016-06-06 06:57:33)

0


Вы здесь » Программирование ATMEL в BASCOM. » Вопросы - ответы » Как оценить загрузку ядра, или сколько потянет?