esaulenka

Микро-советик. Делал программатор для LPC1111, тоже было лень разбирать, что за эхо валится. Послал команду отключения эха, и несколько дней разбирался, что за хрень происходит. Почему-то чтение прошивки (для проверки) при отключенном эхе работало совершенно некорректно. Помучался-помучался и включил эхо обратно. Не так и сложно его отрабатывать (во всяком случае, если оно себя "штатно" ведёт). Не исключаю, конечно, что у меня руки кривые, но на идеальность NXP'шного загрузчика теперь не расчитываю :-) Посмотрел: побайтово эхо сравнивать я поленился, но длина "что послали" и "что отразилось" совпадает. Все отправляемые строки заканчиваются /r/n, если что.

Маленький советик: не надо этим злоупотреблять. Проблемы вида "я сохранил переменную в буфер, вызвал совершенно постороннюю функцию, которая для своих целей попользовалась тем же буфером, а потом в первой функции продолжил работать со своей переменной" могут попортить много нервов. В вышеописанной ситуации всё просто и понятно, но когда код чужой, уровней вложенности - штуки 3, а переменная портится далеко не всегда... Самое забавное - это костыли вида "тут я сохраню переменную из буфера в локальную копию, вызову функцию, а потом восстановлю буфер". Т.е. автор о проблеме знал, но ничего с ней не сделал.

Ну неправда ведь! Прямо в документации написано - чем меньше у слота прерывания (VICVectAddrN, VICVectCtrlN) номер, тем больше у него приоритет. Это я ещё про FIQ не вспомнил... В общем, рекомендую читать документацию ;-) Можно начать с user manual, раздел VIC, подраздел Description. С великими гуру, которые, не зная задачи, могут утверждать "это надо, а это не надо", спорить не хочется.

Не, ну можно, конечно, обойтись без деления. Например, вот так: номер знакоместа = (значение * 85) >> 8 Только зачем этот геморрой? На скорости это не должно сильно сказаться - экран чаще 10-20 раз в секунду смысла обновлять нет. Объем программы разве что...

там вот эта ссылка была вставлена (слегка криво) однако вопрос я даже с картинкой не понял

Почитайте ещё и вот эти рассуждения, довольно любопытно.

Хочется всё-таки заметить, что слова "студент" и "разгильдяй" синонимами не являются. Я вот надеюсь, что в бытность первым, вторым был в пределах нормы :) При написании диплома очень, просто ОЧЕНЬ не хватало советов грамотных специалистов. Они у нас на кафедре были (и, надеюсь, ещё есть! долгие лета!) но, к сожалению, уровень знаний 20-30 летней давности... А помоложе кто - так и не знали нифига... :( Любой вопрос сводился к какой-то пустой демагогии :(

R35 - это обычные контактные площадки, а DNP - это "do not place" ;)

Дурацкий вопрос: union-то зачем? Вполне достаточно одной только структуры. Или это какая-то особенность IAR'а ? с IAR'ом плотно не работал, анонимные структуры не использовал (хотя периодически хочется...).

Влезу, пожалуй, в тему. Задача: - есть термопара "от мультиметра". Кучка самых обыкновенных, от самых обыкновенных mastech'ей. - есть мультиметр (какой-то Unit), у которого нет режима измерения температуры, зато есть ком-порт. - хочется измерять температуру вялотекущего процесса и строить графики во всяких экселях. Точности в пару-тройку градусов более чем достаточно, сейчас пользуемся мультиметром с режимом измерения температуры. Однако сидеть с блокнотиком и час переписывать цифры - грустно это как-то... Итого, если просто мерять напряжение, умножать на коэффициент и прибавлять комнатную температуру, оно заработает? Калибровать лень, тем более морозилки на работе у нас нет :-) Материалов по теме не нашёл. Википедии, может, достаточно будет?..

Страшный зверь, оказывается :)

