esaulenka

В очередной раз порекламирую другой подход к использованию таймера: typedef uint32_t TTimer; #define TIMER_COUNTER LPC_TMR32B0->TC #define START_TIMER(tmr) tmr = TIMER_COUNTER #define TIMER_VALUE(tmr) (TIMER_COUNTER - tmr) #define WAIT_TIMEOUT(tmr,val) while (!(val <= TIMER_VALUE (tmr))) __inline void delay_us (TTimer val) { START_TIMER (TTimer Tmr); WAIT_TIMEOUT (Tmr, val); } __inline void delay_ms (TTimer val) { delay_us (val * 1000); } Используется 32-битный таймер в LPC. Таймер настраивается на частоту 1 МГц и ни разу не сбрасывается. Никто не мешает при этом на тот же таймер вешать какие-то другие прерывания. Для таймеров STM надо поменять typedef TTimer на 16-битный, чтобы эта переменная переполнялась вместе с таймером.

Сергей, а у каких "этих" ? А то я ведь тоже ни одной подтяжки по уарту не ставил...

На правах рекламы - вызов SRecord для подсчёта контрольной суммы векторов прерываний. Алгоритм - сумма int-ов по смещениям 0..0x20 должна быть равна нулю. Контрольная сумма записывается по адресу 0x14. Дальше "пристыковывается" остальной файл без изменений. Под Ваши алгоритмы переделывайте самостоятельно - надо "растянуть" или обрезать файл (смотря по тому, что приходит от линкера) и подобрать правильный ключ для контрольной суммы. echo add arm core vectors checksum srec_cat ^ %File%.bin -binary -crop 0x00 0x14 0x18 0x20 -LECN 0x14 4 4 ^ %File%.bin -binary -crop 0x20 -max %File%.bin -binary ^ -o %File%.bin -binary PS ccitt / xmodem, насколько я понимаю, различаются полиномами.

Проблема "не гарантируем стабильность RTC во всём диапазоне температур" описана в errata. Там же описано и решение - не использовать ревизию "-", использовать ревизию "А". Собственно, мы так и делаем. Проблема, скорее всего, связана с микропотреблением часов. Сигнал на кварце уж больно дохленький - у меня получалось меньше 200 мВ. Правда, сколько "отъедалось" щупом осцилла, я не знаю... А про Ваши исследования можно поподробнее? Ходили по этим же граблям, но климат-камеры у нас нет, а с холодильником эксперименты получались весьма кривые...

Гм. За день решилась половина проблемы? Вас ждёт грандиозный коммерческий успех. Я уже две недели с гораздо более простой задачей копаюсь, и конца-края не видно... Ну так вопросы надо грамотно составлять. Схему подключения для неизвестно какой ширпотребной матрицы никто искать не хочет, это вполне очевидно. А вот какие-то советы на конкретные вопросы тут вполне могут дать.

А какая версия кейла? Проверил на 3.85 (проекты так на 4-ю не перевели...) В одном сишнике typedef struct { float a; float b; } TLimit; const TLimit WeightChannelTableLimits[8] = { {0.0,0.0}, ... В другом typedef struct { float a; float b; } TLimit; extern const TLimit WeightChannelTableLimits[8]; ... i = WeightChannelTableLimits[1].a; Собралось без проблем. Вообще-то хорошим тоном является объявление extern WeightChannelTableLimits в хидере того модуля, где задаётся сам массив. Тогда рекомендация maksimp выполняется "автоматически".

И мне интересно. У нас наштампована уже гора плат - LPC2368 / LPC1768, три микросхемы памяти (в т.ч. одна AT45DB161D), сантиметра три дорожек между ними. И ни единого разрыва, в смысле фронты все аккуратно-прямоугольные, всё отлично работает. А нагрузочной способности в каком бы то ни было виде я в даташите не нашёл...

Знакомый ясновидящий подсказывает, что это Microsoft Visio - простенький векторный редактор. Однако я бы посоветовал сразу купить книжку, скажем, про Альтиум.

О, заодно и я влезу с вопросом. Нужен монохромный дисплей размерами 40..50 x 15..20 мм. Скорее графический, собственный контроллер необязателен (там рядом контроллер будет, скорее всего). Каких производителей посмотреть можно? Разобрать мобильник не предлагать, начальство планирует их сотнями в месяц продавать :)

