Звичайно, можна було б використати з’єднувач 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 для оптимальної компіляції на різних архітектурах. Файл stdint.h включено в scmRTOS.h.
• Змінено угоду про іменування функцій та змінних. Ця зміна вимагає деяких дій при переході на нову версію (див. нижче).
• Змінено структуру каталогів прикладів репозиторію та імен архівів на сторінці завантаження 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.

З наявних недоліків — на wiki проекту відсутні сторінки для STM8. Це моя провина і я її (поступово) виправлятиму.

Робот повинен працювати автономно, електроніка робота має керуватися зі звукового виходу мобільного телефону.
Тобто програма має сидіти в телефоні і видавати команди та, можливо, і приймати якісь сигнали зворотнього зв’язку, через звуковий канал. Думаю, можна використати щось стандартне на зразок 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, якій записом в конфігураційній EEPROM не замінено vid/pid за умовчанням. Якщо використовується адаптер з іншими vid/pid, треба додати відповідний рядок в цей файл.

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

Звісно, щоб записати цей файл, права адміністратора знадобляться. Але після цього AVReAl працюватиме від імені будь-якого користувача.