Я бы предложил не заниматься всякой фигнёй. Особенно если нет твёрдого понимания, что вообще происходит. __packed, конечно, экономит память, но заметно сказывается на объеме программы (на не-кортексах) и на производительности (на любых армах). Кейл (в частности, 4.14 с включенным оптимизатором) достаточно догадлив, чтобы собрать данные в одну кучу. volatile char var_a; volatile int var_b; volatile char var_c; int main(void) { var_a = IOPIN0; var_b = IOPIN1; var_c = var_a + var_b; IOPIN0 = var_c; while (1); } var_a 0x40000000 Data 1 main.o(.data) var_c 0x40000001 Data 1 main.o(.data) var_b 0x40000004 Data 4 main.o(.data)

Я сейчас небольшую крамолу скажу... Мы уже несколько лет продаём железки (счёт - на тысячи), в которых контроллер (LPC2138, LPC2368, LPC1768) непрерывно опрашивает одну ячейку FRAM. К стыду своему, о проблеме не задумывался. Пишем мы туда но очень-то и часто, к тому же предусмотрен механизм транзакций, который частичную запись должен откатить. О том, что может нагадить чтение, никто не подумал... Итого, десяток обращений, связанных с бракованной FRAM (была какая-то партия, в какой-то момент там мог установиться один бит и не сбрасываться никак. При нагреве м/с феном эффект исчезал). Хоть сколько-то массовой ругани "у меня данные слетают" не было. Хотя, возможно, просто так повезло - флажок, который постоянно читается, анализируется при старте только изредка (только в некоторых состояниях). В основном он при старте устанавливается, исходя из анализа других флагов. Но за тему большое спасибо. Пойду срочно внедрять кэш флагов в ОЗУ.

Самый тупой и "неэкономичный" способ: три штуки SPI - мастер и два слэйва. Клок передаёт мастер, данные - слэйвы.

Разъём USB соединён с корпусом устройства (задняя планка, ещё пара внутренних металлических частей) напрямую, а он, в свою очередь, через резистор 1МОм и конденсатор (330пФ или 1мкФ, не помню, завтра уточню) - с землёй устройства. Также корпус и земля соединены в одной точке - в блоке питания. БП не наш, дорабатывать его не получится. Хвост БП - метра полтора. Эта общая точка, в свою очередь, через БП подключается к зазмляющему контакту в розетке. Собственно, это очень похоже на рекомендации FTDI и известной статьи о защите от помех (ссылочку могу завтра напомнить, но её тут часто рекомендуют :) ).

Ну вот, уже теплее :-) Некоторые проблемы: - код не компилируется из-за опечаток. Ай-ай, ну надо ж хоть проверять. Благо это можно сделать совершенно бесплатно (и довольно интересно, надо заметить). - таймер и АЦП по-прежнему не работают (описывал проблемы выше). Это тоже можно проверить. - название переменной ADC похоже на название регистра. Это не проблема, это просто некрасиво, на мой взгляд. - вот это неизвестный мне язык: delay[2000]={0 0 0 0 0 … 0}; Инициализацию нулями (если уж хочется) проще сделать в цикле. - алгоритм сдвига вроде б рабочий (один только вопрос: что будет, если tau переполнится?), но гораздо лучше ничего никуда не двигать. Более правильным является алгоритм кольцевого буфера: берём индекс i (можно тау :) ), считываем i-ый элемент (это будет выходом алгоритма), записываем на это же место входное значение. Увеличиваем i на единицу, проверяем, если оно вышло за пределы массива, сбрасываем его в ноль (т.е. в начало массива). Итого при минимальных действиях получаем то же самое поведение - входной сигнал попадёт на выход только после того, как i совершит полный "круг" и второй раз окажется в той же ячейке.

Да, это совершенно банальная проблема в виде наводящейся на кабель помехи. Желающие могут попробовать поставить на металлический лист (у нас используется боковинка от ATX корпуса) своё устройство и "щелкнуть" туда разрядом 4-6 киловольт (наносекунды не помню, но их немного). Убрать совсем помеху, скорее всего, не получится. Мы можем рекомендовать клиентам какое-то размещение, можем им кабелей купить (несколько тысяч, на каждое проданное устройство), можем порекомендовать (и даже, возможно, выполнить) какие-то доработки, но шкафы, которые будут экранировать нашу железку от всего остального никто никогда ставить не будет... kovigor, расскажете, как выглядит несырой механизм входа-выхода из suspend ?

