Сергей Борщ

Откуда известно, что прерывание работает? Дерганья ногой в нем не замечаю. Зато вижу, что при приходе любого числа байт, не кратного четырем код будет крутиться в одном из циклов while (!(UCSRA & (1<<RXC))); rtc_hour = UDR; while (!(UCSRA & (1<<RXC))); rtc_min = UDR; while (!(UCSRA & (1<<RXC))); с запрещенными прерываниями. Почему бы не сделать так: typedef struct { uint8_t day; uint8_t hour; uint8_t min; uint8_t sec; uint8_t sec_div8; } rtc_t; rtc_t rtc; if (UCSRA & (1<<RXC)) { rtc_t Received; Received.day = UDR; while (!(UCSRA & (1<<RXC))); Received.hour = UDR; while (!(UCSRA & (1<<RXC))); Received.min = UDR; while (!(UCSRA & (1<<RXC))); Received.sec = UDR; Received.sec_div8 = 0; __disable_interrupt(); rtc = Received; __enable_interrupt(); Beep_Short(); } #pragma vector = TIMER2_COMP_vect __interrupt void rtc_interrupt (void) { rtc.sec_div8++; if (rtc.sec_div8 == 8) { rtc.sec_div8 = 0; rtc.sec++; if (rtc.sec == 60) { rtc.sec = 0; rtc.min++; if (rtc.min == 60) { rtc.min = 0; rtc.hour++; if (rtc_hour == 24) { rtc.hour = 0; rtc.day++; if (rtc.day == 8) rtc.day = 1; } } } } } Здесь прерывания запрещены на короткое время копирования из временной структуры в основную. Кстати, определить куда именно улетела программа можно вставив дерганье ногой в ключевые места.

А что мешает засыпать прямо в прерывании?Интересно, а если заснуть в прерывании, разве может МК проснуться??? Хм. В остальных встречавшихся мне процессорах мог. Причем в зависимости от того запрещены или разрешены прерывания глобально он после выхода из спячки либо выполнял обработчик прерывания либо просто продолжал выполнение с команды после sleep. В доке на мегу8 об этом ничего не нашел кроме фразы И если понятие "enabled interrupt" выводить как противоположность от то выходит что при глобально запрещенных прерываниях не проснется никогда, что само по себе странно и неестественно. Надо будет проверить это на живом проце. Однако даже это не мешает перед засыпанием запретить прерывание, в обработчике которого находимся и глобально разрешить прерывания. После выхода из спячки и исполнения разбудившего обработчика делаем обратное - запрещаем глобально и разрешаем текущее прерывание. Не забыть только что стека потребуется для обоих обработчиков - текущего и будильника.

Wiggler работал с IARом? Да. Причем пляски в самом начале были связаны с кривой разводкой питания на макете, но никак не с виглером. Счас коллега, по наследству, этот вигглер пользует - я MT-Link купил.

Как тут писал уважаемый vmp, этот фильтр определяет время переходного процесса при захвате ФАПЧ. У меня вообще атмеловский файл расчета этих номиналов в OpenOffice не пошел. Я скопировал номиналы с олимексовской платы ( 1n || (1.5K + 10n) ) и проц работает на всех частотах на которых я его пытался запускать. Хотел бы согласиться, но у LPC2ххх из этого вылезает другой недостаток - там выходная частота может быть только в целое число раз больше входной.

Об этом мы долго спорили с коллегой dxp в привате. Да, конечно можно пользоваться своим. Но тогда придется его создавать его и на тех платформах, где есть stdint.h. Я сторонник stdint.h. Если его в каком-то компиляторе нет - написать руками тот же свой файл, но обозвать его stdint.h. Зато там, где stdint.h есть - писать не придется ничего. Мелочь, а приятно :) P.S. А стандарту С99 уже 8 лет как-никак. А мы (и разработчики компиляторов, к сожалению) все на С89 оглядываемся, который уже "не девочка" :glare: .

Справедливости ради надо сказать что CW с {J|MT|Jet}Link-ом тоже работает. У меня и IAR с ним работал на "ура".

А вы можете сделать минимальный проект из трех файлов (menu.h, menu.c, и заголовка со структурой), выкинув из них все кроме этих определений? Может гоняя такой исходник на своей машине быстрее ответ отыщем?

А что мешает засыпать прямо в прерывании?

Даже если навесить на выходы мощные регистры, все равно дешевле чем AT90CAN128 получится. Да и для Меги 200ма - предельное значение. К тому же не верится что корпус меги сможет рассеять 0.35Вт. Один неверный чих и... А камень действительно интересный. Смотри, потом все проекты, в которых цена проца роли не играет или которые в мегу8 не лезут будешь на них делать :-)

