Vitёk

Спасибо за ответ. Стало интересно: как будет вести себя STM с прошивкой от GD. Не пытались проверить?

Прошу прощения за реанимацию старой ветки. У меня такая же проблема на GD32F105RB. Я пробовал использовать как код, сгенерённый кубом для STM32F105, так и библиотеку tinyUSB - в обоих случаях подведение такое же, как вы описали. Скажите, вам удалось решить эту проблему? Или может быть есть у кого положительный опыт переезда с STM32F105 на GD32F105, что бы работал USB device? Уточню: можно ли переделать HAL от STM, что бы это без проблем работало на GD?

Снова нет. Диалог был следующий: k155la3: Ограничение (без отключения) тока, LM317 + (переменный) резистор. См. в datasheet Current-Limiter пример включения. Vitёk: Такой вариант вполне приемлем. Только ограничиваемый ток должен быть пропорционален напряжению на выходе, и при КЗ составлять например 1/10 от номинального, что бы не перегреть регулирующий элемент. Это чуть сложнее, чем LM317. И остаётся вопрос, как оно будет стартовать на нагрузках разного характера. wim: Не получится, если не ограничить диапазон емкостей нагрузки. И понеслась... Будьте внимательней.

Нет. Вероятно, Вы неправильно поняли идею. Ключевым моментом здесь является прямая (ну почти) пропорция между током и напряжением на нагрузке. При нулевом напряжении на выходе (режим КЗ) ток поддерживается в районе 1/10 - 1/20 от максимального, и таким образом нагрев регулирующего элемента снижается до терпимого уровня. На картинке результаты измерения, полученные на макете, нагруженном на переменный резистор. Нижний левый конец графика - это и есть КЗ. По мере роста напряжения на нагрузке - ток через неё тоже растёт, и в случае чисто ёмкостной нагрузки напряжение на ней будет расти почти по экспоненте. Благодарю Вас!

Получится, от величины ёмкости зависит только время, требуемое на её зарядку. По мере зарядки и увеличения напряжения на ней, ток зарядки будет пропорционально расти. Т.о., график напряжения на ёмкости будет похож на экспоненту.

Спасибо всем откликнувшимся! Такой вариант вполне приемлем. Только ограничиваемый ток должен быть пропорционален напряжению на выходе, и при КЗ составлять например 1/10 от номинального, что бы не перегреть регулирующий элемент. Это чуть сложнее, чем LM317. И остаётся вопрос, как оно будет стартовать на нагрузках разного характера. Боюсь, Вы правы. На напряжения до 5.5в (для защиты USB выхода) на рынке представлены сотни наименований, на любой вкус и почти бесплатно. А как только шаг вправо или влево - добро пожаловать в клуб "сделай сам". Немного не то, но с удовольствием ознакомился бы более подробно. Навскидку не нашёл, можете поделиться ссылкой? С уважением, Виктор.

Добрый день! Есть задача защитить выходы источника питания от перегрузок. При обнаружении таковой, выход должен отключаться, и через время пытаться включиться снова. Выходное напряжение - до 20в, ток срабатывания желательно регулировать от десятков до сотен мА. Отключать можно как "+", так и "-", без разницы. Просмотрел множество готовых решений, из подходящих нашёл только TPS1H000, но у него почти нулевая доступность. Есть вариант на рассыпухе, но он громоздок. Подскажите, есть ли доступное интегральное решение с небольшой обвязкой?

AVI-crak, спасибо, ответил в ЛС.

Очень близко к тому, что я ищу. Но, к сожалению, компилятор выдаёт ошибку: Error: bad arguments to instruction -- smull r4,r5 Видимо, в регистровые пары (или что значит Rp) ассемблер не умеет.

По сути я так и делаю - получаю доступ к половинкам через юнион.

Forger, штатные библиотеки устраивают, умножение 32х32 приведено в качестве примера. Вопрос в том, что бы обойтись без структур, объединений и прочего. Что бы объявить переменную long long, и разбить её на 2 половинки. В avr-ском ассемблере, емнип, были директивы hi/lo, которые позволяли получить доступ к 8-битным половинкам 16-битной переменной.

Добрый день! Что бы передать внутрь ассемблерной вставки половинки 64-битной переменной, использую union, примерно вот так: union u_i64 { int64_t i64; int32_t i32[2]; }; int64_t mul64(int32_t m1, int32_t m2) { register union u_i64 ret; asm volatile ( "smull %0, %1, %[m2], %[m1] \n" : "=r" (ret.i32[0]), "=r" (ret.i32[1]) : [m1] "r" (m1), [m2] "r" (m2) ); return ret.i64; } Но хотелось бы, что бы можно было на входе/выходе asm'а указывать непосредственно половинки большой переменной, что-то вроде "res.H" и "res.L". Или объявлять переменную с явным указанием пары регистров, примерно как register uint64_t res asm ("r0:r1"), тогда можно было бы скормить указанную пару r0 и r1. Беглый просмотр документации ответа не дал. Это вообще возможно? Заранее благодарю за ответ. Компилятор arm-none-eabi-gcc 5.4.1 из состава embitz 1.11, проект для Cortex-M3, если что.

Просьба понизить 10% уровень пятилетней давности. :)

