ivanhoe77 0 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба Кто делал проект на А5 или подобные? Думаю начать ли проект на RTOS (правда под эту платформу почти все платное) или на QT? В проекте идет упор на визуализацию. Это многоязычное иерархическое меню. Порядка 30 разных экранов. Отрисовка графиков. И хотелось бы переносимости на новые платформы. Проект делается на века. ) RTOS даст быстрыю загрузку и малый код. Но QT ускорит скорость разработки, что еще важнее. Потребление не так важно. Есть место для большой батареи. К тому ж прибор работает по 10 минут каждые 2 часа. P.S. Также неспешно ищется разработчик (по удаленке) на этот проект. ЛС пока недоступна. В профиле есть аська и скайп. Спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lotor 0 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба RTOS даст быстрыю загрузку и малый код. Но QT ускорит скорость разработки, что еще важнее. А почему только QT рассматриваете для linux? Для embedded имхо FLTK больше подходит. Вы бы сосредоточились в одной теме со всеми вопросами. А то каждый день новая тема по "Cortex-A5": http://electronix.ru/forum/index.php?showt...=121252&hl= http://electronix.ru/forum/index.php?showt...=121259&hl= Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба И хотелось бы переносимости на новые платформы. Проект делается на века. ) RTOS даст быстрыю загрузку и малый код. Но QT ускорит скорость разработки, что еще важнее. Потребление не так важно. Есть место для большой батареи. К тому ж прибор работает по 10 минут каждые 2 часа. Почему бы не взять планшет для визуализации? Нынче на Embarcadero XE6 можно создать проект и скомпилировать его одновременно под iOS, OS X, Android, Win 8 без изменения кода и пользовательского интерфейса. Вот это будет переносимость! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба и маленькую платку с блютус или wifi для сбора данных и передачи их в планшет-интерфейс%) или по USB проводку.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ivanhoe77 0 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба А почему только QT рассматриваете для linux? Для embedded имхо FLTK больше подходит. Кстати, посмотрел FLTK. ОЧень неплохо. Видно еще не раскручен. Спасибо за наводку. Тем больше плодить не буду. Просто сунулся в разные разделы. Почему бы не взять планшет для визуализации? Нынче на Embarcadero XE6 можно создать проект и скомпилировать его одновременно под iOS, OS X, Android, Win 8 без изменения кода и пользовательского интерфейса. Условия работы прибора - нефтяная скважина в любую погоду. То есть хотя бы IP65 надо. Нынешний прибор можно даже на землю уронить. Ничего не будет. И тачскрин как бы тоже не нужен. Все с кнопок. Просто тачскрин остается по дефолту, ибо есть уже почти в любом экране. Вы сами ваяли на Embarcadero XE6? Я сам сижу на Builder C++ 5.0 (issued 2000 y). Генерит оптимальный код. XE6 - это какая-то могила для программирования. Пустая Win32 VCL-прога 2,5 Мб. Совместимость с Android сомнительная. Через NDK видел я там как пишется. Есть же Intellij IDEA. Она наше все. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба Условия работы прибора - нефтяная скважина в любую погоду. То есть хотя бы IP65 надо. Нынешний прибор можно даже на землю уронить. Ничего не будет. И тачскрин как бы тоже не нужен. Все с кнопок. Просто тачскрин остается по дефолту, ибо есть уже почти в любом экране. Вы сами ваяли на Embarcadero XE6? Я сам сижу на Builder C++ 5.0 (issued 2000 y). Генерит оптимальный код. XE6 - это какая-то могила для программирования. Пустая Win32 VCL-прога 2,5 Мб. Совместимость с Android сомнительная. Через NDK видел я там как пишется. Есть же Intellij IDEA. Она наше все. Как раз сейчас в работе проект на XE6 под POS терминал с тачскрином на дохлом Intel Atom. Да код раздутый. Скажем программа состоящая из одной пустой формы занимает 50 мегабайт! Но она того стоит. Ибо в ней кроются такие компоненты, которые вам сэкономят человеко-годы если все делать с другими тулсами. И какая разница как там пишется? Вся сила в GUI-библиотеке FireMonkey и библиотеке FireDAC на базе которой можно делать межплатформенные комммуникации. А так по теме нефтяных скважин скажу, что к линуксу потянуло вас напрасно. На этом не сделать дивайс с нажежностью пять девяток, не затратив ресурсов с пятью нулями. Однозначно RTOS. Кстати, QT портировали под RTOS MQX ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 4 июня, 2014 Опубликовано 4 июня, 2014 · Жалоба а мы делали прибор для газовиков из 2 частей. измерительная часть - не убиваемая, работала под водой и плавала в болоте,она по блютусу связывалась с приемной частью на планшете. Бригада приезжала, подключала прибор к объекту диагностики, а сама залезала в теплую машину на которой приехала и приятно в комфорте работала. Блютус тянул метров 50, а в степи и побольше. Возможность посидеть в машине, палатке, вместо стояния с прибором по колено в воде и перебором широкого меню на 50 экранов. В планшете даже это можно сделать сильно удобнее... А если очень уж хочется, то сони делает IP65 планшеты, чуть ли не IP67. Планшет андроид, среда написания эклипс бесплатная и приятная... но хозяин -барин... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ivanhoe77 0 5 июня, 2014 Опубликовано 5 июня, 2014 · Жалоба Но она того стоит. Ибо в ней кроются такие компоненты, которые вам сэкономят человеко-годы если все делать с другими тулсами. И какая разница как там пишется? Вся сила в GUI-библиотеке FireMonkey и библиотеке FireDAC на базе которой можно делать межплатформенные комммуникации. Тут согласен. Уже никто теперь не пишет генераторы отчетов (есть fastreport) и отрисовщик графиков (есть TChart). FireDAC весчь! FireMonkey не приживется - вот увидите. Уж больно тормозной. А так по теме нефтяных скважин скажу, что к линуксу потянуло вас напрасно. На этом не сделать дивайс с нажежностью пять девяток, не затратив ресурсов с пятью нулями. Однозначно RTOS. Кстати, QT портировали под RTOS MQX ;) Я вот тоже по Линуксу думаю. Есть большой опыт работы с ucLinux на одноплатниках. Эта зараза порой может и бэдануть. Нужно где-то сверху держать копию и watchdog. А со RTOS под А5 еще не определился. Есть BeRTOS, NuttX, ThreadX. Это уж наверно пусть будущий разработчик и определяется. Кстати, под Cortex-A5 есть вроде версия QT прямо под него без линуховой оболочки. измерительная часть - не убиваемая, работала под водой и плавала в болоте,она по блютусу связывалась с приемной частью на планшете. Бригада приезжала, подключала прибор к объекту диагностики, а сама залезала в теплую машину на которой приехала и приятно в комфорте работала. Блютус тянул метров 50, а в степи и побольше. нам планшет не подходит однозначно. Сами клиенты категорически против. А у вас по блютусу в этом приборе какой протокол ходил? что-нибудь свое или Modbus или аналог? А то интересует опыт людей, заюзавших Modbus RTU на блютус(или Zigbee) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 5 июня, 2014 Опубликовано 5 июня, 2014 · Жалоба у нас был свой протокол, Модбас - это жесткий запрос-ответ, сервер - много клиентов. А блютус - это фулдуплекс, да еще точка - точка. Потому сделали свой, с контролем пропуска и повторения пакетов, обвешали таймаутами на потерю связи и задали дефолтные безопасные состояния в которые прибор переходил если все плохо. А остальное просто, планшет слал регулярно состояние которое надо принять схеме, а схема постоянно слала показания датчиков измерения и реально принятое состояние (там были всякие краны с контролем положения). Причем планшет был мастером и полностью управлял процессом работы. Потому смена алгоритмов работы прибора была легка, просто меняем приложение планшету и готово, а проц прибора был гермитизирован в ящике-корпусе. Хотели еще делать блютус загрузчиик для проца прибора, но в нашей концепции оказалось невостребованным. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SapegoAL 0 5 июня, 2014 Опубликовано 5 июня, 2014 · Жалоба Да код раздутый. Скажем программа состоящая из одной пустой формы занимает 50 мегабайт! Но она того стоит. Ибо в ней кроются такие компоненты, которые вам сэкономят человеко-годы если все делать с другими тулсами. .... Кстати, QT портировали под RTOS MQX ;) Возможности у QT тоже весьма недурственные. Если программер его знает, то результаты впечатляют. Пишется на нём легко. Не хуже чем в том же билдере. Отлаживается очень неплохо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 197 5 июня, 2014 Опубликовано 5 июня, 2014 · Жалоба А у вас по блютусу в этом приборе какой протокол ходил? что-нибудь свое или Modbus или аналог? А то интересует опыт людей, заюзавших Modbus RTU на блютус(или Zigbee) Modbus по BT? Через SPP??? Интересно - как Вы это себе представляете? Вы как бы не задумывались, что разделение кадров на канальном уровне в Modbus делается по паузам меж байтов? И что вы получите после прохождения этих кадров через SPP? SPP вовсе не гарантирует передачу временных характеристик входного потока байт через канал в выходной поток. Да и не может гарантировать, ибо по нижнему уровню любой RF-канал - это пакетная передача. Или нужен другой канальный уровень Modbus, а не канальный уровень последовательных каналов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 5 июня, 2014 Опубликовано 5 июня, 2014 · Жалоба модбас к слову есть на ТСР, и прекрасно себя там чувствует, отрезается вся фигня что нужна для RS485, в том числе и определение конца сообщения по таймауту, и готово... Конечно остается только формат полей и коды команд, но в целом это модбас:).... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 197 5 июня, 2014 Опубликовано 5 июня, 2014 · Жалоба Вот именно существует. Только там свой канальный уровень - ориентированный на Ethernet с её кадровой природой. А SPP-профиль в BT - это байтовый поток, а-ля - COM-порт. Т.е. - совсем не кадровый по своей природе, а поток байт. Только он не имеет временных характеристик обычного COM-порта. А значит - ни канальный уровень Modbus-TCP ни канальный уровень последовательного порта здесь применить нельзя. С Modbus-TCP дела не имел, но думаю что там кадр Modbus полностью входит внутрь TCP-кадра, так и определяются его границы. А как вы границы Modbus-кадра в SPP-профиле определите? Нужен другой алгоритм выделения кадров. Для такого канала как BT, где нельзя привязаться к временным характеристикам и он не имеет пакетной природы, подойдёт например SLIP-протокол канального уровня. Он не имеет привязки к временным характеристикам - может работать на любом последовательном канале, хоть железный UART, хоть любой виртуальный (BT, GSM, CDC-USB и т.п.). Для передачи IP-датаграмм через последовательные каналы как раз и используют SLIP-протокол, когда среда передачи представляет из себя поток байт. Например ранее, когда были телефонные модемы, он как раз и использовался. SLIP-протокол обеспечивает деление на кадры и кодонезависимость. Можно использовать и другой протокол, с меньшей избыточностью. Либо можно использовать какой-то другой BT-профиль, где передача носит кадровый характер (с приемлемыми размерами кадров). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
