Перейти к содержанию
    

visht

Свой
  • Постов

    344
  • Зарегистрирован

  • Посещение

Весь контент visht


  1. не забыл, и написал об этом... , и потом привел листинг ... Вопрос был не в том как сделать , а в том почему так, И вот на этот вопрос можно ли поподробнее, что же все таки было задумано ... ?
  2. Один и тот же код выполняется с разной скоростью на 2-х разных процессорах. И даже на одном и том же процессоре при выборе разных условий оптимизации. может есть этому научное объяснение, хотелось бы его выслушать. А пока факты: программа выполняет действия: дергает ногой делает задержку (циклом с volatile), дергает ногой выполняет функцию дергает ногой снова задержка дергает ногой выполняет функцию дергает ногой снова задержка дергает ногой измеряются промежутки времени потраченные на задержку между дерганиями для дергания ногой используется Fast метод, соотв бит установлен. вариант 1: уровень оптимизации Level 2, time optimization - off имеем задержки снятые ЛА 70us 195us 250us 96: ESYNC_X; 0x0000B0B4 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0B8 E2200001 EOR R0,R0,#0x00000001 0x0000B0BC E1C403B6 STRH R0,[R4,#0x36] 97: for (i = 0; i < 800; i++); // wait 70 µs 0x0000B0C0 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0C4 E2800001 ADD R0,R0,#0x00000001 0x0000B0C8 E3500E32 CMP R0,#0x00000320 0x0000B0CC 3AFFFFFC BCC 0x0000B0C4 98: ESYNC_X; 0x0000B0D0 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0D4 E2200001 EOR R0,R0,#0x00000001 0x0000B0D8 E1C403B6 STRH R0,[R4,#0x36] 99: write(0x6a); 0x0000B0DC E3A0006A MOV R0,#0x0000006A 0x0000B0E0 EBFFFF91 BL write(0x0000AF2C) 100: ESYNC_X; 0x0000B0E4 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0E8 E2200001 EOR R0,R0,#0x00000001 0x0000B0EC E1C403B6 STRH R0,[R4,#0x36] 101: for (i = 0; i < 1600; i++); // wait 140 µs 0x0000B0F0 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0F4 E2800001 ADD R0,R0,#0x00000001 0x0000B0F8 E3500D19 CMP R0,#0x00000640 0x0000B0FC 3AFFFFFC BCC 0x0000B0F4 102: ESYNC_X; 0x0000B100 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B104 E2200001 EOR R0,R0,#0x00000001 0x0000B108 E1C403B6 STRH R0,[R4,#0x36] 103: write(0x6b); 0x0000B10C E3A0006B MOV R0,#0x0000006B 0x0000B110 EBFFFF85 BL write(0x0000AF2C) 104: ESYNC_X; 0x0000B114 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B118 E2200001 EOR R0,R0,#0x00000001 0x0000B11C E1C403B6 STRH R0,[R4,#0x36] 105: for (i = 0; i < 1800; i++); // wait 250 us 0x0000B120 E59F1094 LDR R1,[PC,#0x0094] // тут 0x708, зуб на холодец 0x0000B124 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B128 E2800001 ADD R0,R0,#0x00000001 0x0000B12C E1500001 CMP R0,R1 0x0000B130 3AFFFFFC BCC 0x0000B128 106: ESYNC_X; 0x0000B134 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B138 E2200001 EOR R0,R0,#0x00000001 0x0000B13C E1C403B6 STRH R0,[R4,#0x36] вариант 2: уровень оптимизации Level 2, time optimization - on имеем задержки снятые ЛА 70us 250us 157us 96: ESYNC_X; 0x0000B0DC E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0E0 E2200001 EOR R0,R0,#0x00000001 0x0000B0E4 E1C403B6 STRH R0,[R4,#0x36] 97: for (i = 0; i < 800; i++); // wait 70 µs 0x0000B0E8 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0EC E2800001 ADD R0,R0,#0x00000001 0x0000B0F0 E3500E32 CMP R0,#0x00000320 0x0000B0F4 3AFFFFFC BCC 0x0000B0EC 98: ESYNC_X; 0x0000B0F8 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B0FC E2200001 EOR R0,R0,#0x00000001 0x0000B100 E1C403B6 STRH R0,[R4,#0x36] 99: write(0x6a); 0x0000B104 E3A0006A MOV R0,#0x0000006A 0x0000B108 EBFFFF89 BL write(0x0000AF34) 100: ESYNC_X; 0x0000B10C E1D403B6 LDRH R0,[R4,#0x36] 0x0000B110 E2200001 EOR R0,R0,#0x00000001 0x0000B114 E1C403B6 STRH R0,[R4,#0x36] 101: for (i = 0; i < 1600; i++); // wait 140 µs 0x0000B118 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B11C E2800001 ADD R0,R0,#0x00000001 0x0000B120 E3500D19 CMP R0,#0x00000640 0x0000B124 3AFFFFFC BCC 0x0000B11C 102: ESYNC_X; 0x0000B128 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B12C E2200001 EOR R0,R0,#0x00000001 0x0000B130 E1C403B6 STRH R0,[R4,#0x36] 103: write(0x6b); 0x0000B134 E3A0006B MOV R0,#0x0000006B 0x0000B138 EBFFFF7D BL write(0x0000AF34) 104: ESYNC_X; 0x0000B13C E1D403B6 LDRH R0,[R4,#0x36] 0x0000B140 E2200001 EOR R0,R0,#0x00000001 0x0000B144 E1C403B6 STRH R0,[R4,#0x36] 105: for (i = 0; i < 1800; i++); // wait 250 us 0x0000B148 E3A01FC2 MOV R1,#0x00000308 0x0000B14C E3A00000 MOV R0,#task_io(0x00000000) 0x0000B150 E2811B01 ADD R1,R1,#0x00000400 0x0000B154 E2800001 ADD R0,R0,#0x00000001 0x0000B158 E1500001 CMP R0,R1 0x0000B15C 3AFFFFFC BCC 0x0000B154 106: ESYNC_X; 0x0000B160 E1D403B6 LDRH R0,[R4,#0x36] 0x0000B164 E2200001 EOR R0,R0,#0x00000001 0x0000B168 E1C403B6 STRH R0,[R4,#0x36] и вот смотрю я на листинг, и он одинаковый, и команду те же, а задержка разная, причем первая одинаковая, а вторая увеличивается ... и если сосредоточить внимание только на второй то имеем 195us 0x0000B0F0 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B0F4 E2800001 ADD R0,R0,#0x00000001 0x0000B0F8 E3500D19 CMP R0,#0x00000640 0x0000B0FC 3AFFFFFC BCC 0x0000B0F4 250us 0x0000B118 E3A00000 MOV R0,#task_io(0x00000000) 0x0000B11C E2800001 ADD R0,R0,#0x00000001 0x0000B120 E3500D19 CMP R0,#0x00000640 0x0000B124 3AFFFFFC BCC 0x0000B11C как так то ? чем дальше адресация флешь, тем дольще выполнение команды ? Жду ваших мнений. Спасибо.
  3. IAR HID mouse example

    не находиться вообще, или определяется как неизвестное устройство ? в первом случае проверьте правильность управления 1,5 кОм резистором. Вполне возможно что на платах это реализовано по разному. во втором проверьте на тот ли порт (у него их 2) подключен ваш разьем, правильно ли выбраны все PINSELx.
  4. suspend & resume USB LPC23xx

    у них там так и написано. USB_NEED_CLK is asserted if any of the bits of the USBClkSt register are asserted. а вот что имелось ввиду под словом любой, остается тайной. Техподдержка не отвечает. Запрос отправлял через офф. сайт, а там конкретных email нету, и мучать некого ... а я бы помучал :maniac: Сегодня пришло письмо, с просьбой подождать еще 5 дней. Тем временем я выяснил, что USB_NEED_CLK все таки сбрасывается, но только при работе в железе. Т.е. если ходить JTAG-ом то в USBClkSt всегда установлен младший бит, и соответственно USB_NEED_CLK всегда 1. А при работе процессора в нормальном режиме, этот бит 0, и все происходит правильно. Однако это не решает проблемы, так как при установки USBWAKE бита просыпания контроллера не происходит. Может нужно самому выключить PLL так как при Power Down она не выключается, может еще что ... пока не выяснил. Но появился новый вопрос в техподдержку, буду продолжать долбить.
  5. suspend & resume USB LPC23xx

    Ну я примерно так и понял. Проверял без буфера, просто ногу паралельно на вход прерывания EINT, все работало. Потом выяснил, что есть возможность просыпаться по той же ноге, но изнутри, и на этом варианте остановился. Так что решение найдено, спасибо за наставления и помощь. PS: USB_NEED_CLK так и не удалось сбросить, проблема видать в том, что USBClkSt = 0x13, т.е. младший бит который Reserved по каким-то внутренним причинам = 1. А сам USB_NEED_CLK видать реализован как лог сложение всех битов USBClkSt. Попытка усыпить контроллер с просыпанием по USB WAKEUP тут же приводит к просыпанию, так как этот бит = 1;
  6. suspend & resume USB LPC23xx

    За обещанный промежуток в 5 рабочих дней техподдрежка NXP так и не ответила. Видимо вопрос не укладывается в стандартные ответы :) На форуме NXP аналогичная ситуация ... По предложенной методике все получилось. Причем в LPC23xx есть возможность настроить на просыпание GPIO0, что позволило обойтись без внешних повторителей. void suspend(void) { USBClkCtrl = 0x00; while ((USBClkSt & 0x12) != 0x00); INTWAKE = 1u<<7; IO0_INT_EN_F = 1u<<29; IO0_INT_CLR = 1<<29; PCON = 0x06; // Power Down PLL_init(); } void resume(void) { INTWAKE = 0; USBClkCtrl = 0x12; while ((USBClkSt & 0x12) != 0x12); } Поиск путей снижения тока потребления привел к следующим изысканиям, может кому то это пригодится: 1. Если USB модуль включен в PCONP, и Power Down происходит не по шине USB, то сам модуль потребляет ~1 мА. При этом, его можно отключить с помощью PINSEL настроив D+ и D- как GPIO. 2. При получении suspend по USB 1мА модулем не потребляется, но можно отключить D+ и D- при этом USB продолжает функционировать и дальше. 3. Сработка прерывания по GPIO0 происходит даже при том, что нога выбрана как USB+. 4. Выключение DEV_CLK и AHB_CLK впринципе не требуется, но логика подсказывает что выключать все таки правильнее. 5. Cигнал USB_POW о наличии подключения USB разьема потребляет 100мкА (подаю через 10к) по понятным причинам 5 В USB и 3.3В контроллера. И вот тут как нельзя кстати подходит предложенный буфер. 6. в Power Down по описанию должна сбрасываться PLL и USB_DIV (в отличие от LPC21xx тут частота береться от основной PLL), но на практике получается что PLL и делитель остаются в настроенном состоянии. Хотя осциллом вижу прекращение генерации на кварце. Вот с 6 пунктом вопрос, то ли я опять чего то гдето не дочитал, то ли глюк чипа, то ли просто мне так везет, но когда нибудь PLL все таки отключиться .. ? И еще вопрос, а что привело к использованию такого рода схемы на LPC124x, ведь там то проблем с USB_NEED_CLK нет ?
  7. suspend & resume USB LPC23xx

    Была такая мысль, но я пока её отгонял. Написал в support и на форум NXP. Подождем результатов, а пока попробую реализовать по вашей схеме.
  8. suspend & resume USB LPC23xx

    Само прерывание по suspend() работает, с FE попробую, но ... ведь тот же usb_needclk используется для просыпания контроллера, и соответственно он уже не проснется.
  9. suspend & resume USB LPC23xx

    в моем случае AP_CLK = 0, т.е. я должен дождаться пока usb_needclk не сброситься, и потом могу убрать тактирование с USB модуля. SOF пропадает, это я вижу на осциллографе, но вот usb_needclk продолжает быть 1. и соответственно дальше ничего не возможно делать. Получается, что я не вижу аппаратно пропадание SOF.
  10. suspend & resume USB LPC23xx

    привожу результаты последних исследований. после этого ядро USB отваливается, J-LINK показавает в области памяти USB 0xAAAAAAAA т.о. действия описанные в Errata можно расценивать как дезу, ну или все таки оно работает на единственной ревизии "-" найти которую уже не получиться. т.о. имеем проблему с тем, что USB_NEED_CLK никогда не становиться равным 0. похожая проблема поднималась тут и тут и осталась без решения. Кроме предложенного вырианта от NXP, был проверен пакет code.bundle.lpc23xx.lpc24xx.uvision.zip в котором вроде как, suspend и resume обрабатываются. результат не удивил, при suspend происходит зависание на цикле ожидания USB_NEED_CLK; непонятно как это работало у человека, который писал этот код :cranky: Есть ли у кого из присутсвующих возможность проверить данный код на платах ENG_BOARD_LPC24XX или KEIL_BOARD_LPC23XX или SK-LPC2378 (c мелкими изменениями в инициализации) ? Есть ли адрес службы поддержки NXP (не то что на сайте, а тот с которого отвечают :) ), или какие другие предложения по поиску решения ?
  11. suspend & resume USB LPC23xx

    Большое Спасибо, за предоставленный код, основную идею понял, но на LPC23xx все оказалось несколько иначе, возможно я опять все попутал ... Итак имеем бит USB_NEED_CLK который должен сброситься после 2ms как только активность на шине прекратиться. Once USB_NEED_CLK becomes one, it it resets to zero 5 ms after the last packet has been received/sent, or 2 ms after the Suspend Change (SUS_CH) interrupt has occurred. В другом месте говориться о том что состояние биты DEV_CLK_EN и AHB_CLK_EN должны быть 0 0 и только после этого USB_NEED_CLK будет равен нулю. After entering the suspend state with DEV_CLK_EN and AHB_CLK_EN cleared, the DEV_CLK_ON and AHB_CLK_ON will be cleared when the corresponding clock turns off. When both bits are zero, USB_NEED_CLK will be low, indicating that the chip can be put into Power Down mode by writing to the PCON register. На самом деле USB_NEED_CLK всегда 1. Errata утверждает что данная проблема имела место в ревизии -, а у меня B. Но предложенный ими вариант решения проблемы испробовал. After setting the PCUSB bit in PCONP (located at 0xE01F C0C4), write 0x1 to address 0xFFE0C008. The USB_NEED_CLK signal will now function correctly. Writing to address 0xFFE0C008 only needs to be done once after each chip reset. чудо произошло, но не надолго. При таком подходе контроллер абсолютно никак не реагирует на то, чтобы ответить на запрос шины, до дискриптора даже не доходит. Хотя если бродить JTAG-ом то все находиться как нужно, при сбросе контроллера и запуске отладки. Тогда сделал следущее: FIO2DIR = (1<<3); if (!(FIO2PIN & (1<<2))) // кнопка для отладки { *((int*)0xFFE0C008) = 1; // без этого USB_NEED_CLK всегда 1 if (FIO2PIN & (1<<3)) FIO2CLR = (1<<3); else FIO2SET |= (1<<3); // проверка входа в режим USBClkCtrl &= ~0x12; // без этого USB_NEED_CLK всегда 1 while ((USBClkSt & 0x12) != 0x00); while (USB_INT_STAT & 0x00000100); INTWAKE = 0x20; PCON = 0x06; USBClkCtrl = 0x12; /* Dev clock, AHB clock enable */ while ((USBClkSt & 0x12) != 0x12); INTWAKE = 0x00; } при этом во первых.... if (FIO2PIN & (1<<3)) FIO2CLR = (1<<3); else FIO2SET |= (1<<3); срабатывает только при отладке JTAG PCON = 0x06; - срабатывает всегда (смотрю по потребляемому току), но проснуться контроллер уже не может. Допустим мы пропустим все режимы сна, а просто после запуска и определения устройства остановимся на suspend, выключим а затем включим драйвер, и продолжим выполнение программы. По логике код должен продолжить функционирование как ни в чем не бывало, но проблема остается все в той же форме.
  12. suspend & resume USB LPC23xx

    Решил пойти другим путем. 1. скачал с сайта производителя тут пример AN10759 USB bootloader (LPC23xx) (v.1.0, 2008-10-14) Там контроллер выдает себя за Mass Storage и появляется в винде в виде диска с файлом firmware. 2. Залил его в мой контроллер. И собственно все те же проблемы. Находиться диск, на нем файл, винда не ругается, применяет стандартный драйвер. Но попытка воспроизвести отключение драйвера с последующей активацией вызывает точно такие же проблемы. Сами функции обработки suspend и Resume есть, но они пустые. Собственно как и у меня. Никаких действий с вводом контроллера в спящий режим не производиться. Может в этом и проблема ? Тогда вопрос, как правильно это делать ? В документации на контроллер никаких упоминаний про рекомендуемые действия после suspend и resume я не нашел. Может не там искал, или не так понял...
  13. suspend & resume USB LPC23xx

    насколько я себе думал, то пробуждение возложено на встроенный контроллер, и все диаграммы он должен формировать аппаратно, без участия написанного кода. Пользовательское ПО должно обеспечить снижение энергопотребления. Или я ошибаюсь ? Проблема в том что что-то в модуле USB происходит такое, из за чего он виснет. Но, по этому поводу в даташите никаких намеков. suspend описан только как событие, и никаких рекомендаций или последовательностей действий я не нашел. Errata тоже молчит по этому поводу.
  14. suspend & resume USB LPC23xx

    Не могу разобраться с проблемой определения девайса после suspend. событие resume отлавливается, но сам контроллер не сообщает драйверу о готовности возобновить передачу. В качестве драйвера использую Thesycon. В качестве контроллера LPC2368 В качестве управляющей программы - пример от tnkernel Логическим анализатором засканил вариант отработки resume на JLink, и тестируемого устройства. При resume на D+ появляется лог 0 на 1ms, после чего происходит обмен и снова в подтверждение D+ становиться в лог 0 на 1ms. В моем случае подтверждения не получается. Аналогичная реакция происходит и при подключении устройства к USB но в этом случае подтверждение есть. Проверяю следующим образом, в device manager Windows отключаю драйвер (при этом ловим suspend) а после включаю, отлавливаю resume но далее контроллер USB не выдает подтверждение, и процесс выдает ошибку. Если в момент после suspend ресетнуть контроллер, то все проходит нормально, и драйвер активируется без проблем. Лог событий из demo приложения от Thesycon: вставляем OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) OnDeviceChange message: 00008004 (DBT_DEVICEREMOVECOMPLETE) The USB device \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4} has been removed. OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) OnDeviceChange message: 00008000 (DBT_DEVICEARRIVAL) A new USB device has been plugged in and is now available. Device path is: \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4}. OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) отключаем драйвер OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) OnDeviceChange message: 00008004 (DBT_DEVICEREMOVECOMPLETE) The USB device \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4} has been removed. задествуем драйвер после ресета программы OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) OnDeviceChange message: 00008000 (DBT_DEVICEARRIVAL) A new USB device has been plugged in and is now available. Device path is: \\?\USB#Vid_16c0&Pid_05dc#000010#{325ddf96-938c-11d3-9e34-0080c82727f4}. OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) если не делать сброс программы то: OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) и через секунду еще раз OnDeviceChange message: 00000007 (DBT_DEVNODES_CHANGED) после чего в состоянии устройства USBIO появляется ошибка: "Запуск этого устройства невозможен. (Код 10)" проверял как на BUS Powered так и на Self Powered, разницы нет. Подскажите в каком направлении двигаться, как отловить проблему, чем засканить обмен более детально, какие варианты попробовать ?
  15. Я не компилировал u-boot, только подверился по вашим функциям инициализации. Подобный демо проект есть и для моей SK-LPC2378 но у него отваливался JTAG после записи MAC_MAC1 = 0x0; /* deassert all of the above soft resets in MAC1 */ причину искать не стал, и занялся адаптацией Ethernet загрузчика от NXP. На данный момент все заработало. Проблема была то ли в драйверах сетевой карты (интеграшка), то ли в конфликтах с внешней Realtek, которая имела что-то сказать по поводу адреса, но при этом работала. Когда я переключился на неё и задал ей статический адрес - все стало проходить. Вернулся к интеграшке, и оказалось что и там тоже все проходит. до этого пакеты только ловились WireShark но реально до KS8721 недоходили. Спасибо.
  16. Спасибо, но это не помогает. У меня физически не видно прихода сигнала на Rx линии. Соответственно никаких изменений по RXD0,1 самого KS8721 тоже нет. WireShark запрос UDP пакета обнаруживает, а вот где он теряется дальше - загадка. HUB через себя инет пропускает, стало быть он исправен. Чем можно посмотреть реально наличие пакета ?
  17. SK-LPC2378 + Ethernet Bootloader NXP

    Пытаюсь проверить работоспособность Ethernet на SK-LPC2378. описанное тут устранено изготовителем. демо версия загрузчика взята здесь Внесены изменения касательно инициализации KS8721. В итоге инициализация проходит, программа зависает в цикле ожидания приема, и собственно все. При запуске утилиты от NXP и попытки вычитать Device ID возникает UDP Communication Error. Состояние RX линий на осциллографе не изменються, присутствует лишь шум в виде наскольких частот. Подскажите кто в курсе, куда копать.
  18. проблему решил путем внимательного прочтения user manual :rolleyes: в процессе было выявлено: на стр. 339 для регистра USBCmdCode имеем CMD_PHASE 0x01 - Read 0x02 - Write 0x05 - Command на стр. 350 имеем пример USBCmdCode = 0x00F50200; // CMD_CODE=0xF5, CMD_PHASE=0x02(Read) где уже 0x02 считается Read. сравнив UM на другие LPC выяснил, что 0x02 действительно Read.
  19. data abort при обращении

    при записи в область памяти USB получаю data abort. Наблюдается только "в живую" (J-Link). проблема возникает после включения USB PCONP |= 1u << 31; из Errata было выяснено: изменение кода на PCONP |= 1u << 31; HC_CMD_STAT = 1; FIO0DIR = 0; USBPortSel = 0x03; // вот после этого - data abort проблему не решает. проект для Keil 3.8a прилагается. надписи на проце: LPC2378FBD144 SH4140.1 01 ZSD0747BY :cranky: tram.rar
  20. PWM на LPC2294

    нет, у меня другие грабли, хотя не такие интересные как ваши. взял на заметку, спасибо.
  21. PWM на LPC2294

    не заметил :laughing: иголки не будет, пишут что сброс имеет больший приоритет. If both a set and a clear of a PWM output are requested at the same time, clear takes precedence. This can occur when the set and clear match values are the same as in, or when the set or clear value equals 0 and the other value equals the PWM rate. писать можно, я вообщем то так и сбрасываю генерацию, просто с этим 0 каналом .... сбило с толку что можно сбрасывать останавливать любым MRx но все это не относиться к режиму с теневыми регистрами. Обычно они в каждом месте сноски ставят, а тут одно предложение. зато теперь запомню надолго :)
  22. PWM на LPC2294

    выхода нет, только на управления защелками теневых регистров и идет. вот я со второго и начал, чтобы можно было установить и сбросить разными MRx после вашего предыдущего поста проверил, действительно так и есть. а после этого нашел таки это место в даташите ... Again, the PWMMR0 match register controls the PWM cycle rate. а выше в описании для простого ШИМ One match register (PWMMR0) controls the PWM cycle rate ... вот как всегда пару слов и описание возможностей сброса любым шимом, но уже без сноски по поводу того что MR0 должен быть больше чем любой сбрасывающий ... причем только в режиме PWM, без теневых он то работает ...! Большое спасибо за терпение. а насчет 03 я все таки не согласен, это 0 и 1 бит в 1, кусок даташита приложил.
  23. PWM на LPC2294

    это так, но вроде только для атмеловских SAM, а у LPC сброс может проводить любой из MR конфигурация чего задается PWMMCR = 0x00000081; // MR2 - Reset, MR0 - interrupt прерывание по MR0 сдесь лишнее, забыл убрать эксперименты. вот я тоже так думал .... а получается нет, запускаю в отладке с MT-LINK останавливаюсь, снимаю галочку на PWM Enable и все генерит, ставлю и все пропадает, чудеса. вероятно Вы с чем то путаете, 03 - сброс таймера следующим тактовым импульсом, и пока оно не станет 01 счетчик шима будет стоять, и стоит, проверил. смысл есть, формирование охранной паузы к примеру, да и канал мне не один нужен, это лишь тестовый пример, чтобы не отвлекать от сути проблемы.
  24. PWM на LPC2294

    дергаю, в том то и дело, не помогает :( PWMLER = 0x07; на 0, 1 и 2 MR соответственно.
  25. PWM на LPC2294

    нужно менять значение ШИМ на лету, задачка вроде стандартная, и для ней предлагается решение в виде PWM. тестовый код для инициализации канала 2 PINSEL0 = 0x00008000; // PWM 2 PWMMCR = 0x00000081; // MR2 - Reset, MR0 - interrupt PWMPCR = 0x00000404; // PWMSEL 2 = 1, PWMENA 2 = 1 PWMMR1 = 0x80; PWMMR2 = 0x100; PWMMR0 = 0x50; PWMLER = 0x07; PWMTCR = 0x09; // PWM enable, Count start работает только в симуляторе, в железе никак. если поставить PWMTCR = 0x01; - все вертиться, но это уже не PWM ... проверил даташит на предмет хитростей - ничего не нашел. в книге Тревора Мартина обнаружил подобный пример, но там есть регистр PWMEMR а в LPC2294 его нет :cranky: причем значимость данного регистра как раз то чего не хватает. вырезку из книги прикрепляю (стр. 100) Если кто сталкивался, поделитесь опытом как бороться :crying: p0100_sel.bmp
×
×
  • Создать...