Сергей Борщ

Конечно проще. Хотя еще проще - купить новый паяльник. А поскольку автор ветки Творит просто для удовольствия, то знание о других возможных решениях будут только полезны. А если сделатьтак к гейту П канала подключить Гейт Н канала ? Теоретически можно. Но в моменты переключения когда один еще не закрылся а второй уже начал открываться будет течь сквозной ток, который будет греть транзисторы и уменьшать КПД. Попробовать можно. Зависит от скорости открывания/закрывания и пороговых напряжений полевиков.

Ну так опубликуйте код этой функции. А еще лучше вместе с ассемблерным листингом этого цикла. Вот здесь возможна проблема. Т.е. warning может и изчезнет, но вместе с ним и чтение TC_SR. предлагаю volatile u32 dummy; dummy = AT91C_BASE_TC0 -> TC_SR;//Acknowledge interrupt status

Конечно проще. Хотя еще проще - купить новый паяльник. А поскольку автор ветки Творит просто для удовольствия, то знание о других возможных решениях будут только полезны.

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

Не прав. Дроссель является индуктивностью, а ток в индуктивности не может измениться мгновенно (напряжение может, на этом зажигание в автомобиле работает). Вот при закрытии транзистора ток и продолжает течь, но уже через диод. А чтобы он не грелся и КПД был совсем хороший, имеет смысл поставить вместо него n-канальный полевик, который открывать в противофазе с Q1. Еще неплохо бы уменьшить R3 до ~680 ом - быстрее будет закрываться Q2 и, следовательно, Q1. несовсем понятно куда нуно поставить Q1 если заменить егь на N канал Q1 заменять не нужно. Полевик можно поставить вместо D2. Важно чтобы этот дополнительный транзистор и Q1 не были открыты одновременно.

извиняюсь за повтор, сглюконуло что-то.

Не прав. Дроссель является индуктивностью, а ток в индуктивности не может измениться мгновенно (напряжение может, на этом зажигание в автомобиле работает). Вот при закрытии транзистора ток и продолжает течь, но уже через диод. А чтобы он не грелся и КПД был совсем хороший, имеет смысл поставить вместо него n-канальный полевик, который открывать в противофазе с Q1. Еще неплохо бы уменьшить R3 до ~680 ом - быстрее будет закрываться Q2 и, следовательно, Q1.

Посмотри тут, похоже твой случай: http://electronix.ru/forum/index.php?s=&am...st&p=120688 Есть лекарство для 3.20А для 30-дневного варианта, могу мылом выслать. Вот тут впечатления о нем по семинару: http://electronix.ru/forum/index.php?s=&am...st&p=117135 В общем ответ такой - если можешь пользовать ИАР, то брось каку (композер). Если нет особой привязанности к GCC, то ИАР однозначно.

Поразительное упорство. :) Я знаю :) :-) Но все равно "не выйдет из тебя путёвого старика" :-) Тем, что с этой самой переферией приходится работать самому. Т.е. ее в программе рассматриваешь как набор этих самых регистров. Т.е. в программе таймер ты видишь не как таймер, а как регистры. А ЕЕPROM компилятор представляет как ПАМЯТЬ в которую можно писать и из которой можно читать. Да, но об особенностях работы с этой памятью ты должен позаботиться сам. Тебя не удивляет ведь, что компилятор не запрещает прерывания при доступе к многобайтовым volatile - переменным? А ведь прерывание может изменить эту переменную посередине чтения в основном цикле. Хочешь атомарный доступ - ручками. Не хочешь - тебе виднее. Когда компиляторы научатся бегать за пивом я уволюсь - ибо тогда программы они смогут писать без меня и подавно. Попробуй вызвать таким манером библиотечную функцию strtok(). Получишь именно только что тобой описанное. Тебя это удивляет? Меня нет. Я знаю, что эта функция нереентерабельная (как и многие другие _библиотечные_ функции). Резюмирую: компилятор в твоих граблях не виноват. Он еще много чего не умеет делать сам ибо это в принципе не возможно. Потому-то к нему программист в комплекте должен быть.