OMG... Я, канэшна, подозревал, что освоение новой САПР и перенос проектов не будет безболезненным. Но чтоб через такую ж..... :crying: PS: Спасибо за информацию. :)

Спасибо, получилось. Успешно импортировал ячейки в central library. Только вот вопрос остался. Скачанные с сайта мегратека трансляторы OrCAD->PADS и PADS<->Expedition не очень дружат друг с другом - первый создаёт файлы типа *.??4, а второй требует файлы *.??07. Это в пределах нормы (и их просто нужно переименовать), или я что-то не так сделал?

После работы в OrCAD осваиваю Expedition. Вопрос следующий: при помощи "PADS Layout translator" преобразовал *.LLB библиотеки (футпринты) в наборы файлов *.pt4, *.pd4, *.ld4 и *.ln4. Возможно ли импортировать их в Central library?

Повторить ситуацию не удалось. Получается, что ввел всех в заблуждение, прошу меня извинить. В двух словах, почему?

Компилятор у меня WinAVR (указано в комментарии к названию темы). Некоторые вещи он компилит совершенно безобразно, поэтому приходится делать на асме. Способ генерить поля может и есть, но чутьё подсказывает, что это маловероятно. Такое ощущение, что компиляторы для С и для АСМ сделаны независимо, и пересекаются слабо. В любом случае, спасибо. :) ЗЫ: попрошу модераторов перенести тему в раздел с соотв. компилятором.

SasaVitebsk: Да, примерно так так в конце концов у меня и получилось. С той разницей, что я использовал не указатель, а напрямую адресовал конкретное поле в конкретном экземпляре структуры. И проблемы по большому счёту тоже нет, как Вы правильно заметили. Есть только один момент: при внесении изменений в структуру (а такое иногда бывает), приходится заново вычислять смещение для некоторых её полей (вручную), и менять соотв. дефайны. При создании темы у меня была надежда, что описание структуры (в .h-файле) можно скормить компилятору, что бы он сам проделывал эту работу. Сбыться ей, судя по всему, не судьба. У меня были проблемы с порядком размещения полей в структуре, от которых удалось избавиться при помощи #pragma pack. Может я чего не так делал, или настройки проекта неправильные, но победить удалось после её добавления. Вот сама структура: union TDate { unsigned char date[3]; struct { union { unsigned short mmdd; struct { unsigned char dd, mm; }; }; unsigned char yy; // }; }; Если есть желание, попробуйте, может у вас будет нормально без прагмы... Если да, дайте знать. :)

Решил проблему, относительно красиво. 1. Поместил интересующие поля в самом начале структуры. 2. Окаймил описание структуры с помощью #pragma pack(push, 1) и #pragma pack(pop) (т.к. было неоднократно замечено, что поля в структуре могут физически располагаться не в том порядке, в каком они описаны): #pragma pack(push, 1) struct TStored { volatile unsigned short var_1; volatile unsigned short second_var; //...... все остальные поля } #pragma pack(pop) 3. И, наконец, досткп к ним сделал следующим образом: .extern strd; .equ var_1, (strd + 0) .equ second_var, (strd + 2) //....... lds r25, var_1 + 1 // High lds r24, var_1 // Low Работает нормально. :) Если кто найдёт недостатки данного решения, или знает, как сделать лучше - пожалуйста, не стесняйтесь, буду благодарен за советы.

Вот что я пытался сделать: Собственно, нужно написать что-то вроде такого: lds r16, var Пока var не была полем структуры, всё работало хорошо. После этого я поместил её в структуру, как указано 1-м посту, и пытался сделать следующее: .extern strd.var_1 #define var strd.var_1 и .extern strd.var_1 .equ var, strd.var_1 Результаты были одинаковы: (.text+0x6): undefined reference to `strd.var_1' Правда, каюсь, описание структуры не включал в .s файл, сейчас попробую. ============= Попробовал. Ассемблерный компилятор не хочет понимать С-шные описания структур.

В основном теле программы, написанной на С, используется экземпляр структуры, примерно так: // описание структуры struct TStored { .... volatile unsigned short var_1; .... }; // экземпляр struct TStored strd; // .... strd.var_1 = 0x1234; И есть процедура обработки прерывания, написанная на АСМе (файл типа *.s), откуда необходимо получить доступ к полю var_1 структуры strd. Я безуспешно пытался сделать это несколькими способами, насколько хватило фантазии. Сейчас пребываю в тупике. Подскажите, можно ли это сделать, и если да, то как?

makc, спасибо! :)

XCF01S Интересная мысль, можно и поставить что-нибудь 3-стабильное, но это в крайнем случае. И всё-таки: как оно будет себя вести при включении, описанном выше? Неужели никто не сталкивался?

ПЗУ подключена к ПЛИС по схеме из даташита, ПЛИС грузится в режиме 'master serial'. Логика работы всего этого понятна, за исключением одного момента: если я буду использовать вывод ПЛИС "INIT_B" (он подключен к "OE/RESET" ПЗУ), не будет ли ПЗУ дёргать ножкой "DO" и тем самым мешать работе на линии "DI" ПЛИС? Если сформулировать вопрос по другому: то использовал кто нибудь _одновременно_ ножки ПЛИС "INIT_B" и "DIN" как пользовательские, в режиме "master serial", нет ли здесь подводных камней?