neiver

Начинать надо с того, что COM порт вообще и его реализация в Windows в частности, не гарантирует безошибочной передачи данных. То есть рассчитывать на это нельзя, и контроль и/или обеспечение целостности данных надо реализовывать в протоколе обмена. Поврежненный пакед должен отбрасываться и если нужно передаваться повторно. По возможным причинам. У стандартного аппаратного СОМ порта есть внутренний буфер, как правило размером 15 байт. Это не тот буфер, который задается в SetupComm. Если драйвер порта по каким-то причинам не успеет прочитать этот буфер, то принятые байты теряются, о чем извещают соответствующие флаги возвращаемые ClearCommError. Приоритет пользовательского процесса не влиет на приоритет драйвера СОМ порта при обработке прерываний.

Гуглить "инверсия приоритетов freertos".

Я как-то вот такое делал: http://we.easyelectronics.ru/Soft/prostoy-...oder-ik-du.html

Это особенности реализации конкретных аллокаторов. В keil аллокатор оптимизирован под небольшие объемы памяти.

Параметры шаблона должны быть константами времени компиляции, иногда можно константы времени компановки(но не все компиляторы это едят, хотя ГЦЦ должен). То есть Объект Settings должен быть размещен по известному в точке инстанцирования адресу, хотя-бы во время линковки.

Первые ссылки из гугла: https://artofcode.wordpress.com/2010/12/12/...m-stdstreambuf/ https://msdn.microsoft.com/en-us/library/aa...3(v=vs.60).aspx Надо написать свой класс унаследованный от streambuf, в нем реализовать соответствующие функции вывода. Потом связать объект своего streambuf с потоком: std::cout.rdbuf(&my_streambuf);

Можно так-же как и printf перенаправить, переопределить функцию низкоуровневого вывода: size_t __write(int handle, const unsigned char * buffer, size_t size) А можно средствами C++ - реализовать свой std::streambuf и передать его в cout.

IEEE 802.15.4?

На счет ЖК матрицы не скажу точно, заказчики используют какую-то Samsung-овскую IPS матрицу, модель не знаю. На счет по-штучно тоже не знаю, попробуйте написать запрос на [email protected], что нужны образцы на попробовать, может и продадут. Я если что смогу проконсультировать на счет протокола обмена и т.д.

В качестве тачскрина могу порекомендовать свою разработку: http://zaprib.ru/catalog_products/avionika/modul_sensornyj/ Инфракрасный, мультитач 2 точки, фактическое разрешение более 1024х1024. Разрабатывался для авиации со всеми вытекающеми. На данный момент доступна модель 10.4''. И да, физическим лицам в розницу не продают :)

А у меня статейка по этому поводу есть: http://we.easyelectronics.ru/Soft/preobraz...ey-tochkoy.html

Ну например, для всяких алгебраических типов данных перегрузка операторов однозначно полезна. Вместо какого-нибудь: c = sqrt(complex_add(complex_mul(a, a), complex_mul(b, b))); можно записать: c = sqrt(a * a + b * b); Существенно улучшает читаемость кода и уменьшает вероятность ошибок. Перегружать операторы конечно надо так, чтоб их семантика была очевидна. Плохой пример: MyArray<int> array; ... array = 10; Если оператор присваивания перегружен. Что он может делать с массивом? Делает размер массива равным 10? Или присваивает всем элементам массива значение 10? Или только первому элементу?

Кстати на счет симтем контроля версий и разработки схем и печатных плат. Altium поддерживает интеграцию с SVN. И даже дифы схем и плат умеет показывать. По "altium svn" гуглится много интересного. Git напрямую не поддерживается, но можно прикрутить через git-svn. Однако, я демонстрировал работу Альтиума с СВН-ом ребятам схематехникам, конструкторам ПП. Показывал им ветки, дифы, хранение истории и разных ревизий, как можно сделать централизированную библиотеку шаренных компонентов. Сказали, что очень круто, но работают всё равно по старинке, каждый пилит свою плату на своеё машине, изредка копируя ревизии в шаренную папку на сервере. Они считают им так удобнее.

