Cosmojam
-
Постов
306 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Cosmojam
-
-
У них теперь основной козырь это технология NABTO
Которая стоит какую-то такую цену что даже трудно запомнить.
ИМХО мёртворождённая технология. Стоит дорого, требует установки дополнения к браузеру. Тоже самое можно реализовать в чистом вэбе и я подобное делал без особых проблем. А за что они просят безумных денег вообще не понятно.
-
E меня ни одной Discovery нет, но в ST-Linkе сигналы JTAG идут через буфер-согласователь нровней с маркировкой NH245 (производитель TI). На фотке Discovery я этого буфера не вижу. Значит придется допаивать и буфер. Стоит ли
девчинка вые***овчинка выделки?Спасибо. Ещё помучаюсь с этим nxp-шным поделием и закажу st-link 2
-
Раз уж про ST-Link, задам глупый вопрос. Платы discovery со встроенным ST-Link v2, пишут что он умеет только SWD, но отдельный ст-линк в корпусе умеет и JTAG. Значит с платы дискавери можно только SWD на внешний таргет взять или JTAG там просто на разъём не выведен и можно подпаяться?
-
Дык это даже не клон j-link, а фирменный NXP-шный отладчик. С клонами тоже не везёт, но это отдельная песня. В этом lpc-link 2 сделали возмжность заливать прошивки и превращать в кастрированный j-link или в cmsis-dap. Но ни то ни другое нормально не заработало. Вот тоже посматриваю на ST-Link v2. С ним как-то однажды сталкивался и он с пол-пинка заработал. А с NXP какая-то беда.
-
На форуме поддержки ничего толкового ответить не могут.
У моего в линуксе "connection refused", костыль предложенный в FAQ не помогает. В винде "connection timeout".
Прошивку от j-link залить получается, виндовая софтина его определяет. Линуксовая - нет. openocd тоже нет.
Может кто-то уже пробовал это чудо? Мне либо не везёт на них, либо реально там глюк на глюке. Первый их отладчик тоже глючил жутко пока не умер, но хоть как-то работал.
-
Ок, это я не правильно понял тот абзац из стандарта. Спасибо!
-
Да, действительно, заголовочный файл - интерфейс модуля. В него нужно включать через #include только те файлы, которые необходимы для этого интерфейса, для обращений к этому модулю. Чтобы в пустом .c - файле сделать #include "my_header.h" и это откомпилилось. Те заголовочные файлы, которые необходимы для реализации вашего модуля - его внутреннее дело, для обращений к модулю они не нужны и вытаскивать их в заголовочный файл не нужно и даже вредно (по причине увеличения времени компиляции и просто замусоривания заголовочного файла). А вы смешали эти две группы заголовочных файлов в одну.
Ок, а если, например, есть модуль A, для реализации которого (именно реализации) требуется модуль B. Но для использования A не обязательно инключить B.h в A.h (нет зависимости от объявленных в B.h типов и дефайнов). В этом случае получается include "B.h" надо писать в A.c. Но тогда взглянув на A.h нельзя точно сказать от каких модулей он зависит. Т.е. получает компромисс между читаемостью и захламлением глобального пространства имён.
А для решения проблем с переопределением одинаковых символов/функций можно к имени всех глобальных функций/символов добавлять префикс с именем модуля. Например, во FreeRTOS так сделано.
С точки зрения крупных проектов это нормально или тоже есть какие-то подводные камни?
-
Речь идёт про Си. Си++ не трогаем, хотя догадываюсь что аргументы там те же.
Существует мнение что писать в .h все необходимые инклюды - это плохо. Единственное подтверждение почему это плохо что мне удалось найти - время компиляции увеличивается. Многократные инклюды одного хидера лечатся очень просто с помощью ifndef/define и как аргумент не рассматриваются т.к. без защиты от множественных инклюдов в любом проекте где один хидер используется более чем в 1 .c файле будут проблемы.
Мой аргумент почему это стоит делать: Хидер - это заголовок модуля, определяющий его публичный интерфейс. Логично расположить в нём всё необходимое для работы модуля, а в .с файле инклюдить только один этот заголовок т.о. отделив реализацию от интерфейса. Улучшается наглядность т.к. сразу в хидере видно зависимости от других модулей.
Погуглив можно найти мнение со ссылкой на NASA C coding standard где написано
(4)The unit header file shall contain #include statements for all other headers required by the unit
header. This lets clients use a unit by including a single header file.
Так как же "правильнее"? NASA не дураки ведь. Так почему существуют противоположные мнения?
-
Кажется понял причину. В каталоге проекта есть неиспользуемые при сборке хидеры, в которых нужные символы переобъявлены. В данном случае это lwipots.h из юниттестов в составе lwip. Видимо реальный lwipopts.h индексируется раньше чем тестовый и некоторые символы оказываются переобъявлены.
-
Смотрите вот здесь.
(Это касаемо заголовка топика, про дефайны в makefile).
О, спасибо, пол-беды решено. А вот с дейфайнами внутри хидеров какие-то глюки индексера видимо. Некоторые нормально видит, некоторые - нет.
-
попробовать сделать переиндексацию
Неа, и настройки индексера менял (включал "index unused headers"). Не прокатывает
-
Есть кусок кода
#if SOME_VAR void func(void); #else
SOME_VAR определена в каком-то хэдэре, который виден эклиспу, но по каким-то причинам он не видит этот дефайн и соответственно весь код под ifdef становится ему не виден. Это страшно неудобно т.к. очень привык Ctrl+click на функции и попадать к её определению. А если она определена под таким блоком ifdef, то эклипс её не видит и приходится мучится с поиском.
Пути к инклюдам эклипс видит (дописал их в path and symbols, по ктрл+клику находит инклюды). Там же в symbols дописал эти дефайны - не помогло.
Подскажите как бороться с этим?
-
непонятно зачем хост ? Во всех АРМ/MIPS-железках есть хосты.
Не во всех смартфонах/планшетах он есть. Точнее полноценного хоста на планшете я не видел ни разу. OTG иногда бывает для подключения всяких клавиатур, но не у всех. Поэтому для поддержки как можно большего числа девайсов (особенно самых дешёвых где нет OTG) нужен хост.
-
А какой в этом смысл ?
Стоимость хоста FT312D + контроллера ATMEGA32U4 ~ 3,4 + 3,4 = 6,8 $
По примерно такой цене уже можно купить младшие чипы серий Freescale i.MX, TI Sitara или AllWinner.
Они уже с USB-хостом на борту и гораздо более производительные, чем ATMEGA32U4.
Т. е. на них можно легко реализовать все задачи,
которые были обозначены в первом сообщении темы, без каких-либо вспомогательных Android девайсов.
Во-первых: теряется совместимость с ардуинами или затрудняется портирование существующих проектов.
Во-вторых: у этих процессоров тоже есть встроенные GPS, 3G, Wi-Fi, Bluetooth, дисплей с тачскрином, камера, микрофон и динамик? Смысл именно в этих вещах при их очень низкой цене в составе китайской мобилки по сравнению с отдельной железкой.
-
так непонятно чем тут поможет Ардуина ? Софт то пишется под хост ?
Под Андроидом есть Scripting API, где на обычном Javascript можно сделать простейшее API-обертку для той же FTDI: на низком уровне: Serial.write(...), Serial.read(), I2C..., SPI..., 1wire..., или на более высоком - коммуникация с конечными устройствами. И ничего не нужно перекомпилировать - блок текста выполняется через eval http://code.google.com/p/jav8/
Софт пишется под ардуину, которая USB-хост в варианте с USB, да. Софт под андроид делается мышкокликательно и на контроллы примитивно вешаются коллбэки в самой ардуине, т.е. код пишется только для ардуину, а на андроиде только интерфейс рисуется (представьте QtCreator с дизайнером где Вы добавляете кнопку на форму, кликаете go to slot и слот генерируется в коде - Вам не нужно знать что этот слот будет вызван через слой абстракций от конкретной платформы). Никаких Serial.write() и JS. Это для самого простого варианта, который и должен уменьшить порог вхождения. Для более сложных вещей, таких как распознавание голоса будем отдельно библиотеки делать чтобы так же не заставлять пользователя кодить под андроид. Желающие - пожалуйста, там тот самый JS через Cordova с нашим плагином. Или нативно.
Но по наблюдениям половина ардуинопроектов не сложнее мигалки светодиодом. Для таких задач нет нужды писать код под андроид и типовые применения можно сделать в виде подключаемых стандртных библиотек. Типа добавить на форму не кнопку, а микрофон, который будет означать голосовой ввод и сделать функцию обучения (какое слово какой коллбэк в ардуине вызовет). Точно так же для навигации и остальных типовых применений.
-
Тема с роутерам давно изучена. например http://robocraft.ru/blog/electronics/1053.html
Туда же китайские MK802 из который юарт достаётся.
Но это всё гиковские вещи, малодоступные, простите, среднему ардуинщику. Суть же предлагаемого проекта в максимально низком пороге вхождения. Хорошо это или плохо - тема для холивара за кружкой чая. Есть масса самоделкиных применений в которых пригодится дешёвый GPS и 3G (... голосовое управление искаропки, распознавание лиц, игровые движки м.б.). Но сделать это на основе биглы, например, дороже чем на основе старого планшета, и сложнее. Тем паче на базе роутера. В то же время у нас есть дешёвые и доступные на каждом углу моблики, многие из которых без дела валяются.
Raspberry и Beagle, на мой взгляд, пошли путём ардуин, только слегка сменили ЦА.
-
Я так вижу ©
Все время вижу одно и то же: вай-фай роутер и к нему по свободному ETH - порту подключена дурдуина и далее - прочая и прочая как в теме.
Не голосовал :)
Да, тоже вариант. Только на роутере нет тачскрина (да и консоль через ssh не всем покажется дружелюбной) с джипиэсом да 3г и батарейного питания "искаропки", а эзернет на ардуйне стоит денег. Одна из вариаций на тему.
-
Ну, смотрите. Поставить на плату чип с USB-хостом - это уже значит, что чип по производительности будет (или может быть таким) минимум в 30-50% от того, что стоит в андроид девайсе. И смысл тогда в нем ? Использовать смартфон как GSM, 3G модем и для каких-то вспомогательных вычислений ?
Надежда на FTDI http://www.ftdichip.com/Android.htm которые "тупые", а дальше Atmega32u4. На атмеге собственно ардуйня, а фт-шка как готовый мост через USB. Хостить андроид на арме получается дороже и сложнее. А если рядом с ним ещё и атмегу - вообще слон с китом. Хотя фт-шки ещё не пробовали. Через месяц должны приехать - сделаем шилдов для обычной ардуйни и потестим. Пока просто мнения людей интересны о задумке.
Если с вафлей то тоже примерно так на готовых модулях (подобных http://www.aliexpress.com/item/serial-uart...351870217.html) , только цена больше будет.
-
И тем не менее вы изобретаете именно вариацию на тему Embedded Pi: устройство сопряжения одноплатной ЭВМ с исполнительными устройствами. Единственно, что для подключения используется не GPIO, а USB. И чем оно лучше варианта «подключить ардуинку к OTG-разъёму планшета/телефона чтобы программа на андроиде рисовала графическую морду и общалась с контроллером через USART» я пока что не вижу.
OTG есть далеко не у всех андроидо-девайсов. Мы хотели хостить андроид на плате т.о. любой девайс должен работать.
Но всё это больше развлечение чем реальная система.Именно! Просто оно видимо смущает людей что находится на форуме профессионалов.
Нельзя ставить знак равентства междк смартфоном и обычным пультом управления.Я тут было понаписал на страницу страшилок, а потом подумал на фига? Ну пострадают фанаты пультов в виде смартфонов. Так это ж хорошо, займутся полезным чем нибудь...
Ну зачем Вас на страшилки тянет? Много кто пострадал от простых ардуин? Все те же ведь возможности по подключению машин-убийц.
1) Вы хотели сказать к USB-хосту устройства с Android подключается некая дочерняя плата с GPIO и другим хозяйством ?Обычно USB-хост делается там, где более мощный процессор.
2) Вам тогда придется Wi-Fi в обязательном порядке ставить на дочернюю плату даже минимальной конфигурации. Wi-Fi в данном случае довольно ненадежное соединение, IMHO.
В большинстве случаев будет и проще и выгоднее взять готовую плату "всё в одном", а их сейчас великое множество.
Вот это уже более интересно.
Но лучше делать это для одноплатного компьютера (готового или своей разработки) на хорошо документированных комплектующих.
Нет, именно на плате хост чтобы работали любые андроидодевайсы, а не только те что с OTG.
тогда непонятно зачем городить новую плату ? Давно же есть IOIO со своим API и подобные.обратите внимание на Android Scripting API http://code.google.com/p/android-scripting/
IOIO на мой взгляд слишком гиковская. Единственная дока - вики на гитхабе и та скудная. А смысл "ещё одной IOIO" во-первых простейший в работе конструктор мобильного приложения (что не тривиальная задача для человека работавшего только с ардуиной) и во-вторых полная совместимость с ардуинами. Т.е. на IOIO можно выпустить UART наружу, например, но что с ним дальше делать? А тут понятно - это ардуина и кодить под неё прямо можно и старые проекты у людей не пропадут. Под IOIO же чтобы закодить на неё свою мигалку светодиодом надо разбираться со всеми тулзами от Микрочипа, а ещё учитывая их малую популярность и современных радиолюбителей и ардуинщиков в особенности - это не приемлемо для большинства.
android-scripting не знал, спасибо. Была мысль QPython использовать, но пока не пробовал.
-
Перевернуто все с ног на голову. Платформа Андроид у смарфтонов и планшетов сырая и дырявая донельзя. А вы хотите навесить на нее испольнительные механизмы жизнеобеспечения. Что неразумно и опасно.
Какая нафиг дисковая пила под управлением Андроид? Вы решили, что у Вас как у ящерицы отрастет новая кисть?
Не придирайтесь к примерам с дисковой пилой - это просто примеры для придания красочности. ЦА - ардуинщики, которым не приходит в голову использовать свои поделки в устройствах жизнеобеспечения. И никто не заставляет их этого делать. Более того, Вы можете прочитать первое сообщение и не найти в нём упоминания что мы собираемся продавать "умные дома". Это всего лишь DIY платформа. К тому же если она выйдет, то большими буквами будет написано на коробке что это не для применение в космических кораблях и системах жизнеобеспечения.
Хм, на этом форуме нет даже раздела посвященного ардуино.Настолько это неактуальная тема для разработчиков, как понимаю.
Да, это не основная ЦА, тем не менее отголоски есть http://electronix.ru/forum/lofiversion/ind...hp/t102947.html
Мнение профи тоже интересно.
На USB/Bt/WiFi-RS232 можно навесить например RS485-Modbus или 1-wire (через DS2480).На FT232R/2232 с драйвером ft2xx можно вообще организовать что угодно - I2C/SPI/GPIO и т.д.
Например, на SPI навесить радиосеть на nRF24L01.
Все это делается без дополнительных аппаратных/программных наворотов.
Интерфейс можно сделать Web - HTML+JS на локальном сервере, соответственно автоматом получится удаленный доступ и управление, и работа софта на PC.
Почти все это проверено на личном опыте.
Да, для профи это не сложно (не считая что на это требуется время). Но для ардуинщика порог вхождения в андроид-разработку высок. Предположительно это одна из причин не особого успеха Arduino ADK и ещё парочки подобных проектов. Мы же планировали упростить именно эту часть с помощью конструктора приложений. Данную гипотезу и хотим проверить.
Простите, но я не совсем понял. Это вы Arduino TRE изобретаете или Embedded Pi? Я уж не говорю про Кубодоску, где «GPIO, PWM, ADC, UART, I2C, SPI» есть чуть-ли не по умолчанию: http://linux-sunxi.org/Cubieboard/ExpansionPortsНи то ни другое ни третье. Добавьте на куби дисплей с тачем, вайфай, блютус и джипиэс да ещё чтобы это в красивом корпусе и нормально работало в андроиде. Получится дорогой и непрактичный монстр, в то время как китайские смартфоны по 500р за киллограм продаются со всем этим на борту, да ещё порой без дела у людей валяются после покупки нового. Их и планируется использовать. И при том что ардуинщику не сподручно разбираться с embedded pi (даже с родной ардуиновской бордой на арме) и прочих более гиковских и уж тем более профессиональных вещах.
-
Как известно вычислительная мощность современного смартфона превосходит мощность всех компьютерных систем времён холодной войны, причём с обеих сторон. Раньше она использовалась для управления орбитальными группировками и для запуска ракет в космос, а сейчас - для запуска птичек в свинок и управления статусами вконтакте. Мы считаем это не справедливым и предлагаем использовать смартфоны и планшеты (в том числе и вышедшие из употребления) в техническом творчестве с помощью специального устройства и софта.
Устройство представляет собой полностью Arduino-совместимую плату размером 20*50 и позволяет Вам подключить любые датчики и исполнительные устройства к Вашему Андроид-устройству, например управлять чайником в 1 клик.
Предполагается один и либо оба варианта (зависит от вас):
- USB HOST, к которому подключается устройство на Android версии 3.1 и предоставляет доступ к низкоуровневым интерфейсам на плате
- Клиент или точка, связываемый с любым мобильным или стационарным устройством по Wi-Fi и так же предоставляющий простой доступ к интерфейсам на плате.
Интерфейсы стандартные: GPIO, PWM, ADC, UART, I2C, SPI. Это позволит Вам измерять температуру, влажность, уровень воды в бочке унитаза, радиационный фон, а так же управлять любыми устройствами такими как чайник, тостер, лампочка, рука-манипулятор от ОБЧР и многое другое. Список датчиков и исполнительных устройств ограничен лишь Вашей задачей и фантазией.
Помимо железа будет ещё и максимально дружелюбный софт, представляющий собой Arduino IDE с добавленным визуальным редактором мобильного приложения.
Вы конструируете приложение из готовых блоков (кнопок, индикаторов, крутилок), указываете какую функцию должен выполнять той или иной блок на плате (добавили кнопку -> правый клик на ней -> добавить функцию -> функция сгенерирована в окне редактора кода Arduino и Вам остаётся лишь дописать что нужно сделать на плате [включить дисковую пилу, опросить счётчик подходов кота к миске и т.д.]).
Пара кликов в окне редактора загружает и мобильное приложение и прошивку на Arduino. Вам не нужно беспокоиться взаимодействии приложения на Android с платой - всё это уже сделано за Вас. Конечно же, все исходники открыты и API документирован так что Вы можете погрузиться в более низкий уровень и получить максимальную гибкость для создания более продвинутых устройств.
Так же вы можете использовать любые существующие проекты для Arduino на нашей плате и легко добавить к ним возможности смартфона или планшета, например:
- Красивый интерактивный интерфейс на экране
- Голосовое управление
- Распознавание лиц и другие возможности компьютерного зрения
- Подключение к интернету и облачным сервисам Ваших бытовых приборов
- Почти бесплатно добавить WiFi, Bluetooth, GPS, GSM вашим ардуинам не покупая дорогие и массивные шилды, а просто взять старый андройдофон
В базовой установке будут примеры приложения:
- Для велокомпьютера с навигацией и замером скорости/пробега/литража выделенного пота посредством датчиков;
- Голосовое оповещение о низком уровне бензина/перегреве/переполненной пепельнице в автомобиле;
- Робот телеприсутствия, например, на базе Makeblock
- Ваш вариант?
Спасибо за участие в опросе!
Подпишитесь на твитер и фейсбук чтобы первыми узнать о появлении устройства в продаже.
-
долго наблюдал этот топик...
в своё время не прокатило останов/удаление потока из вне. если присмотреться к типовым решениям, то обычно это делается из того-же самого потока. т.е. поток получает команд - убейся, идёт и грохает свой хэндл. может тут собака порылась у вас? (насколько я увидел в вашем кусочке кода - Вы грохаете потоки из вне)
Да, в некоторых высокоуровневых ЯП только так и можно прибить тред. Но добавляется слишком много гемора из-за блокирующих операций в треде. А реализовать это уже могут быть большие изменения в коде самого lwip.
Зачем его перезапускать ? Стек работает годами без каких либо глюков, ищите проблему в другом месте, а не грабли прикрывайте листьями. А если по делу, что бы сильно не вникать в кишки lwip, создайте список всех созданных lwip хендлов, потом зарубать задачу lwip, потом в цикле все хендлы, потом заново создать задачу. Но еще раз это не правильно LWIP проверен годами.По-хорошему - да. Но разобраться с этой проблемой в данном проекте не удалось ни мне ни ещё нескольким людям. Поэтому было принято решение прикрывать грабли листьями. Было бы здорово если Вы хорошо разбираетесь в lwip и помогли бы справится с этой проблемой за $.
wave48, с Вашим выделятором кажется нашёл утечку памяти в проекте. Сначала были такие глюки как в первом посте описаны. Потом другие люди вносили изменения в проект, причём совсем в другую его часть. Потом у меня начал вываливаться malloc hook в ртосе. Не вдаваясь в подробности попробовал Ваш выделатор - тоже самое, в какой-то момент malloc_z() возвращает NULL. Видимо где-то тут собака порылась.
-
На самом деле, нормальные фрилансеры - это, фактически, маленькая фирма, состоящая, порой, из одного человека. Она не оформляется официально благодаря замечательной политике государства - ну не может один человек не воруя и не обманывая содержать директора, бухгалтера, ТБ-шника, пожарника, санинспектора и т.д. и т.п.
Зачем столько людей для нано-конторки? ИП не считая налоговых проверок: 6% с дохода + нынче 36тыров в год в ОМС и ПФР (ок.20 если годовой доход меньше 300тыр, но пока насколько мне известно это временная мера и законопроект всё ещё мусолят). Раз в год сдать декларацию в налоговую и оформить платёжки в тот же ОМС и ПФР - бухгалтер за пару тысяч поможет. ООО чуть дороже. За те же пару тысяч в год сервисы типа "моё дело" помогают с бухгалтерией и отчётностью.
-
Можно проверить как будет вести себя мой аллокатор:
http://electronix.ru/forum/index.php?showt...15&start=15
Был сделан из-за такого же рода ошибок.
lwip вроде бы свои собственные (не RTOS) семафоры и очереди использует.
Спасибо! Попробую сегодня
lwip использует семафоры от ртос. Обёртки для работы с ними в sys_arch.{c,h} пишутся. Вроде кроме это больше ничего подобного в нём нет
Первый взгляд на freeRTOS
в FreeRTOS
Опубликовано · Пожаловаться
Не "это" а "подобное" на xmpp для управления железкой на линуксе из вебприложения в гугле аппэнджен. А UDP никто не мешает держать на собственном/выделенном/виртуальном сервере и иметь связь по нему из бэкэнда. Для единичных устройств т.е. без высокой нагрузки на сервер это делается намного проще чем вам кажется.