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

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

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

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

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

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

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

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

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

• Error in EEPROM size for ATmega328, ATmega328P — fixed.
• Alias for ATtiny84A added.

Previous version (3.10 + fixes for known bugs) is saved in scmrtos/tags/3.11.

New version is fixed in scmrtos/tags/4.00 and will be developed further in scmrtos/trunk.

Waht’s new in scmRTOS 4.0 over version 3.11:

• Type aliases byte, word, dword replaced by uint8_t, uint16_t, uint32_t from stdint.h. In some cases “fast” types like uint_fast8_t used for optimal compilation. stdint.h header included in scmRTOS.h
• New naming conventions. The user has to rename appropriate functions and type names in his code for using 3.xx-style sources with new OS (see below).
• architecture/compiler/family hierarchy now used for samples’s repository directories and archive names on scmRTOS download page.
• Process restart functionality added.
• Program debug and profiling features added:
  • determining the amount of process’s free stack space,
  • profiling of process execution time,
  • determining the address of service object that the process is waiting for.
• 4-Debug sample is added for new features demonstration.
• Class TKernelAgent and OS extensions mechanism. Class TProfiler as extension example.
• OS class hierarchy changed. All OS services are descendents of the class TService which is descendant of the class TKernelAgent. OS user is able to create it’s own services.
• STM8/IAR port and STM8/IAR/STM8S samples added.
• CortexM3/GCC/LPC17xx samples 1-EventFlag and 4-Debug added.
• Support for devices with more than 128K flash (ATmega256x) added in AVR/GCC and AVR/IAR ports for megaAVR.
• CortexM3/IAR examples removed from OS because a lack of contributors.
• Fujitsu MB91 port no longer supported.
• ARM7/IAR port is currently not supported.

To simplify the scmRTOS 3.xx to 4.xx migration process the special header file is offered: scmRTOS_310_compat.h. The file contains some aliases for old type names and enables compatibility mode in all OS sources. In compatibility mode two types of inline adapter functions defined:

• For user code: from old-style names to new-style names like from Sleep() to sleep() in new OS code.
• For OS code: from new-style names to old-style names like from system_timer_user_hook() to SystemTimerUserHook() in old user’s code.

Because of the adapter functions the user just should change process’s Exec() function name to еxec() and old code will work.

scmRTOS_310_compat.h must be included in project-level configuration file scmRTOS_CONFIG.h. Also, add there two typedef definitions — for system tick counter tick_count_t and for timeouts and sleep time timeout_t.

See 3-Channel sample in AVR/GCC and AVR/IAR ports as example of using scmRTOS v3.xx oriented code with scmRTOS v4.00 in compatibility mode.

Робот повинен працювати автономно, електроніка робота має керуватися зі звукового виходу мобільного телефону.
Тобто програма має сидіти в телефоні і видавати команди та, можливо, і приймати якісь сигнали зворотнього зв’язку, через звуковий канал. Думаю, можна використати щось стандартне на зразок 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) розміщено в підземному переході від станції метро Палац «Україна» на протилежний від палацу бік вулиці «Велика Васильківська», між «мобілкоторгувальним» та «кавоварним»:

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

Then FTDI MPSSE support was added. I noticed that without administrator rights the program can’t connect to FT2232 chip. But all AVReAl versions on my PC run with root priveleges because it is required for LPT direct acces testing. So, the program works fine with FTDI chips and I had no need to dig deeper.

Finally I decided to investigate the matter. As often happens, to do right you just stop and spend a little time to read and think.

To work with FTDI-based programmers without root priveleges add a file named, for example 55-ftdi.rules to directory /etc/udev/rules.d/. The file must have the following content:

You need not reboot. It is enough to reconnet the programming adapter.

The rules use default vid/pid for FTDI chips. If you use an adapter with different vid/pid, add appropriate line into the file.

OpenOCD contains a file with rules for all adapters supported by this program. If FTDI-based adapter listed in the file is used with AVReAl, you can simply copy the file into /etc/udev/rules.d/ directory. OpenOCD rules use GROUP="plugdev", MODE="0664". As for me it is no difference between this two variants for desktop PC because all users are already included in plugdev group.

Of course, you must have administrator rights to create the file. After that you will be able to work with AVReAl without root privileges.