Звичайно, можна було б використати з’єднувач DIP на шлейф. Та треба було «бігом», поки думка ворушиться, а до Нью-Паріса їхати зараз неблизько. Тому було знайдено шматочки макетки та штирі і мені швиденько запаяли ось такі перехідники:

Все, що потрібно, було перевірено і на деякий час я про це забув. Аж тут раптом виявився потрібним аналогічний перехідник на шість контактів, підключити до макетки один з варіантів програматора. Причому вдома — а паяти самому ліньки
Лінощі — двигун прогресу. Дуже швидко в голові промайнули розміри дворядних кутових штирів і з’ясувалося, що їх можна акуратно розігнути (показано різні стадії процесу):

В результаті вийшли чудові перехідники:

Виріс він на старому, майже непомітному пеньку. Стан — «якраз брати». Кінчики вже не «сопливі», серединка ще не надто волокниста та тверда. Було б це не поруч з проспектом зі жвавим рухом машин, а у лісі — неодмінно зрізав би.

Фото з мобільного телефона, вибачте за (не)якість. Невеликий світлий гриб на темному фоні «перебило» так, що ніяка корекція не допоможе.

Після замірів стало все зрозуміло.

Ті, що давали напругу 2.88…2.92 В та струм 20..24 мА — працюють у велокомпові, не просідають. Для детектора пульсу, схоже, не вистачає напруги.

Ті, що давали напругу 3.1…3.15 В та струм 0.7-1.2 мА — працюють в детекторі пульсу. Навантаження (радіоканал) імпульсне з малим часом активності і гарний конденсатор виручає. Комп з ними перевантажується по кожній спробі пропищати.

З тими, що давали 2.5…2.7 В та струм 0.5-1 мА все зрозуміло — вони вже працюватимуть хіба як елементи енергоцентралі живлення «Зірки смерті» або як щити для вархаммерівських вояків.

• Исправлена ошибка размера EEPROM для микроконтроллеров ATmega328, ATmega328P
• Добавлен синоним для микроконтроллера ATtiny84A

После исправления известных ошибок предыдущая версия сохранена в ветке scmrtos/tags/3.11.

Новая версия зафиксорована в scmrtos/tags/4.00 и продолжает развиваться в scmrtos/trunk.

Что нового в scmRTOS 4.0 в сравнении с версией 3.11:

• Вместо byte, word, dword используются типы uint8_t, uint16_t, uint32_t из stdint.h. В некоторых случаях используется тип uint_fast8_t для оптимальной компиляции на разных архитектурах.
• Изменено соглашение об именовании функций и переменных. Это изменение требует некоторых действий при переходе на новую версию (см. ниже).
• Изменена структура каталогов примеров репозитория и имён архивов на странице загрузки scmRTOS. Теперь используется путь архитектура/компилятор/линейка_микроконтроллеров.
• Добавлена возможность перезапустить процесс.
• Добавлена поддержка профилирования и отладки програм:
  • определение остатка свободного места на стеках процессов,
  • измерение времени работы процессов,
  • возможность узнать адрес объекта синхронизации, ожидаемого процессом.
• Добавлен пример 4-Debug для демонстрации части этих возможностей.
• Добавлен класс TKernelAgent — механизм расширений ОС (собственно, профилирование и сделано как пример такого расширения).
• Изменена иерархия классов ОС. Все сервисы ОС теперь есть потомками класса TService, который есть потомком класса TKernelAgent. Пользователь может создавать свои собственные сервисы.
• Добавлен порт для STM8/IAR и примеры для STM8S.
• В порт CortexM3/GCC добавлены примеры 1-EventFlag и 4-Debug для микроконтроллеров LPC17XX.
• В портах AVR/GCC и AVR/IAR для микроконтроллеров megaAVR добавлена поддержка кристаллов с памятью программ более 128 килобайт (ATmega256x).
• Из порта CortexM3/IAR убрано примеры для LPC17XX (ввиду отсутствия желающих их сопровождать). Участники проекта работают если и с IAR, то с STM32, а если уж с LPC17XX, то с GCC.
• Порт Fujitsu MB91 больше не поддерживается.
• Порт ARM7/IAR на данный момент не поддерживается. Он, как и порт Fujitsu MB91, оставлен в ветке 3.11 но эти порты вошли в 4.0 и в текущую ветку разработки.

Для облегчения перехода с scmRTOS 3.xx на 4.xx создан файл scmRTOS_310_compat.h, который делает синонимы для старых типов данних с использованием типов из stdint.h и включает в исходных текстах ОС режим совместимости. В этом режиме создауются inline функции-адаптеры двух типов:

• Для кода пользователя: адаптеры перехода от старых к новым именам, например, от Sleep() к sleep() в новом коде ОС.
• Для кода ОС: адаптеры перехода от новых к старым именам, например, от system_timer_user_hook() к SystemTimerUserHook() в старом коде пользователя.

