Посоветуйте микроконтроллер для Linux Опции

[Sergiy26]

Задача: использовать Mono exe-шник (1мБ) + Apache для запуска одного DLL (для работы с Web Service) + mysql database (5мБ) + пару script'ов + 3G модем. На контроллере желательно более 2-х UART + вся память на одном кристале и конечно хорошая цена.
Пример Raspberry, но минус этого чипа - рабочая температура и один UART.

Приветствуется наличие Dev Kit для легкой разработки. Если есть подходящий чип в корпсе LQFP/QFP для двух слойного дизайна платы, то это супер.

[Sergiy26]

AlexandrY, ответ по поводу MonoDevelop. Язык C#. Приложения работают одинаково под Windows и Linux.
На данный момент Admin в нашей компании работает по тестированию и настройке Linux: mySQL, Apache, remote upgrade ( *.exe files, так же выводимого текста на экран), scripts, FTPS, load on power on. Другой человек работает на своем Linux computer с mysql и SOAP, проверка связи по 3G, в случае отсутствия надо сохранить все пакеты и отправить когда связь вернеться. Мою часть я делаю под windows, с помощью Remoting я могу передавать данные между двумя EXE файлами проекта, которые на разных компьютерах. Мой EXE файл обесечивает связь с контроллером, поддержку ISO15118, управлением 4x20 Character LCD, RFID, считыванием значений со счеткика по RS-485. Весь проект работает не зависимо от платформы. Тестируем, каждый свою часть на своем компе ( мне проще на своем подключить RS-232 и USB). В итоге все файлы запускаются на одной Linux Board. Есть и свои минусы, но время разработки уменьшается.

По поводу mysql. Есть много разрозненых данных, настроек, параметров, white/black list. Можно работать с разными DBF файлами. Можно работать с множеством текстовых файлов с парсерами и т.д. Поиском, заменой, удвлением и т.д. должен заниматься движок mysql. За это надо платить объмом памяти, но все в одной БД и работать с даннвми легче

[AlexandrY]

AlexandrY, ответ по поводу MonoDevelop. Язык C#. Приложения работают одинаково под Windows и Linux.
На данный момент Admin в нашей компании работает по тестированию и настройке Linux: mySQL, Apache, remote upgrade ( *.exe files, так же выводимого текста на экран), scripts, FTPS, load on power on. Другой человек работает на своем Linux computer с mysql и SOAP, проверка связи по 3G, в случае отсутствия надо сохранить все пакеты и отправить когда связь вернеться. Мою часть я делаю под windows, с помощью Remoting я могу передавать данные между двумя EXE файлами проекта, которые на разных компьютерах. Мой EXE файл обесечивает связь с контроллером, поддержку ISO15118, управлением 4x20 Character LCD, RFID, считыванием значений со счеткика по RS-485. Весь проект работает не зависимо от платформы. Тестируем, каждый свою часть на своем компе ( мне проще на своем подключить RS-232 и USB). В итоге все файлы запускаются на одной Linux Board. Есть и свои минусы, но время разработки уменьшается.

По поводу mysql. Есть много разрозненых данных, настроек, параметров, white/black list. Можно работать с разными DBF файлами. Можно работать с множеством текстовых файлов с парсерами и т.д. Поиском, заменой, удвлением и т.д. должен заниматься движок mysql. За это надо платить объмом памяти, но все в одной БД и работать с даннвми легче

Что-то не понял, это вы так представляете себе работу или так у вас уже работает?
Ведь как понимаю у вас embedded платформы-то пока подходящей нет.

И что то не увидел в MonoDevelop кросс платформенной разработки.
Т.е. чтобы компилировать на компе, а запускать и отлаживать на встраиваемой платформе.

А уж лаконичность у MonoDevelop просто эпическая, лаконичней только черный ящик.

И как вы себе представляете интеграцию аппаратных средств микроконтроллера в API Mono?
Это же весь Mono надо будет изучить на уровне исходников.

Опять же глючные драйвера файловых систем на дешевых встраиваемых платформах не дадут сильно разгуляться с MySQL.
Придется титанически напрягаться чтобы уменьшить износ носителей (NAND, SD или что там еще) и устойчивость к последствиям сбоев.
Т.е. и MySQL придется изучить на уровне исходников.

Так о какой экономии времени может идти речь? Здесь надо пару лет минимум.

[mantech]

И что то не увидел в MonoDevelop кросс платформенной разработки.
Т.е. чтобы компилировать на компе, а запускать и отлаживать на встраиваемой платформе.

А уж лаконичность у MonoDevelop просто эпическая, лаконичней только черный ящик.

И как вы себе представляете интеграцию аппаратных средств микроконтроллера в API Mono?
Это же весь Mono надо будет изучить на уровне исходников.

Опять же глючные драйвера файловых систем на дешевых встраиваемых платформах не дадут сильно разгуляться с MySQL.

Незнаю, но по мне - ТС изначально неверно начал с техзадания, пытаясь то, что делают на разных уровнях и устройствах запихнуть в один девайс.
Сам счетчик и какой-либо интерфейс связи с сервером должен быть сделан на небольшом мк типа стмки, а его данные уже передаются на полноценный стационарный сервер, с полным фаршем апачей мускулей на линухе, который ведет базу данных имеет вебсервер и т.п.

[AlexandrY]

Незнаю, но по мне - ТС изначально неверно начал с техзадания, пытаясь то, что делают на разных уровнях и устройствах запихнуть в один девайс.
Сам счетчик и какой-либо интерфейс связи с сервером должен быть сделан на небольшом мк типа стмки, а его данные уже передаются на полноценный стационарный сервер, с полным фаршем апачей мускулей на линухе, который ведет базу данных имеет вебсервер и т.п.

Ну да некоему admin-у это упростило бы работу. Он бы сваял свои кросс платформенные скрипты на стороне embedded сервера и голова не болит.

Зато разработчику realtime части дивайса придется изобретать свой велосипед в виде M2M протокола чтоб WEB серверу
по запросу предоставить любые данные какие он пожелает и чтоб в MySQL все шло не слишком быстро и не слишком медленно и резервирование предусмотреть
когда этот MySQL будет восстанавливаться после очередного краха и т.д. и т.п.

По сути надо будет сделать шлюз SOAP в некий доморощенный межпроцессорный M2M.
И MQX с готовым межпроцессорным прикладным уровнем здесь все равно вне конкуренции.
Надежный, асинхронный, P2P, событийно управляемый M2M протокол это будет посложнее портирования SQL движка на RTOS.