Как правило третий вывод - это встроенный терморезистор. Про зарядку довольно подробно описано в аппнотах атмела ( http://www.atmel.com/dyn/resources/prod_do...nts/doc1659.pdf ) и тексаса ( http://focus.ti.com/mcu/docs/mcusupporttec...actName=slaa287 ) а также в даташитах на микросхемы зарядников (Ti, Analog Devices, Maxim, Linear и т.д.) Скорее всего в аккумуляторе есть и схема защита от перезаряда/переразряда, но лучше в этом убедиться.

Там суть в глобальных ресурсах - сохраняет-же он при входе в прерывание SREG, так чем EEAR и EEDR хуже? Поразительное упорство. А регисты таймера, портов, UARTa, АЦП и прочей периферии компилятор не должен сохранять при входе в прерывание? Нет? А чем они лучше чем EEAR, EEDR? Тем более IAR-овцы должны были на эту выдержку обратить внимание :( . Да не надо валить с больной головы на здоровую. Вам пять человек пытаются объяснить, что компилятор тут не при чем. Это не ИАРовцы, а Вы должны были прочитать эту выдержку и обратить на нее внимание. Ибо только Вам известно где Вы работаете с EEPROM - в прерывании, в основном цикле или и там и там. В двух случаях из упомянутых трех никаких "срадств защиты" на которых Вы настаиваете не требуется. И только в третьем случае нужно предохраняться. Но компилятор не имеет _никакой_ возможности определить какой метод пользуете Вы в своей программе. А поскольку обычно (грамотно) используют первые два подхода, то нет никакого резона перестраховываться и генерить лишний код на случай если кому-то придет в голову поизвращаться.

Поставить курсор в окно с исходным текстом на С++. Ставишь брейкпоинт (кажется не более 3 при отладке из флеш, при том что одну отладчик ставит на main если стоит галочка "Run to main" и сколько угодно при отладке из ОЗУ), жмешь Run.

У LPC213x/4x уже официально, как R/W. Похоже :-(, я по простоте душевной несколько раз пользовал его на "старых" LPC, как R/W без побочных эффектов. Судя по всему у них периферийные блоки практически одни и те же. Не удивлюсь, если их делали одни и те же люди. Так что может статься, что они просто не потрудились описать заложенный функционал. Хотя лично мне этот функционал IOPIN (на запись в регистр) пока ни разу не требовался. Похоже это недоработка в доке. В усер мануале на 2119/2129/2192/2292/2294 тоже написано что он read only, но дальше сказано так:Applications that require instanatneous appearance of zeros and ones on the respected parallel port can use direct access to port’s corresponding GPIO Pin Value Register (IOPIN). Assuming that pins P0.8 to P0.15 are configured as output, write to IO0PIN: IO0PIN = 0x0000 C700 will produce the same output as following sequence of writes: IO0SET = 0x0000 C700 IO0CLR = 0x0000 3800

Ну так напишите обертку и вручную используйте. Компилятор-то тут при чем? Именно так. Внутри обработчика (предворительно исключив собственную рекурсию если она могла быть) разрешается прерывание. Чего тут непонятного :blink: ? Опс. Еще и вложенные прерывания организовать там, где можно просто тупо взять данные из копии в ОЗУ. Тогда не удивительно, что "грабли" :-)

Вот очень подробно описано: http://www.telesys.ru/projects/proj022/index.shtml

Огласите хотя бы один способ. PUSH/POP-нуть глобальные временные регистры EEAR, EEDR... Он это должен сделать тогда и только тогда когда вызов идет из прерывания. Во всех остальных случаях это будут ненужные накладные расходы. Как компилятор определит, что вызов делается из прерывания? Даже при разрешенных прерываниях? Даже если ожидаемое событие все равно глобально должно поменять весь алгоритм работы? :blink: ?? Ожидается готовность eeprom. Что значит при разрешенных прерываниях? Мы уже внутри обработчика. Нет, компилятор тут не при чем. Он физически не может тут ничем помочь. Если уж если вам так хочется поизвращаться - напишите обертку для функции чтения из прерывания.

Огласите хотя бы один способ. Ну, не знал, что чтение в прерывании флагов сохраняемых в EEPROM в каком-то другом месте это глюк :cranky: ... Теперь знаете - вы сами на него напоролись. Для обхода приходится запрещать прерывания в основном цикле, хотя без этого можно было обойтись. Обращение к eeprom требует ожидания готовности eeprom, а ожидание чего-либо находясь в прерывании - ошибка алгоритма. TomaT абсолютно прав. Копии данных, которые могут потребоваться в прерывании надо держать в ОЗУ. И грабли сразу исчезнут. А главное, компилятор сразу станет не виноват.

Это не у этого контроллера надо было отлавливать момент обратного хода развертки и в это время менять содержимое? Да, он. Вот например: http://www.telesys.ru/wwwboards/mcontrol/9...ges/75094.shtml Тема часто поднимается, вот еще: http://www.google.com/search?client=opera&...-8&oe=utf-8

Пришел на работу, прочитал вчерашние сообщения и только рука потянулась написать предупреждение, как похоже вы уже "наступили" :-) Я недавно по дурости первыми же командами инициализации периферии перевел ноги JTAG в состояние обычных ног. А поскольку залил сразу во флешку то получил мигающий светодиод и мертвый JTAG. Пришлось подключить COM-порт, ногой P0.14 принудительно стартануть загрузчик, стереть через загрузчик флешку и только после этого JTAG ожил. Может вас тоже спасет стирание через загрузчик? А про инструмент соглашусь с zltigo - ИАР гораздо дружелюбнее. Там все работает и отладка начинается без всяких заглушек.

Грабли не в компиляторе. Вопрос первый: Зачем запрещать прерывания если программа уже находится в прерывании? Из него плавно вытекает второй: как компилятор определит что в одном случае функция вызвана из прерывания и запрещать не нужно а в другом случае из фона и запрещать нужно? В том виде в каком оно есть все прекрасно работает из фона _без_ лишних накладных расходов - запретов/разрешений прерываний и сохранения/восстановления регистров. Если уж вы решили извратиться и работать с eeprom в прерывании (что само по себе уже глюк, только алгоритма) то уж будьте добры возьмите на себя труд сделать все эти лишние действия вручную и там где по-вашему они необходимы. P.S. А еще он за пивом не бегает, вот это меня бесит больше всего.

Эта, вдруг подумалось... А ноги отвечающие за старт приложения/загрузчика подтянуты куда надо? Хотя на моей макетке никуда не подтянуты и все работает, но может тогда залипли не туда?

Тогда исходник не весь, я не вижу команд дерганья строба (E). Если он не дергается, значит не на всех ножках сигналы есть. Сорри, а как же тогда работал упоминавшийся исходник на MSP430F149? Как это не нашли в описании? А диаграмы смотрели? На E нужно подавать импульс на каждую команду. Как же иначе индикатор поймет, что именно эта комбинация и есть данные индикатору а не кому-то другому или мусор на шине? Суда по тому, что при подаче питания он высвечивает верхнюю полосу (как и Powertip и вообще все которые попадались алфавитно-цифровые ЖКИ) инициализация все же требуется.

Ой... ассемблер :-( Ну симптомы явно указывают на неправильную инициализацию. Глянул инициализацию: ldr r0,=ioset ldr r2,=D45 // установка D4, D5 str r2,[r0] stmfd sp!,{r14} mov r2,#0x200 // 43,4 мкс bl pause ldmfd sp!,{r14} ldr r0,=ioclr ldr r2,=LCD_IOALL str r2,[r0] Вижу выставление D4, D5, задержку и сброс всех ножек. Не вижу где здесь выставляется E. Вы пробоваали на симуляторе или в железе пошагово проходить и смотреть что ноги выставляются именно так как надо? После команд =D45 задержки есть, после остальных команд инициализации задержек нет. Индикатор не будет успевать. Задержки 43 мкс при инициализации маловаты. Я делаю (взял в даташите, с тех пор кочуют из проекта в проект): перед началом инициализации 200мс, после первой и второй команд (0x03) по 50мс и после 0x02 200мс. Далее все задержки около 40 мкс.

А если попробовать в .ddf исправить для нужного участка памяти access type с R на RW - это не поможет? Или добавить еще одну область с RW?

Да. Но кроме локальных переменных на стеке хранятся адреса возвратов из подпрограмм и временные переменные (если они нужны компилятору в процессе выполнения кода). Можно с примерами? Если глобальная переменная инициализирована при объявлении, то необходим код для инициализации и для хранения инициализирующего значения. А если просто int a, b, c; int main (int) { return 1; } и int a, b, c, d, e, f; int main (int) { return 1; } То размер кода должен остаться неизменным.