Вы чего-то странного хотите. Регистры R0...R3 сохраняются и восстанавливаются в прерываниях аппаратно. Если обработчику прерываний их не хватает, то будут использованы и остальные регистры. Оставьте регистры компилятору, он неплохо разбирается как и когда их использовать.

BitCloud вроде бы. Больше ничего не припомню.

Дальность связи от многих факторов зависит: от взаимной ориентации антенн модулей, о расположения модулей в корпусе, от помеховой обстановки. Например, в железобетонном здании (в пределах одного этажа) с гипсокартоновыми перегародками дальность была около 70м (иногда до 100м) при отсутствии помех. А когда рядом начинали работать несколько точек доступа WiFi падала до 30-50 м, были частые повторы передач. Через толстые ЖБ перекрытия сигнал плохо проходит - одно-два перекрытия и всё. На открытом воздухе дальность больше 100 м.

Коллизии обрабатываются. Для этого нужно только включить автоподтверждение приема и автоповтор передачи. Насчет ZigBee. ST32W108 линейка брат близнец Ember em357 (ныне silabs), они идентичны почти полностью, за исключением серийных номеров и ID. Для них есть стек EmberZNet. Он, например, в модулях telegesis используется. Раньше EmberZNet был доступен и для ST32W108 - теперь пути STM и Ember(Silabs) разошлись и фиг знает где и как его достать/купить. Короче, если нужен именно ZigBee, то лучше выбрать другую линейку моделей. А если нужен просто МК со встроенным радиомодулем, то ST32W108 - неплохие камушки.

1. Чтоб при запросе разбудить спящее ядро, приемник должен быть включен, а он потребляет не мало. Лучше пусть датчики периодически просыпаются и передают, что нужно мастеру - мастер всегда включен и слушает. 2. ZigBee либа была, да сплыла. Рассчитывать можно только на SimpleMAC библиотеку.

Да в коммерческих продуктах не лучше. В случае чего адекватную тех поддержку получить бывает сложно. Поначалу упорно отвечают - это не бага, это фича. А если таки упрешься у докажешь, что бага, скажут ОК, в следующей версии починим - ждите, покупайте следующую версию.

soft/hard отличаются только способом передачи float аргументов и возвратом значений в/из функции. В случае soft FP аргументы передаются также как и целочисленные - через регистры и стек если регистров не хватило, результат возвращается в r0. При этом вычисления всё равно идут в регистрах мат сопроцессора. Соответственно параметры функции надо скопировать из РОН в регистры сопроцессора, потом обратно. Hard FP - все float переменные передаются непосредственно в регистрах сопроцессора. Hard FP чуток побыстрее. У меня в текущем проекте используется много метематики с плавающей точкой, общая разница между soft/hard была около 10%. Для меня это было критично и определило выбор Hard FP. Soft FP зато совместим с либами скомпилированными без использования мат. сопроцессора.

Попробовал на Stm32f407 с использованием аппаратной плавающей точки, получилось 28000000 тактов процессора на 1000000 (миллион) итераций цикла - 28 тактов на итерацию. Для double нет аппаратной поддержки и результат куда печальнее 1117999516 тактов, ~1118 тактов на итерацию. Компилятор arm-none-eabi-gcc 4.7.3.

Cortex M3 reference manual

http://stackoverflow.com/questions/2287122...er-type-warning

А на сколько интенсивно нужно double использовать? Насколько я помню, софтварные операции с double занимают порядка пары сотен тактов процессора. А аппаратные целочисленные деления и умножения при операциях с плавучкой не очень-то полезны. А если нужно быстро, то может и у float-а точности хватит?

Посмотрите здесь, может что интересное найдёте: http://we.easyelectronics.ru/Soft/preobraz...lye-chisla.html