Вопрос "не программируется" обсуждали только что: http://electronix.ru/forum/index.php?showt...t&p=1006280 А про вопрос "не работает без ULINK'а" ничего не подскажу. Как-то игрался с такой же платой, работала нормально. Да, дурацкий вопрос: Вы как отладчик отсоединяете? Если отключить от компьютера, оставив подключенным к плате, у меня тоже ничего не работает.

О! Спасибо за ценную мысль. Почему-то над словом "OTA" на блок-схеме я не задумался. Ушёл читать...

Угу. Информация из первых рук: ;) The privilege levels for software execution are: • Unprivileged The software: – has limited access to the MSR and MRS instructions, and cannot use the CPS instruction – cannot access the system timer, NVIC, or system control block – might have restricted access to memory or peripherals. Unprivileged software executes at the unprivileged level. • Privileged The software can use all the instructions and has access to all resources. Privileged software executes at the privileged level.

Сижу, разбираюсь в теории построения преобразователей. Наткнулся на следующую странность: во всех букварях цепь обратной связи нарисована так: Однако все даташиты ON Semi (и некоторые даташиты National) предлагают следующее включение цепи компенсации: Причём в примерах расчёта компенсации в даташите ONS нарисована первая картинка. Вопрос: как работает вторая схема? Это ж не обратная связь получается...

Вроде б однозначно всё написано: Таймеров, как у микрочипа, тут не предусмотрено, посему и меандров не будет... А вопрос, как отследить убитую батарею, и мне интересен. Надо будет задуматься, а что вообще такое - убитая батарея...

Некрасиво это как-то... Тем более у топикстартера совсем не 7805 в корпусе TO92, а SOT223. При достаточно большом радиаторе (график есть в даташите на NCP1117) можно целых полтора ватта рассеить.

Т.е. надо написать это по-русски? А всю остальную документацию как тогда читать?!

Да, выдаёт. В недрах даташита (того, что по ссылке) есть описание схемы "за" этим пином HW. Правда, зачем нужен режим, когда к этому пину ничего не подключено, я не осознал... Я подозреваю банальный непропай - при наличии резистора меньше 2 кОм пульсаций не должно быть видно... PS теоретизирую, такие навороченные драйверы в руках не держал. И вообще, если не секрет: в чём прелесть этого AMIS ? Если есть контроллер, можно и самостоятельно крутить мотором, с помощью тупого драйвера, который только и умеет, что ток ограничивать.

Тогда уж наоборот надо считать - 3,3 / 1,8 = 183% КПД ;-) PS при использовании двух линейников КПД от схемы включения зависеть не будет (ну, почти не будет). Меняться будет только распределение тепла по корпусам.

У нас продано несколько тысяч изделий с AT45DB011B[D]. Ни разу так не везло.

Где-то в недрах даташита рассказывали, как это удобно: можно в "кратном" размере хранить данные, а в "дополнительном" - какие-нибудь контрольные суммы. Да, и ещё можно однократно перевести память в режим 512-байтных страниц. 3% емкости при этом теряются.

Направление выходов указываю для контроллера. RTCK - выход тактовой частоты JTAG'а. Можно не подключать, тогда не будет работать автоопределение частоты интерфейса JTAG в отладчике. Отлично решается заданием частоты вручную. RST - вход, обычный резет контроллера NTRST - вход, резет модуля JTAG. Можно не подключать. VTARGET - вход, возможно питать отлаживаемую плату от отладчика. Можно не подключать, если есть своё питание на плате (тем более не каждый отладчик умеет отдавать питание). VREF - выход питания, для определения наличия оного отладчиком. Вопрос с софтом оставляю открытым. Не уверен, что есть что-то, позволяющее программировать и отлаживать ARM'ы через программатор для ксайлинкса.

Неверно выразился. Сначала была комбинация из while (LPC_SSP0->SR & BIT(4)); while(LPC_SSP0->SR & (1<<2)) ucByteReadMem=LPC_SSP0->DR; А потом я второй цикл развернул, стало заметно быстрее. В итоге: было 7 мкс, стало 4,5. С одной стороны - неплохо. А с другой - я два дня страдал фигнёй, ускорив первичную инициализацию аж на 30 миллисекунд. Всё остальное время обмен небольшой, пользователь потерпит.