Мда. Плохо победили... Периодически оно таки отваливается... "Дёргать" connect неинтересно - возникают проблемы у софта на ПК, хотелось бы не перезапускать тамошний драйвер. Собственно, что я вижу: по какой-то проблеме (разряд статики вблизи кабеля, или, например, просто кратковременное замыкание D+ и D-) в регистре Device Status появляется значение 0x0D - выставлены биты connect, suspend, suspend change. Попытка сделать remote wakeup - сделать Set Device Status без бита suspend не работает - сначала из регистра статуса читается 0x09 - без бита suspend, а потом сразу же после - с этим битом.

Ура. Ещё чуть-чуть - и алгоритм наконец родится! По поводу того, что я говорил о 20000 значений - это я что-то неправильное говорил... Для начала предлагаю обдумать задержку на 0.05 секунд и расписать на бумажке, какие значения запоминаются, а какие - выводятся. Десятка тактов для понимания должно хватить. Учебник языка Си. Классика - Керниган и Ричи (спрашивать в гугле), но это описано в ЛЮБОМ учебнике. Заполнение нулями - либо вызовом memset (см. гугл) либо организацией цикла.

Волшебные буквы |= &= ~ << UL (и прочие) должны быть описаны в любом справочнике по языку Си.

Вообще-то "список команд на Си" придуман задолго до появления LPC и описан в любом учебнике по Си. Есть маааленькие расширения языка (дополнительные функции, прагмы и прочие служебные слова). Это в первую очередь зависит от компилятора. Однако для простоты можно про них не думать. Работать лень, загнал в Кейл вышеприведённый пример. Рекомендую повторить, очень полезно - у кейла (демоверсия - бесплатно) более-менее работоспособный симулятор и удобные окошки с галками для просмотра периферии (да, они с "побочными эффектами", но для первоначального ознакомления пойдёт). Так вот: - АЦП неработоспособно (два канала при ручном запуске выбирать нельзя, надо каждый раз заново устанавливать) - таймер неработоспособен (неправильно выбран режим) - несколько мелких опечаток в именах регистров А всё остальное работает. Я сделал маленькое открытие - зря я боялся float'ов, на 32-битниках они довольно шустро обсчитываются. Просто я в своих проектах медленно и мучительно переводил всё в fixed-point, пересчитывая все коэффициенты. Десяток сложений и десяток умножений - это около 600 тактов. Терпимо... Да, и ещё. У 2148 32 килобайта памяти (+ 8 килобайт "сбоку"), туда никак не влезет 20000 запомненных значений. Разве что ограничить точность одним байтом.

На таймере, всё на таймере. Это и Си, и ассемблер, и всё-что-угодно. Задержки типа "тупой цикл" можно делать только для проверки (программа "подёргать ножкой", для проверки живости вывода) или для коротких задержек, которым некритичны небольшие отклонения. Вот, например. Там, правда, смесь STMа c LPC, но принцип (целых два!) видно. http://electronix.ru/forum/index.php?showtopic=99675 Если использовать просто циклы (даже написанные на ассемблере, для исключения влияния компилятора), результат никто не гарантирует. Прерывание в середину влезет, например.

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

Да блин... Мы говорим о квантовании в 10 мс или в "примерно 20 секунд" ?

Идея в следующем: каждые 10 мс вызывать прерывание, чтобы оно что-то там считало с гарантированной частотой. Идея хорошая, реализация тоже ничего так, но... Как это работает: - программа стартовала, запустила счётчик - счётчик натикал свои 10 мс, сработало прерывание, посчитались нужные значения - в прерывании же начала работать задержка 20 секунд (о том, что такие задержки делать нельзя - см. выше). - ещё через 10 мс (за вычетом времени расчётов) счётчик опять пытается вызвать прерывание. Это не проходит, т.к. из текущего прерывания мы ещё не вышли. - предыдущий пункт повторился около 2000 раз, т.к. задержка длинная. - задержка наконец закончилась, программа выходит в основной цикл. - ... и тут же попадает обратно в прерывание, т.к. таймер давным-давно установил флажок прерывания. Отличия от того, что написано в первом посте, видно?