про long (никаких домыслов, только факты): Про float подловили :-) Действительно: И файл называется <stdint.h>, т.е. только целые типы. Правда есть исключения, но тут уже ничего не поможет:

Это имеет еще одно скрытое преимущество - если вы захотите перенести код на другую платформу (например для отладки алгоритма на PC), где нет понятия флеш или ключевого слова __flash, вы просто добавите в начало исходника строчку #define __flash и переменная будет продолжать вести себя адекватно, т.е. константой, и компилятор сможет проконтролировать попытки записи в нее. И сразу на будущее - наверняка придется таскать код между платформами (пример только что привел), сразу же наткнетесь на то, что int, ling, float, double, в общем практически все типы имеют различный размер. Например int у AVR, MSP430, win16 = 2 байта, а у ARM, win32 - 4 байта. И чтобы не попадать в зависимость от этой неоднозначности есть два пути - 1)подключаете стандартный файл <stdint.h> и везде в программе используете переопределенные в нем типы uint8_t, int8_t, uin16_t, int16_t и т.д. (по названию понятно что они означают) 2)пишете для каждой платформы свой файл в котором подбираете подходящий тип: typedef unsigned char byte; typedef signed char sbyte; typedef unsigned short word; typedef unsigned long dword; typedef volatile byte sfr_byte; typedef volatile word sfr_word;

Это нормально. Это небольшая плата за независимость от компилятора и от трюков с __raw и связанных с этим сложностей в версии 2.0

На самом деле правы были все. Обратите внимание на замечания otrog и aesok по поводу volatile. Без этого вполне возможно что программа у вас сейчас работает, а при смене уровня оптимизации, версии компилятора или просто добавлении лишней команды вдруг перестанет. Причем компилятор будет совершенно не виноват. Поскольку вы только начинаете - лучше сразу приучить себя писать правильно, чтобы потом не наступать на эти очень распространенные грабли на ровном месте. Успехов!

здесь инверсию хотите сделать? Имхо надо n = ~n; Как раз в этом случае правильнее !n, ибо переменная по логике программы должна принимать два значения - "ноль" и "не ноль". И конструкция !n это обеспечивает. А вот если n в программе каким-то образом примет любое значение, отличное от 0 или 0xFF, то конструкция ~n всегда будет давать в результате "не ноль": if(n) { } else { } Для Anjey_N: Tens=CharToBCD©; // A PORTA=Tens; Ones=Tens; // B Ones=Ones&(0x0F); Tens=Tens>>4; // C // D Некорректно написан кусок программы. Если прерывание FIRST возникнет в любом месте между A и D то Tens будет иметь значение выходящее за пределы массива decode. Также между B и C Ones имеет некорректное значение. Надо пользоваться временной переменной или запрещать прерывания: __disable_interrupt(); Tens=CharToBCD( с ); PORTA=Tens; Ones=Tens; Ones=Ones&(0x0F); Tens=Tens>>4; __enable_interrupt(); или unsigned char Tmp = CharToBCD( c ); PORTA=Tmp; Ones=Tmp & 0x0F; Tens=Tmp >> 4; Кстати, чтобы компилятор не ругался на __enable_interrupt(), __disable_interrupt() и т.п. достаточно включить <inavr.h>, intrinsic.h подключится из него автоматически.

