LiTr

Была идея проверить в железе все о чем говорилось выше (проверить светящихся друзей на живучесть), но подумав о затратах времени и предполагаемом результате отказался от этой затеи :) Так что, я думаю, ответ на вопрос "можно ли включать светодиоды без резисторов": "можно? - да, нужно? -нет!"

Тогда я не совсем понимаю смысл приведенных ниже графиков (выдранных мною из документации на линейные светодиодные шкалы KingBright). Согласно им можно вполне конкретно определить и ток и относительную яркость. Я согласен что небольшие изменения в напряжении ведут к значительным изменениям в токе, но на счет зависимости напряжения от температуры мне не совсем понятно, везде в документации на подобного рода изделия даются зависимости ТОКА от температуры.

Тогда назовем его допустимым прямым напряжением, т.е. напряжением которое ниже либо равно максимально допустимому прямому напряжению, таким образом если (согласно ВАХ) наш светодиод имеет Vfmax=2.8 В, то управляя им напряжением в 2.5 В мы уж никак не сможем сделать ему больно. Или я не прав?

Даже если управляются номинальным для них напряжением? Все Вы правильно говорите, однако не вижу доводов "против" того, что может быть система в которой и резисторов нет и с предельными нормами все в порядке. Собственно, я не агитирую всех выкидывать из схем токоограничительные резисторы и включать светодиодные индикаторы напрямую к источнику питания, просто непонятно предвзято-негативное отношение большинства в такому подходу и нежелание представить ситуацию где он мог бы использоваться. P.S. Тема плавно перетекает в пространные разговоры об инженерной грамотности...

Позволю себе с Вами не согласится, т.к. задача разработчика - разработать, ну вот представьте себе, ставится вполне конкретная задача: разработать автономные часики со светодиодной индикацией, понятное дело что обсуждаемые резисторы составляют чуть-ли не половину комплектующих (по количеству, а не по стоимости, разумеется), да и само требование автономности ставит под вопрос необходимость их присутствия на плате (тратят драгоценную энергию на нагрев окружающей среды), вот и появляется идея снижения питания всего устройства и подключение индикатора без резисторов. 1. Эти гарантии в документации: если написано - должен работать, если нет - значит не должен... 2. См. документацию. 3. См. документацию. 4. См. документацию, если некоторые порты МК отличаются от других, это указывается в документации, так например некоторые порты могут быть с открытым коллектором, другие - обычные (с нагрузочной способностью скажем 5мА по низкому уровню), а третью так вообще "High Sink" с нагрузочной способностью, скажем 40 мА и вверх и вниз; ну это я все для примера... 5. Вы имеете ввиду нагрузочную способность порта? 6. Гарантий нет, могу Вас уверить - они разные :) 7. Тоже никаких гарантий - замечательно меняется :) В общем-то Вы просто перечислили вопросы подлежащие проработке при разработке конкретного устройства, вот например пункты 6 и 7 нужно рассмотреть даже в случае использования резисторов (ведь нужно их номинал посчитать). По хорошему большую часть того что Вы перечислили нужно прорабатывать в любом случае.

Нужную длительность могут гарантировать прямые руки. Если же присутствует непреодолимое желание свести риски выгорание портов МК и диодов индикатора к минимуму, есть очень простое решение - снизить питающее напряжение МК до номинального прямого напряжения светодиодного индикатора (обычно лежит в пределах 1.6-2.2 вольт) , в таком случае и ток будет такой какой нужен (ну или почти такой). P.S. Понятное дело, что ко всему нужно подходить с умом, сам я всегда использую токоограничительные резисторы, но истина в том, что включение светодиодных индикаторов без их использования возможно.

Доброго времени суток! На самом деле, в подобной схеме включения нет ничего необычного, необходимо лишь следовать определенным правилам, а именно: 1. Коэффициент заполнения управляющего (светодиодом) напряжения должен составлять 1/10. 2. Длительность импульса должна быть в пределах (примерно) 1-0.1 мс. Конкретные значения этих параметров лучше уточнить в документации на индикатор, в разделе предельно допустимых значений, где обычно указывается максимально допустимый прямой пиковый ток через светодиод и условия (описанные выше) при которых он не наносит разрушающего воздействия на светодиод индикатора.

Можно и другим способом. А именно так как описано в Application Note 2557 "STM32F10xxx in-application programming using the USART (IAP)". Фактически переход по нужному адресу осуществляется через присвоение этого адреса указателю на функцию, с последующим вызовом этой функции. Только не забудьте об переинициализации стека (макрос "__MSR_MSP()" в исходнике cortexm3_macro.s ). Успехов!

По поводу включить/выключить. Сталкивался с подобной ситуацией, то-ли при программировании SPI, то-ли того же самого UART. Подозреваю, все дело в том, что когда происходит перекомпиляция ПО и его последующая прошивка в МК, то сброса как такового, не происходит, т.е. содержимое регистров и ОЗУ сохраняется (я это проверял на не инициализируемых массивах). Таким образом, если для настройки периферии (т.е. установки битов в регистрах) Вы используете операцию лог. ИЛИ, предполагая, что изначально все регистры имеют нулевое значение - то это как раз и может привести в описанный Вами ситуации. Возможное решение: перед настройкой регистров UART - предварительно их обнулить.