Благодаря функциям-адаптерам ядра в старом коде следует лишь заменить имена функций процессов Exec() на еxec() и старый проект будет продолжать работать.

Файл scmRTOS_310_compat.h нужно включить в начале scmRTOS_CONFIG.h проекта. Также необходимо добавить определения для двух типов — счётчика системных тиков ОС tick_count_t и типа времени таймаута timeout_t.

В качестве примера такого перехода можно посмотреть примеры 3-Channel в портах AVR/GCC/MEGA и AVR/IAR/MEGA.

Робот повинен працювати автономно, електроніка робота має керуватися зі звукового виходу мобільного телефону.
Тобто програма має сидіти в телефоні і видавати команди та, можливо, і приймати якісь сигнали зворотнього зв’язку, через звуковий канал. Думаю, можна використати щось стандартне на зразок DTMF.

Конкретні умови (які, можливо, ще не остаточні) та посилання на приклади дивіться у вказаній вище темі на форумі.

З часів інтелівського ApBUILDER-а — програми для генерації коду ініціалізації для MCS-51, MCS-196, … — я всю роботу з периферією завжди робив вручну. Тобто, я і до цього робив вручну, а тим ApBUILDER-ом спробував і відмовився. І знову лише вручну. Читаєш собі документацію на потрібний модуль та й потихеньку пишеш всі ці маски/зсуви. Константи для них у файлах від компілятора чи виробника мікроконтролерів є — і то добре.
А тут — на тобі… Вирішив полінуватися…

Про всяк випадок спочатку глянув, як воно компілюється та скільки займає місця. Додав до проекту весь каталог Drivers/source, закоментував у makefile рядок, який просить лінкера викидати код, що не викликається (точніше, секції, на які нема посилань)

і запустив компіляцію.

Почалося з того, що половина файлів бібліотеки відмовилися компілюватися, бо вони включають файл lpc17xx.h, а в комплекті йде файл LPC17xx.h. Різниця в регістрі літер може десь і неважлива, але не для gcc в Linux. Та це було поремонтувати неважко, я просто додав в каталог проекту файл lpc17xx.h з таким вмістом:

Після цього все зібралося. Розмір коду під сорок кілобайт за «зручності» бачити було незвично, але ж флеша пів мегабайта, хай вже. Може воно там купу корисної роботи робить, я ж ще детально не дивився.

А от кілька десятків попереджень компілятора в дусі

трохи налякали. За такими попередженнями іноді ховаються дуже неприємні помилки.

З останнім, про «comparison is always true» виявилося просто. Бібліотека має купу макросів для перевірки аргументів функцій на припустимий діапазон. Місцями аргументи оголошено як беззнакові цілі, а макрос перевіряє діапазон так:

На перше порівнювання компілятор і видає попередження. Нічого наче страшного, все працюватиме, але купа таких попереджень засмічує лог компілятора.

Місцями стоять зовсім незрозумілі приведення типів стоять. Наприклад, тут аргумент функції має кваліфікатор const, а для локальної змінної він знімається явним приведенням. При тому, що по цьому вказівникові однак дані лише читаються:

Більш за все, початковий код виглядав так:

Вказівник const void *str дає можливість передати у функцію як масив char, так і масив uint8_t без приведення у точці виклику. Але для циклу передачі байтів необхідно мати вказівник на конкретний тип, тому заведено локальну змінну типу uint8_t *. Про const для цього вказівника автор забув. Отримав від компілятора попередження, що при ініціалізації змінної s автоматичним приведенням відкидається кваліфікатор для об’єкта, на який вона вказуватиме:

При компіляції в режимі C++ тут взагалі буде помилка:

На простому рівні діагностики явне «ручне» приведення (uint8_t *) зняло авторові коду попередження. Замів сміття під килимочок і заспокоївся. У мене ж код компілювався з ключем -Wcast-qual:

Тобто і під килимочом сміття теж буде видно.

Проста правка — визначення вказівника потрібного типу — робить код коректним:

В іншому місці ще веселіше:

Тут визначається неконстантний масив вказівників на константні об’єкти типу LPC_GPDMACH_TypeDef. Звісно, масив розміщено в оперативній пам’яті. 32 байти туди, 32 байти сюди — хто їх на 64 кілобайтах помітить?
Але далі у функції по вказівнику, вибраному з таблиці, йде модифікація об’єкта. Щоб компілятор дав це зробити, автор додав приведення вказівника зі зняттям кваліфікатора:

Знову помилку попереднього коду замасковано приведенням типу в наступному.

А треба ж було лишень правильно описати масив:

Тепер ми маємо константний масив (ляже у флеш) вказівників на неконстантні об’єкти. Ніякого приведення типу у функції робити вже не треба.

Ще одне місце, тут вже знімається кваліфікатор volatile:

Для звертання до потрібного регістра зі структури береться вказівник на перший з однотипних регістрів, до нього додається індекс, по отриманому вказівникові проводиться запис.
Але тип LPC_PINCON_TypeDef має біля всіх полів модифікатор __IO (макрос, що замінюється на volatile). Вказівник pPinCon такого кваліфікатора не має. Попередження компілятора знову сховані за явним приведенням замість того, щоб відразу оголосити потрібний тип вказівника. І таких місць в бібліотеці багатенько.

