Также, не стоит закладывать нашу плату в серийный проект, ну тут всё понятно, для массового изделия выгоднее сделать свою конструкцию.
?
Вот нам в упомянутом в статье серийном проекте (Wiren Board) подобный модуль был бы очень кстати. Своя конструкция может выйти дешевле, но совсем не хочется тратить на это драгоценное время. К тому же двухслойные платы мы например прекрасно и в России делаем. А вот если здесь делать самим четырёхслойную и с BGA, как у вас, то это выйдет в два раза дороже, чем купить готовую.
Правда у вас плата, на мой взгляд, получилась уж очень широкой для встраивания в что-то своё. Если бы вы сделали версию уже и с более маленькими коннекторами, например с PLD меньшего шага или даже с FPC — то было бы просто прекрасно. Или даже плату с card edge разъёмом, как у «серьёзных» SoM. Мне кажется, что такое решение будет очень востребовано при низкой цене. К тому же чип A13 имеет индустриальный диапазон рабочих температур, что позволяет всё остальное тоже ставить в индустриальном исполнении.
Кстати, Olimex на днях анонсировали SoM на A20 за 25 евро. Если всё сделают хорошо, то это будет достойный конкурент вашей плате.
Метро стало пытаться внедрить многоразовые карты через много лет после появления одноразовых. До сих пор пополнить многоразовую карту — то ещё приключение, потому что автоматов мало, они тормозные и очень часто не работают. Как правило, купить одноразовый билетик в кассе по продаже одноразовых билетиков сильно быстрее. Разница в цене, опять же, появилась только сейчас и составляет всего 3р, что меньше, чем стоимость билетика UL (насколько я знаю, что-то около 7-8р).
Стоимость Mifare Classic и пластика почему-то заложена в цену многоразовой карты с двухкратным запасом, а себестоимость бумажных Mifare UL в цену одноразового билетика не включена.
Кроме этого, совершенно не понятно, что мешало сделать пополняемыми бумажные билетики UL. Не понятно, что мешало отбирать билетики в турникетах на выходе, как в Пекине например.
В общем непонятно, было это глупостью это или преступным умыслом, но вопиющая неэффективность по-моему очевидна. Положительная динамика впрочем есть.
Вот если убрать из вашей задачи i2c/spi/gpio, то это вполне себе задача, которая могла бы возникнуть и для настольного PC. И такие задачи вполне себе решаются, и никаких проблем с «нормальной средой разработки» у людей не возникает. А для i2c/spi/gpio есть стандартный ядерный интерфейс, есть какие удобно обёртки под что угодно. О WiFi/3G/UART вам в случае linux вообще задумываться обычно не надо. Хотите на python пишите (и это будет очень быстро), хотите на C, будет вам native код.
Вообще всё что я пытаюсь сказать, это то, что написать приложение под linux для нашей платки (причём работающее с периферией) не сложнее, чем написать приложение под linux для любимого ноутбука. Возможно вам это непривычно и поэтому сложнее. Но, как мне кажется, специалистов, для которых верно обратное, найти проще и стоят они, как правило, дешевле. А это, согласитесь, важно.
А для вашей конкретной задачи, вы бы могли например работать с gpsd, писать лог в базу sqlite на флешке, на которой журналируемая фс ext4, отправлять данные через wifi (wpa2 с сертификатом) на ПК через HTTPS. Ну и да, делать всё что угодно через BT (как через последовательный порт) и общаться через i2c/spi с МК тремя строчками. Всю это логику вы, например, реализуете в одном скрипте python, который запускается через inittab. Отлаживаете скрипт удалённо, подключив плату по ethernet к компьютеру через любимый отладчик для python. Wifi и 3G вы настраиваете практически как на настольном компьютере путём изменения конфигурационных файлов. Как это сделать, вы за 5 минут найдёте в гугле, даже если ни разу этого не делали.
И ещё, в нагрузку, вы можете поставить на железку веб-сервер и сделать простой веб-интерфейс для управления.
По-моему не очень сложно и можно ни одного shell скрипта не писать.
Позволю себе с вами не согласиться. Разрабатывать и отлаживать на плате вполне можно, а ещё можно делать это на большом компьютере, подключая образ через qemu+chroot. Кросс-компиляция, опять же, настраивается один раз 10 минут и дальше просто работает. На плате и так стоит по-умолчанию «большой линукс» и инструментарий там вообще точно такой же.
Использовать плату в приложениях с реальным временем конечно не лучшее решение. Хотя даже задачи, для которых обычно используют ОС РВ, во многих случаях можно реализовать на линуксе с real-time патчами ядра или таймерами высокого разрешения. А ещё можно поставить рядом PIC/AVR за 1$ и почти без обвязки, или даже воткнуть готовый модуль в UEXT и перенести на него realtime задачи, оставив всю логику и связь со внешним миром внутри платы. Понятно, что есть случаи, когда это всё сложнее, чем использовать например упомянутый STM32, но часто использовать linux удобнее.
Для многих задач, где нужна работа с камерой, наша плата действительно не подходит. Скорее не из-за общего быстродействия, а из-за отсутствия хардварного энкодера видео (что позволяет нам сделать плату на $20+ дешевле). Впрочем, если вам не нужно сжимать видеопоток от мегапиксельной камеры в h264, то даже мощностей нашей платы должно хватить. Если нужно — то лучше подойдёт предложение от наших упомянутых в посте конкурентов.
Возможно это конечно дело вкуса, но я считаю, что разработка более или менее сложной системы под нормальный линукс выйдет сильно быстрее и дешевле, чем под мк, даже с какой-нибудь FreeRTOS. Именно из-за готовых драйверов для всего, готового инструментария, готовых библиотек, нормальной многозадачности и вообще всей инфраструктуры.
Да, вы правы, всё так и есть. Человек, который у нас занимается платами и трассировкой в частности, опыта трассировки ВЧ-плат не имел, только силовой электроники, так что приходилось учиться в процессе.
Но мы об этом конечно знаем и перед производством серийной партии собираемся отдать схему профессионалам, чтобы исправить ошибки трассировки.
Почему мы не сделали этого сразу? Ну, ресурсы у нас не бесконечные, а кривая трассировка, ручная сборка и остатки флюса на плате на работоспособность прототипа влияют слабо.
Так как по результатам предзаказа мы ещё будем вносить изменения в конструкцию и что-то добавлять, то делать это сейчас не имело бы большого смысла.
Кстати, если бы вы посоветовали нам хороших людей, которые бы могли исправить наши ошибки с трассировкой, или которые могут провести согласование антенн ВЧ-частей, я был бы очень благодарен.
Ну, у нас вообще нет аппаратного энкодера, так что видео в любом случае обрабатывать процессором придётся. USB-модули кажется тоже довольно компактны: такой или такой например.
А почему, если не секрет, вы выбрали эту микросборку HDG104 для wifi? Кажется стоит она дорого, интерфейс только SPI, 802.11n нет, драйвера только для старого ядра — сплошные минусы.
Спасибо!
Я думаю, что дело как раз в цене: сам чип RTC стоит $0.5 от 1000 штук, а ещё нужен разъём для батарейки, сама батарейка. Это всё денег стоит, место на плате занимает и т.д. Так как нужно это далеко не всем, на этом значительно экономят.
С продукцией olimex всё ещё проще: у них есть очень компактный внешний модуль MOD-RTC за 4 евро (совместимый естественно с Wiren Board), который можно подключать ко всем их платам, так что делать часы на плате Olinuxino не было смысла совсем.
Вообще в процессора i.mx233, который стоит в используемом нами Olinuxino Micro, есть встроенный RTC, который держит время, пока подключена основная li-ion батарейка. Поддержка в ядре тоже есть с недавнего времени. Мы правда этот встроенный RTC не тестировали, и я не знаю какое энергопотребление чипа в таком режиме без выделенного кварца.
Debian, ядро 3.7.1 с нашими и не нашими патчами, отдельный репозиторий с специфичными пакетами и портами (собственно ядро, особый hostapd, libnfc с поддержкой, биндинги, настройки для всего этого под плату). Пока так. Свой abstraction layer делать пока не планируем, разве что очень примитивный. Интерфейсы стандартные, пользовательский код можно писать на Python или других скриптовых языках, биндинги есть. Т.к. там debian + несколько кастомных пакетов, системы сборки никакой не используем, потому что не надо. Готовые образы, инструкции по сборке и патчи выложим к релизу.
Очень не хочется собирать самому из блока питания, микроконтроллера, радио-модуля и реле.
А почему вы думаете, что
?
Вот нам в упомянутом в статье серийном проекте (Wiren Board) подобный модуль был бы очень кстати. Своя конструкция может выйти дешевле, но совсем не хочется тратить на это драгоценное время. К тому же двухслойные платы мы например прекрасно и в России делаем. А вот если здесь делать самим четырёхслойную и с BGA, как у вас, то это выйдет в два раза дороже, чем купить готовую.
Правда у вас плата, на мой взгляд, получилась уж очень широкой для встраивания в что-то своё. Если бы вы сделали версию уже и с более маленькими коннекторами, например с PLD меньшего шага или даже с FPC — то было бы просто прекрасно. Или даже плату с card edge разъёмом, как у «серьёзных» SoM. Мне кажется, что такое решение будет очень востребовано при низкой цене. К тому же чип A13 имеет индустриальный диапазон рабочих температур, что позволяет всё остальное тоже ставить в индустриальном исполнении.
Кстати, Olimex на днях анонсировали SoM на A20 за 25 евро. Если всё сделают хорошо, то это будет достойный конкурент вашей плате.
Стоимость Mifare Classic и пластика почему-то заложена в цену многоразовой карты с двухкратным запасом, а себестоимость бумажных Mifare UL в цену одноразового билетика не включена.
Кроме этого, совершенно не понятно, что мешало сделать пополняемыми бумажные билетики UL. Не понятно, что мешало отбирать билетики в турникетах на выходе, как в Пекине например.
В общем непонятно, было это глупостью это или преступным умыслом, но вопиющая неэффективность по-моему очевидна. Положительная динамика впрочем есть.
Вот если убрать из вашей задачи i2c/spi/gpio, то это вполне себе задача, которая могла бы возникнуть и для настольного PC. И такие задачи вполне себе решаются, и никаких проблем с «нормальной средой разработки» у людей не возникает. А для i2c/spi/gpio есть стандартный ядерный интерфейс, есть какие удобно обёртки под что угодно. О WiFi/3G/UART вам в случае linux вообще задумываться обычно не надо. Хотите на python пишите (и это будет очень быстро), хотите на C, будет вам native код.
Вообще всё что я пытаюсь сказать, это то, что написать приложение под linux для нашей платки (причём работающее с периферией) не сложнее, чем написать приложение под linux для любимого ноутбука. Возможно вам это непривычно и поэтому сложнее. Но, как мне кажется, специалистов, для которых верно обратное, найти проще и стоят они, как правило, дешевле. А это, согласитесь, важно.
А для вашей конкретной задачи, вы бы могли например работать с gpsd, писать лог в базу sqlite на флешке, на которой журналируемая фс ext4, отправлять данные через wifi (wpa2 с сертификатом) на ПК через HTTPS. Ну и да, делать всё что угодно через BT (как через последовательный порт) и общаться через i2c/spi с МК тремя строчками. Всю это логику вы, например, реализуете в одном скрипте python, который запускается через inittab. Отлаживаете скрипт удалённо, подключив плату по ethernet к компьютеру через любимый отладчик для python. Wifi и 3G вы настраиваете практически как на настольном компьютере путём изменения конфигурационных файлов. Как это сделать, вы за 5 минут найдёте в гугле, даже если ни разу этого не делали.
И ещё, в нагрузку, вы можете поставить на железку веб-сервер и сделать простой веб-интерфейс для управления.
По-моему не очень сложно и можно ни одного shell скрипта не писать.
Использовать плату в приложениях с реальным временем конечно не лучшее решение. Хотя даже задачи, для которых обычно используют ОС РВ, во многих случаях можно реализовать на линуксе с real-time патчами ядра или таймерами высокого разрешения. А ещё можно поставить рядом PIC/AVR за 1$ и почти без обвязки, или даже воткнуть готовый модуль в UEXT и перенести на него realtime задачи, оставив всю логику и связь со внешним миром внутри платы. Понятно, что есть случаи, когда это всё сложнее, чем использовать например упомянутый STM32, но часто использовать linux удобнее.
Для многих задач, где нужна работа с камерой, наша плата действительно не подходит. Скорее не из-за общего быстродействия, а из-за отсутствия хардварного энкодера видео (что позволяет нам сделать плату на $20+ дешевле). Впрочем, если вам не нужно сжимать видеопоток от мегапиксельной камеры в h264, то даже мощностей нашей платы должно хватить. Если нужно — то лучше подойдёт предложение от наших упомянутых в посте конкурентов.
Возможно это конечно дело вкуса, но я считаю, что разработка более или менее сложной системы под нормальный линукс выйдет сильно быстрее и дешевле, чем под мк, даже с какой-нибудь FreeRTOS. Именно из-за готовых драйверов для всего, готового инструментария, готовых библиотек, нормальной многозадачности и вообще всей инфраструктуры.
Но мы об этом конечно знаем и перед производством серийной партии собираемся отдать схему профессионалам, чтобы исправить ошибки трассировки.
Почему мы не сделали этого сразу? Ну, ресурсы у нас не бесконечные, а кривая трассировка, ручная сборка и остатки флюса на плате на работоспособность прототипа влияют слабо.
Так как по результатам предзаказа мы ещё будем вносить изменения в конструкцию и что-то добавлять, то делать это сейчас не имело бы большого смысла.
Кстати, если бы вы посоветовали нам хороших людей, которые бы могли исправить наши ошибки с трассировкой, или которые могут провести согласование антенн ВЧ-частей, я был бы очень благодарен.
Я думаю, что дело как раз в цене: сам чип RTC стоит $0.5 от 1000 штук, а ещё нужен разъём для батарейки, сама батарейка. Это всё денег стоит, место на плате занимает и т.д. Так как нужно это далеко не всем, на этом значительно экономят.
С продукцией olimex всё ещё проще: у них есть очень компактный внешний модуль MOD-RTC за 4 евро (совместимый естественно с Wiren Board), который можно подключать ко всем их платам, так что делать часы на плате Olinuxino не было смысла совсем.
Вообще в процессора i.mx233, который стоит в используемом нами Olinuxino Micro, есть встроенный RTC, который держит время, пока подключена основная li-ion батарейка. Поддержка в ядре тоже есть с недавнего времени. Мы правда этот встроенный RTC не тестировали, и я не знаю какое энергопотребление чипа в таком режиме без выделенного кварца.