Это все конечно понятно, но дело вот в чем: 1. Зачем делать лишнюю работу? Если все можно (точнее очень хочется) прошить за один раз. 2. Вы верно говорите, если в устройстве есть (точнее используются) эти самые интерфейсы. У меня вот например - не используются и ноги все заняты... 3. В IAR у меня даже не получилось создать отдельный файл с данными EEPROM (например HEX или ещё какой), чтоб, например, используя какой-либо из интерфейсов загнать их в МК.

Аналогия не совсем корректна, в приведенном Вами примере EEPROM - это просто место для гаража, который необходимо построить (создать массив данных) и поставить туда машину (инициализировать). Нет, Вы, конечно в праве построить гараж сами, по собственному чертежу (предварительно изучив основы строительства, закупив стройматериалы и т.п.) ну или прибегнуть к помощи строительной бригады которая сама все сделает за Ваши же деньги. Если инициализировать EEPROM отдельно, т.е. через программатор зашивать в неё данные (поскольку среда этого делать не может) то это равносильно строительству гаража собственными силами, если городить функцию копирования данных из Flash в EEPROM, все равно что нанять (а то и содержать) строительную бригаду. Возможно у Вас EEPROM используется иначе, а вот в моем случае, в неё необходимо при первоначальной прошивке устройства занести массив (точнее структуру) настроек устройства, которые в процессе работы могут редактироваться. У STM8 памяти конечно не мало, но занимать килобайт ПЗУ только ради того чтоб его один раз использовать для инициализации ЭСППЗУ - это неправильно. К стати, Atmel и ST тут не причем, речь об IAR, обе платформы и AVR и STM8 имеют возможность чтения/записи EEPROM посредством внутрисхемного программатора, это палка в огород IAR. К слову: STVD+Cosmic прекрасно умеют инициализировать eeprom, только что проверил.

Разработчики IAR сами портировали библиотеку STM8 FWLib под свой компилятор (её можно выдрать из примеров в директории, куда установлен IAR). По поводу векторов прерываний (пункт 3.): загляните в файл реализации "stm8s_it.c" (который лежит там же, в примерах), в данном случае в IAR нет символьного определения векторов прерываний, используются их порядковые номера вот таким образом: /** * @brief Timer4 Update/Overflow Interruption routine. * @par Parameters: * None * @retval * None */ #ifdef _COSMIC_ @far @interrupt void TIM4_UPD_OVF_IRQHandler(void) #endif #ifdef _RAISONANCE_ void TIM4_UPD_OVF_IRQHandler(void) interrupt 23 #endif #ifdef _IAR_SYSTEMS_ #pragma vector=0x19 __interrupt void TIM4_UPD_OVF_IRQHandler(void) #endif { /* Код обработчика */ } Я в своем проекте не использую заголовочные файлы IAR'а - только из библиотеки, с целью возможности безболезненного портирования на Cosmic или Raisonance. По поводу линкера (пункт 7.): кроме того что не создает *.hex файлы, на сколько я понял, вообще нет возможности компилировать различные сегменты кода в разные файлы, для последующего программирования, скажем при помощи ST Visual Programmer. особенно это неприятно, поскольку создать инициализированный массив данных в области EEPROM не представляется возможным (сегмент объявлен как .noinit). Это кажется непонятным - что мешает на этапе загрузки программы во флэш грузить данные и в EEPROM, тем более, что адресное пространство единое.

Помогло! Спасибо!

Возможно автору и так известно но все же: вполне сносное подобие класса можно реализовать на С используя структуры, с их же помощью и создавать булевы переменные как битовые структуры, ибо все равно меньше чем байт в ПЗУ или ОЗУ Вы не адресуете, а инструкций для битовых операций у АВР достаточно, и при грамотном подходе откомпилированный код будет очень компактным. Из личного опыта: и я и многие знакомые-разработчики в свое время отказались от программирования на С++ под контроллеры, так что не наступайте на чужие грабли :)))

Наконец-то удалось поплотнее заняться платформой STM8. Первые свои изыскания в этой области провожу на базе St'шной среды ST Visual Develop в связке с компилятором от Cosmic. Самые первые впечатления были удовлетворительными, за исключением некоторых назойливых моментов, таких как самопроизвольное перемещение тулбаров, кривые пути тулчейнов (которые IDE прописывает по умолчанию), содержащие непонятные символы, и редкие "вылетания". В целом же примеры компилировались и отлаживались нормально. Но вот сегодня IDE выкинула очередной фортель: собрал проект вручную со структурой директорий и исходных файлов привычной для себя, но при попытке компиляции файл "stm8_interrupt_vector.c" чудесным образом исчезает из структуры проекта, и О! Чудо!снова появляется но уже в директории "Source Files", которая тут же и создается (в моей структуре проекта этой директории нет). Все бы ничего и можно было смириться, но компилятор говорит: что этого файла найти не может (физически сам файл как лежал на диске так и лежит). И вот собственно вопрос: как бороться со своеволием среды разработки? Сталкивался ли кто-нибудь с подобным?