Дану конкретну функцію я переписав так:

Використав той же модифікатор __IO, яким позначено регістри PINSELx. Ну і просто дещо скоротив запис, не змінивши функціонал.
Все одно це мені не подобається, бо тут нема перевірки на припустимі значення всіх трьох аргументів. Якщо задати занадто великі числа, то будуть попсовані як мінімум біти режиму інших виводів процесора. А можна і до зовсім іншої периферії дістати. Якщо вже робити перевірку аргументів, як це зроблено в інших файлах бібліотеки, то і тут треба б.

Я вважаю, що чим жорсткіші перевірки робитиме компілятор і чим менше при цьому попереджень — тим краще. Менше шансів отримати проблеми при редагуванні коду чи зміні версії компілятора. Тому так старанно і передивлявся бібліотеку. І ще дивитимуся.

p.s. Мало не забув. Прикладаю файл з моїм патчем до бібліотеки LPC175x and LPC176x CMSIS-Compliant Standard Peripheral Firmware Driver Library (GNU, Keil, IAR) (Jun 21, 2011), яка на даний момент знаходиться на сторінці підтримки мікроконтролерів NXP.
Купу повідомлень про порівнювання беззнакової змінної на невід’ємність не вичищав, бо для цього треба правити ще й відповідні макроси в h-файлах, глибше та уважніше копати. А я вже вирішив, що цю бібліотеку використовувати не буду, візьму лише h-файли, як джерело описів структур регістрів та констант номерв/масок бітів. Та й ті по дорозі перевіряттиму.
Тож лише вичистив попередження про приведення типів. Та й то — більше з дослідницькою метою.

Термопара лежить на робочому столі (не на моєму, а на вільному, який найдалі від вікна).
Це хвилин через десять після того, як я вчора вранці на роботу прийшов. Спочатку взагалі вісім з копійками градусів показував.
Потім я ввімкнув тепловентилятор і через півтори-дві години температура стабілізувалася на рівні трохи більше сімнадцяти градусів. То нормально, інакше довелося б знімати джемпера. Я й тепловентилятор на кіловаті залишив, досить того.

У мене під рукою були всі матеріали, від тонких мідних листочків до вже готових круглих паличок (зі старого дитячого ліжечка) та інструменти. І мені було легше і цікавіше зробити їх, ніж десь купляти.
Але не всі хочуть і можуть зробити писачок самостійно, що видно хоча б з логів сайту.

Одне з місць в Києві, де можна купити писачок, це кіоск художніх матеріалів в підземному станції метро Палац «Україна». Практично в центрі міста.

Зараз там є ось такі писачки:

Класичну конструкцію покращено, додано металевого кожушка на паличку в місці закріплення конуса. Крім захисту від обгоряння ручки припаяний до конуса кожушок довше триматиме тепло.

Станом на початок лютого ціна на ці писачки була 25 гривень. Минулого року вибір був більший. Сподіваюся, ближче до Великодня з’являться і інші види.
Можливо, десь на Петрівці і можна купити дешевше, але тут може бути простіше. І просто я не знаю інших місць

Кіоск художніх матеріалів (N4) розміщено в підземному переході від станції метро Палац «Україна» на протилежний від палацу бік вулиці «Велика Васильківська», між «мобілкоторгувальним» та «кавоварним»:

Там є ще акрилові фарби, пластика і подібне. Зі слів сина — не дорожче, ніж на Петрівці.

Когда в программу добавилась поддержка работы с FTDI MPSSE, я заметил, что без прав рута не выходит соединиться с микросхемой FT2232. Но у меня на компьютере все версии AVReAl работают от имени администратора, так как время от времени делается проверка работы с прямым доступом к LPT. Поэтому и с FT2232 всё работает и я не копал глубже.

Наконец-то решил разобраться с этим вопросом. Как это часто бывает, достаточно было немного почитать.

Для того, чтобы работать с микросхемами FTDI без привелегий администратора, нужно в каталог /etc/udev/rules.d/ записать файл с именем, например 55-ftdi.rules, такого содержания:

Эти правила рассчитаны на микросхмему FTDI, которой не заменены vid/pid по умолчанию. Если используется адаптер с другими vid/pid, нужно добавить соответствующую строку в файл.

Пакет OpenOCD содержит файл правил для всех адаптеров, который он поддерживает. При использовании AVReAl с адаптером на микросхеме FTDI из этого списка можно просто перенести файл правил OpenOCD в каталог /etc/udev/rules.d/. В правилах OpenOCD использовано GROUP="plugdev", MODE="0664". Но я не вижу разницы между этими двумя вариантами на «десктопе», где все пользователи по умолчанию включены в группу plugdev, чтобы они могли подключать USB-флешки и переносные диски.