Не взлетит :( Запихать в FIFO 5 байт получается быстрее, чем он их передаёт. Соответственно, переходим к циклу выгребания, и возвращаем какой-то неверный байт. Но за идею спасибо, в итоге закончилось следующим: uint8_t Mem_ReadByte( uint32_t aunMemAddr ) { ACTIVE_SPI(); LPC_SSP0->DR = 0x03; LPC_SSP0->DR = aunMemAddr >> 16; LPC_SSP0->DR = aunMemAddr >> 8; LPC_SSP0->DR = aunMemAddr; LPC_SSP0->DR = 0; while (LPC_SSP0->SR & BIT(4)); DEACTIVE_SPI(); LPC_SSP0->DR; LPC_SSP0->DR; LPC_SSP0->DR; LPC_SSP0->DR; return LPC_SSP0->DR; } При попытке свернуть чтение в цикл получаем неплохие тормоза...

Уже второй день сижу, экспериментирую... Ну да ладно, пятница :) Закономерности выявить не удалось. При частоте ядра 48 и 36 МГц разница незначительная, а при снижении до 24 МГц задержка возрастает до 1,8 мкс. Сделал так, получил 0,9 мкс задержки. И ещё одна десятая микросекунды в выигрыше. Почему, мне не ясно... При выкидывании проверки вообще получаем промежуток между клоками 80 наносекунд. Только, разумеется, ничего не работает ;-) Идею не понял. А читаемые данные как достать? Там же FIFO, всё перепутается...

Почему же, заглядывал. Надо было сразу написать, что там ничего интересного не найдено. SendByteSPI PROC ;;;47 uint8_t SendByteSPI( uint8_t data) 000000 4903 LDR r1,|L2.16| ;;;48 { ;;;49 LPC_SSP0->DR = data; 000002 6088 STR r0,[r1,#8] |L2.4| ;;;52 while( LPC_SSP0->SR & BIT(4) ) 000004 68c8 LDR r0,[r1,#0xc] 000006 06c0 LSLS r0,r0,#27 000008 d4fc BMI |L2.4| ;;;53 ; ;;;59 return LPC_SSP0->DR; 00000a 6888 LDR r0,[r1,#8] 00000c b2c0 UXTB r0,r0 ;;;60 } 00000e 4770 BX lr ENDP |L2.16| DCD 0x40040000 Mem_ReadByte PROC ;;;171 // ;;;172 uint8_t Mem_ReadByte( uint32_t aunMemAddr ) 000000 b5f8 PUSH {r3-r7,lr} ;;;173 { ;;;174 uint8_t ucByteReadMem; ;;;175 ;;;176 ACTIVE_SPI(); 000002 2405 MOVS r4,#5 000004 4e0d LDR r6,|L6.60| 000006 0724 LSLS r4,r4,#28 000008 4605 MOV r5,r0 ;173 00000a 6126 STR r6,[r4,#0x10] 00000c 6126 STR r6,[r4,#0x10] 00000e 2700 MOVS r7,#0 000010 6127 STR r7,[r4,#0x10] ;;;177 ;;;178 SPI_WriteByte( 0x03 ); // Read Data Bytes 000012 2003 MOVS r0,#3 000014 f7fffffe BL SendByteSPI ;;;179 SPI_WriteByte( (uint8_t)(aunMemAddr >> 16 ) ); 000018 0228 LSLS r0,r5,#8 00001a 0e00 LSRS r0,r0,#24 00001c f7fffffe BL SendByteSPI ;;;180 SPI_WriteByte( (uint8_t)(aunMemAddr >> 8 ) ); 000020 0428 LSLS r0,r5,#16 000022 0e00 LSRS r0,r0,#24 000024 f7fffffe BL SendByteSPI ;;;181 SPI_WriteByte( (uint8_t)(aunMemAddr ) ); 000028 b2e8 UXTB r0,r5 00002a f7fffffe BL SendByteSPI ;;;182 ucByteReadMem = SPI_ReadByte(); 00002e 2000 MOVS r0,#0 000030 f7fffffe BL SendByteSPI ;;;183 ;;;184 DEACTIVE_SPI(); 000034 6127 STR r7,[r4,#0x10] 000036 6126 STR r6,[r4,#0x10] ;;;185 ;;;186 return ucByteReadMem; ;;;187 } 000038 bdf8 POP {r3-r7,pc} ;;;188 ENDP