Если при таком переносе проявляются какие-то баги, то это уже хорошо, что они проявились - их надо искать и устранять. Только из-за одного этого стоит переносить туда-сюда.
Нормально написанное ПО как правило не перестаёт работать при переносе в разные области памяти. А сам перенос настолько прост, что сам по себе не должен создавать дополнительных ошибок.
Я сам активно использую отладку в RAM или SDRAM почти во всех проектах. И везде у меня ПО работает одинаково и в FLASH и в RAM и в SDRAM. Изменяется только загрузка CPU и скорость загрузки отладчиком.
Вроде как имена окаймлённые двойным подчёркиванием обычно зарезервированы для нужд компилятора или идущих с ним стандартных хидеров. Поэтому такие имена лучше не использовать, во избежание конфликтов и недоразумений.
Я такие поля обычно обзываю unuseXX. Визуально оно чётко отличается от действительных полей, так как те написаны большими буквами.
Я ничего не доказываю, вы что-то путаете - я вообще ничего не говорил про нужность или ненужность его. Наоборот - только в свой адрес и слышу "Раз ты его не используешь, то ты лох".
Тут привели его в качестве аргумента, я всего лишь спросил: "где его описание или что из себя представляет?" В ответ получил отсылки туда, где этого описания нет.
В том, что данная версия IAR неправильно компилит код с uint16_t, а значит её листинг нельзя приводить в качестве объяснения работы с такими типами - он неверный:
https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=147939
PS: Да, вот теперь вижу разницу между типами (IAR_7.80.4):
Открыл этот самый stdint.h: И о чём же таком сокровенном говорит это:
typedef __INT_FAST8_T_TYPE__ int_fast8_t; ???
Просветите неуча. Научите как из этого определения почерпнуть тонкости его реализации? И __INT_FAST8_T_TYPE__ нигде нету....
Ваш 8.2x здесь никак не авторитет - читайте ветку про IAR про баги. Незачем тут кривые листинги в подтверждение чего-то выкладывать.
Версия IAR-а, которым сиё скомпилено - какая? Вообще, это хороший тон - указывать номер версии компилятора, если приводите что-то касающееся его работы (листинги).
У IAR-а между прочим в некоторых версиях от 8.xx до 8.32 есть баг касающийся как раз компиляции такого кода, где есть операции сравнения неосновных типов (например u16). Уже разбирали его на этом форуме. Потом они его поправили (в 8.30 или 8.32). Так что если Вы привели от такой кривой версии - то грош цена этим листингам.
За какие слова? Я разве в чём-то соврал? Вставил в исходник, IAR сказал: "undefined". Прошёл поиском по всем версиям uCOS-II какие у меня есть (поскольку некоторые утверждали что оно там есть) вплоть до v2.92.13 - нету.
Стыдно должно быть тем, кто утверждал, что оно используется в uCOS-II. Вот это откровенная неправда.
А то что я его не использую... Так что с того? Не нужно значит. Я думаю, что Вы тоже многое не используете, что я знаю.
Так два интерфейса или всё-таки два IP? Если 2-е, то оно делается элементарно. Правда не на этом стеке.
PS: Кросспостинг в разные ветки делать нехорошо.
Берёте два 4-разрядных двоично-десятичных счётчика с возможностью параллельной записи. По их выходу ставите элемент И, объединяющий 0-й & 2-й разряды 1-го счётчика и 1-й разряд 2-го счётчика. И с выхода И заводите сигнал на вход параллельной записи в счётчик начального значения "1".
В стародавние времена была такая микросхема: К155ИЕ6. Две штуки К155ИЕ6 + 3-входовой элемент И-НЕ - и Ваша схема готова
А зачем их конструировать? Если нужен FM-приёмник: покупаете на али модуль на RDA5807M, скачиваете даташит на него, подключаете его к I2C своей платы, и остаётся изучить только I2C.
Если интересна приём-передача по радио - можно другие модули. Например те же nRF24L01+ на том же али. Опять - даташит + изучение SPI.
Ну а если Вы хотите свой радиомодем, с модуляцией и демодуляцией, то STM32 пожалуй будет слабовата. Тут нужен DSP или ПЛИС.
Как может залипнуть SDA? Если клоки SCL подаются то в конце концов доберёмся до конца принимаемого байта (раз SDA был == 0, значит слэйв передавал), до бита ACK, и он по любому отлипнет.
Я просто даю много раз подряд СТОП-условие. Потому что если слэйв в состоянии передачи, и даже почему-то сразу не отработает СТОП посреди байта, то по-крайней мере он его будет воспринимать как клок, дойдёт до конца байта, и на ACK-е примет СТОП. Просто у меня количество СТОП-ов == длина байта + макс.длина адреса (10 битного).
Clock-stretching отрабатываю всегда. На его залипание не рассчитываю.
Разве зависит? I2C же допускает объединение на одной шине устройств с 7-и и 10-битным адресом? Если так, то 7-битные должны как-то определять что сейчас передаётся 10-битный адрес. И соответственно пропускать его весь.
Вот что сказано в википедии:
Комбинация бит 11110ХХ адреса зарезервирована для 10-битной адресации.
Получается похоже что можно совмещать на одной шине устройства с разной длиной адреса.
