Перейти к содержанию

    

Arlleex

Участник
  • Публикаций

    669
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Arlleex

  • Звание
    Господин Никто

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

2 442 просмотра профиля
  1. У меня тут проект под STM8S003 (для хобби-девайса), в этом МК ресурс Flash всего 100 циклов. 100 циклов, а не 100 000 И я, в общем-то, не сильно переживаю на этот счет - запустить и отладить почти всю периферию, что есть в этом МК, мне видится возможным за эти 100 циклов. Как убить память в десятки тысяч (а то и сотни!) - надо каждую минуту перепрошивать, сидя беспросветно 7 дней за ПК. Так что, думаю, опасения напрасны. Другое дело, если хочется побыстрее загружать прошивку в МК для отладки... Но если так хочется, вот ссылочка, можете почерпнуть оттуда много интересного: https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=75331
  2. Спасибо! Думалось мне, будет что-то нечто хуже, оказалось все очень неплохо
  3. А можно поинтересоваться, во что превратится ledGreen.on() в итоговом ассемблерном варианте?
  4. И как сие работает? BUTTON1_PIN превратится в 0x000D. И что мне с этим делать? Создавать еще функцию, которая будет расшифровывать битовые поля, и исходя из этого устанавливать нужный бит в нужном GPIO - не очень практично, ИМХО. На мой взгляд, на установку бита в GPIO должно уходить всего пару тактов, чтобы более-менее точно выводить отладочные сигналы на осциллограф или логический анализатор, при необходимости. Либо экзотический интерфейс ногодрыжно запилить, например. Конечно, для измерения точных временных меток такой метод не годится, но во многих случаях он может пригодиться. И поэтому, для меня определяющим фактором является "быстрее - не медленнее". Вместо раздувания вызовов функций и, соответственно, траты процессорного времени, лучше писать сразу в регистр. Не так ли?
  5. Итак, что в итоге. По поводу первого вопроса. Сделал через нижние подчеркивания, как бы намекая, что область системная и прямого манипулирования с этой областью не предусматривается. Поставил модификатор const, чтобы нельзя было туда записать в явном виде (как жаль, что нет модификатора запрета и чтения в Си): ... typedef volatile struct { u8 CR1; u8 CR2; u8 FREQR; u8 OARL; u8 OARH; const u8 __RESERVE__[1]; u8 DR; const u8 SR1; u8 SR2; const u8 SR3; u8 ITR; u8 CCRL; u8 CCRH; u8 TRISER; }TI2C; ... По поводу weak-символов. Получил официальный ответ от Cosmic. Оказывается, weak-символы поддерживаются в компиляторах Cosmic только в версиях, начиная с 4.4.7. Синтаксис следующий: void @weak function(void) {...} Текст официального ответа от Cosmic:
  6. SAME70Q21 rev.B - GMAC не работает на TX

    С этим МК не довелось работать, но есть идеи. Вы сами все регистры пишете? Обычно множество функций определяется внешней аппаратной обвязкой PHY. Есть уверенность, что в регистрах автосогласования и выбора режима дуплекса выставлены правильные значения? А откуда взялись некритичные отличия при одинаковом софте? А если сравнить дампы всех регистров в PHY? Вангую, что схема разводки PHY-уровня все-таки немного отличается от отладочной платы. И где-то из-за этого принудительно отключен режим выбора полного дуплекса. Кстати, что говорят параметры сетевой карты при подключении к двум девайсам? Скорость и режим дуплекса разные? Одинаковые?
  7. stm32 i2c

    Однако, просто очень странно, что сам производитель рекомендует делать >9 тактов по SCL при высоком SDA, а не формировать стоп-условия. https://www.nxp.com/docs/en/user-guide/UM10204.pdf Как я понимаю, первый случай (SCL залипла в 0) возможен только в ведомых на шине, поддерживающих технологию clock stretching-а. И тут спасет только вход сброса этой микросхемы (если он вообще имеется; как показывает практика, таких устройств меньше, чем обделенных таким входом), либо внешний перетык питания этой микросхемы (как когда-то я делал на одном из своих девайсов). Второй случай (SDA залипла в 0) спасается подачей 9 циклов синхронизации по линии SCL. И вот в течение этих клоков линия SDA должна подняться вверх. А если не поднялась - простите/извините, используйте аппаратный сброс (если есть), либо рубите канаты питание. Для 10-битной адресации логично подавать больше синхроимпульсов для получения такого же эффекта, выводящего из коматоза. В общем, никакой 100% гарантии. Так вот. Если залип SDA в 0, то стоп-условие, ИМХО, вряд ли поможет, так как при этом мы должны уметь формировать фронт на SDA. А он залип. А им надо дернуть. А он насильно притянут ведомым к 0. Вот картинка: Более того, если SCL еще можно сделать выходом типа push-pull (и то только для ведомых, не поддерживающих clock-ctretching), то SDA сделать push-pull нельзя вообще никогда, только open drain, т.к. шина данных двунаправленная, и при залипании шины в 0 (ведомый активировал нижний ключ входного/выходного драйвера) переводить драйвер мастера шины в push-pull и последующая выдача лог. 1 на этой линии может поджарить драйверы или в подчиненном, либо в мастере (МК). Тогда уж, ИМХО, совсем правильная процедура сброса будет включать сначала подачу 9 (или больше) импульсов синхронизации на SCL при отпущенном SDA, а затем, попутно проверяя состояние SDA входным регистром GPIO, поймав на SDA лог. 1, дать стоп-условие.
  8. stm32 i2c

    Я делал так, как рекомендует сам разработчик интерфейса (NXP). 1. При обнаружении зависания линии отменяю транзакции по этой шине. 2. Выключаю модуль I2C, деактивирую и перенастраиваю GPIO на режим ручного управления без изменения типа выходных драйверов. 3. Даю больше 9 стробов по линии SCL. 4. Выключаю синхронизацию модуля I2C. 5. Сбрасываю модуль I2C в регистрах RCC. 6. Заново инициализирую модуль (включение синхронизации, настройка GPIO и т.д.). Такую последовательность я провожу как при старте ПО, так и в процессе работы девайса при обнаружении заклинивания.
  9. Печально Не плодя тем, еще хотел бы осветить один момент. Пишу файл startup.c с константным массивом, определяющим таблицу векторов прерываний: typedef struct { #define INT_OPERATION_CODE 0x82 u8 INTOperationCode; void (*Handler)(void); }TISRVector; extern void ISR_ResetHandler(void); extern void ISR_TrapHandler(void); extern void ISR_TLIHandler(void); ... extern void ISR_NVMHandler(void); static const TISRVector ISRVectorTable[] = { {INT_OPERATION_CODE, ISR_ResetHandler}, {INT_OPERATION_CODE, ISR_TrapHandler}, {INT_OPERATION_CODE, ISR_TLIHandler}, {INT_OPERATION_CODE, ISR_AWUHandler}, {INT_OPERATION_CODE, ISR_ClockHandler}, {INT_OPERATION_CODE, ISR_EXTI0Handler}, {INT_OPERATION_CODE, ISR_EXTI1Handler}, {INT_OPERATION_CODE, ISR_EXTI2Handler}, {INT_OPERATION_CODE, ISR_EXTI3Handler}, {INT_OPERATION_CODE, ISR_EXTI4Handler}, {0, 0}, {0, 0}, {INT_OPERATION_CODE, ISR_SPIHandler}, {INT_OPERATION_CODE, ISR_TIM1FirstHandler}, {INT_OPERATION_CODE, ISR_TIM1SecondHandler}, {INT_OPERATION_CODE, ISR_TIM2FirstHandler}, {INT_OPERATION_CODE, ISR_TIM2SecondHandler}, {0, 0}, {0, 0}, {INT_OPERATION_CODE, ISR_USARTTxHandler}, {INT_OPERATION_CODE, ISR_USARTRxHandler}, {INT_OPERATION_CODE, ISR_I2CHandler}, {0, 0}, {0, 0}, {INT_OPERATION_CODE, ISR_ADCHandler}, {INT_OPERATION_CODE, ISR_TIM4Handler}, {INT_OPERATION_CODE, ISR_NVMHandler}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, }; Хочу теперь сделать хитрость. Чтобы в разных проектах заново не добавлять/удалять только нужные обработчики, я (как видно выше) определил для линкера все символы (имена обработчиков). Однако, как и следовало ожидать, при сборке проекта и отсутствии определенных обработчиков (их нет в таблице символов линкера), вылезли ошибки типа Что бы я хотел: при отсутствии обработчика в проекте, считать, что он для текущего проекта и не используется, и подставить вместо этого имени значение 0 (хотя это и не так важно). В Keil для этого существовала опция [weak], которая, будучи определенной рядом с именем, указывала, что, если этот символ будет определен в проекте, то использоваться будет именно он. Если нет - то символ со спецификатором [weak]. Является ли стандартной фишкой компоновщика наличие команды, заставляющей обратить ненайденные символы в 0 или другое известное значение, или это бородатый вымысел и такого в принципе не предусматривается? Беглый взгляд на описание компоновщика под Cosmic прямого ответа не дает.
  10. Приветствую! Пишу тут описание регистров периферии для одного МК (STM8, STVD/Cosmic). Бывает так, что между двумя регистрами одной и той же периферии или блока находится пустое пространство (резерв). Так вот, в местах, где такие "дыры" по пару байт, я пользуюсь безымянными битовыми полями: typedef volatile struct { u8 CR1; u8 CR2; u8 NCR2; const u8 FPR; const u8 NFPR; u8 IAPSR; u16 : 16; u8 PUKR; u8 : 8; u8 DUKR; }TNVM; Но есть периферия, между регистрами которой очень много пространства (больше килобайта). Пытался сделать так: u8 : 95856; Однако, даже если писать более короткие размеры u8 : 16; компилятор кричит на невозможность создания такого битового поля: При этом открываю Dev-C++, копирую туда тот же самый код и компиляция проходит успешно (без ошибок, но с предупреждениями). Кто-нибудь знает наиболее красивый способ объявить безымянную пустышку в структуре в произвольное количество байт, чтобы при доступе к элементам с включенной функцией автозавершения кода это пустое место не светилось никакими "Reserved1" и т.д.? Либо что-то типа безымянного массива (правда, я о таких не слышал). Решение нужно кроссплатформенное стандартное P.S. Раньше так и делал - в нужном месте объявлял массив нужной размерности и давал ему имя Reservedx, x = 1, 2...N. Но сейчас ищу способ не захламлять список регистров при всплывающей подсказке.
  11. Размышления на тему TCP/IP.

    Пока существуют ардуино-строители и всякие WizNet-писатели, я без работы не останусь Кстати, есть МК со встроенными MAC+PHY, поэтому нужен будет лишь внешний разъем 8P8C (с трансформатором внутри).
  12. Cosmic IdeaSTM8 и тип INT

    Я лично определил для себя типы известной размерности и их пользую. Либо всякие unit32_t, либо пишу свои typedef unsigned long u32 (как пример), в соответствии с документацией на компилятор.
  13. Я вот когда модули для лаборатории делал, себе одну платку отладочную (макет), естественно, спаял и оставил. На ней я применял F429. Сейчас запаяна туда H753, но допаять десяток конденсаторов и запустить как-то не хватает стимула ИМХО, артефакты пропадут, связанные с медленной прорисовкой. Да и поэкспериментировать не сильно большая проблема, полгода назад H753 вышел мне даже дешевле, чем F429. Покупал в Терраэлектронике, но сейчас у них дороговато. Не думаю, что плату переразводить Вам придется, хотя, вроде, у них несовместимость в 100-выводных корпусах. У меня LQFP-176...