Задумал использовать систему контроля версий subversion для библиотек PCAD. Обнаружилось две неприятные тонкости: 1) После запуска sch или pcb модифицируется (инкрементируется) счетчик, хранящийся в начале файла в каждой подключенной библиотеке. Даже если никаких действий с библиотекой не происходило. Таким образом subversion справедливо полагает, что файл изменился и готов сохранять изменения. 2) Поскольку файл библиотеки двоичный, subversion сохраняет его тупо целиком, что приводит к непомерному распуханию репозитория и не позволяет отслеживать что же именно поменялось в библиотеке. Достаточно простым решением было бы работать с библиотеками в формате PCAD-ASCII. Но, к сожалению, PCAD не может непосредственно работать с библиотеками в ASCII-формате. Поэтому было бы удобно при работе с репозиторием конвертить библиотеку в текстовый формат и обратно для работы с PCAD. Library Executive имеет в меню Library функцию Translate, но обрабатывать каждый раз каждую библиотеку мышкой абсолютно нереально. Может кто-нибудь знает как странслировать библиотеку из PCAD-Binary в PCAD-ASCII и обратно из .bat-файла? Имеет ли вообще PCAD command-line интерфейс и может где-то есть его описание? Я не нашел :-(

Вот тут выложил один из вариантов, с комментариями по применению: http://electronix.ru/forum/index.php?s=&am...st&p=199555

Часто появляются вопросы об удобном доступе к ножкам порта. Несколько раз выкладывал в разных темах очень удобные (как мне кажется) макросы. Решил выложить здесь наиболее свежую версию, чтобы потом долго не искать. Пользоваться ими так: #define LED1 PORTC,2,H // output, active high (led from PC2 to GND) #define LED2 PORTD,3,L // output, active low (led from Vcc to PD3) #define KEY1 PINB,5,L // input, active low (key from PB5 to GND, pull-up resistor) #define KEY2 PINC,7,H // input, active high (key from Vcc to PC7, pull-down resistor) #include "ascold.h" unsigned char Key1Status; unsigned char Key2Status; void main() { Key1Status = signal(KEY1); Key2Status = signal(KEY2); for(;;) { cpl(LED1); // toggle LED1 if(signal(KEY1)) // if KEY1 pressed, turn on LED2 on(LED2); else // otherwice turn off LED2 off(LED2); } }} Если в результате переразводки вывод поменялся, достаточно изменить лишь одну строчку #define Я использую с компилятором IAR для процессоров AVR, MSP430, AT91SAM7, LPC2xxx, ADuC70xx. Но они должны работать и с любым другим компиляторм. ascold.zip

#define CR "\r\n" // перевод строки __flash char const Tipatest1[] = "Это табулятор: отсюда>\t<до сюда"CR; __flash char const Tipatest2[] = "Это тоже табулятор: >\x08<"CR; __flash char const Tipatest3[] = "Последний символ затерт: *\b"CR; __flash char const Tipatest3[] = "Строчная \"Я\": \xFF"CR; Это имелось ввиду?

Сделать можно, связи появятся, но линий не будет. Будут порты с именами цепей на выводах. Линии все равно придется рисовать самому. Тогда вопрос - а не естественнее ли идти естественным путем (каламбурчик :tongue: ) - от схемы к плате, потом в плате менять местами для удобства разводки эквивалентные выводы/элементы и через ECO переносить изменения с платы в схему? Так гораздо меньше вероятность допустить ошибку.

Да, можно сгенерить новый нетлист и загрузить его. Но удобнее через eco. В схематике Utils->Record ECO->On, вносим изменения, сохраняемся. При сохранении пкад предлагает дополнить eco-файл. Дополняем. Идем в редактор плат. Utils->Import ECO.

На ARM - да, но там я пользую ++ и они "обернуты" в new и delete. В аврах - нет, не было необходимости. Когда для РС писал (еще под ДОСом) - тоже применял.

Чтобы размещать в ней различные данные, используя функции malloc, calloc, free и т.д. из stdlib.h. Динамическое распределение памяти

Это может и верно, но тогда вся маркировка на бекрень съезжает, без зеркала не прочтешь. :) ... а подписывать в отдельности каждый элемент через текст - накладно, пассивных компонентов может и не один десяток набраться. Держим shift, тыркаем в позиционное обозначение. Оно выделяется отдельно от элемента. Кнопкой "R" вращаем в нужную сторону. P.S. интересно, а для чтения трехвыводных зеркало-таки использовалось? :)

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

Да, после приведенного кода снимаю все возражения и обвинения :) Извиняюсь, не смотрел ваши библиотеки, ограничился лишь анализом приведенного куска. Подумал, что раз уж вы выложили кусочек кода, то решили облегчить мне задачу поиска исходников этих библиотек и в представленном коде есть все, что необходимо для обсуждения. Бывает, что некоторые темы я пропускаю ;) Это да, с этим я не спорю. Я пытался спорить с чьим-то утверждением, что компилятор может разместить его в куче. Где там? В куче? Зарадибога. Заметьте, вы получили указатель не "на свободное место в куче", а на свободный участок указанного вами размера. В этот участок никто больше не залезет. Но и вы не имеете права лезть за границы этого участка. Никакого краха. В кучу возвращается выделенный вам участок, на который указывал OW_Rom_Device. Остальные участки если и были выделены кому-то без вашего ведома продолжают существовать. Тут я тоже не буду утверждать категорично - изучал вопрос довольно поверхностно и для аргументированной беседы мне нужно обратиться к литературе, а литература в данный момент не доступна (она на работе, я-дома). Если есть желание - можем продолжить в понедельник, можно в отдельной ветке.