Fenolftalein

Причина оказалась не в драйвере. В dtb были неверно заданы ranges для pcie. После исправления все заработало.

Смотрели со стороны платы на Xlinx, при чтении BAR на Xlinx тишина. Такая мысль тоже была. u-boot видит PCI bridge и X520. Я не могу проверить, может ли u-boot читать BAR.

pci a000:00:00.0 это не X520, а PCI bridge. # lspci -tv -+-[a000:00]---00.0-[01]--+-00.0 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection | \-00.1 Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection \-[0000:00]- Подключал другое устройство, PCIe плата от Xlinx. Та же история, BAR читается на x86 но не читается на PowerPC

PowerPC выступает в роли PCI-E RC, на кастомной плате разведен слот для PCI, куда вставлена карта X520. По хорошему (на x86 с установленной X520) драйвер читает значения не равные 0xffffffff. Например, первые регистры BAR0 X520 на x86 [ 1743.634529] bar 0x0000 : 0x00000000 [ 1743.634531] bar 0x0004 : 0x00000000 [ 1743.634532] bar 0x0008 : 0x00080000 [ 1743.634533] bar 0x000c : 0xdeadbeef [ 1743.634534] bar 0x0010 : 0xdeadbeef [ 1743.634536] bar 0x0014 : 0xdeadbeef [ 1743.634537] bar 0x0018 : 0x00010000 [ 1743.634538] bar 0x001c : 0xdeadbeef То что драйвер не работает именно на плате PowerPC указывает, что проблема не в нем. Поскольку конфиг хедер X520 читается без проблем, я исключаю аппаратные косяки в плате. Значит проблема или в linux/dtb, или в u-boot. При загрузке в логе есть сообщения вида (a000:00:00.0 - RC) [ 4608.157545] pci a000:00:00.0: PCI bridge to [bus 01-ff] [ 4608.162894] pci a000:00:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff] [ 4608.169711] ====================__find_resource: 650=============== [ 4608.176082] pci a000:00:00.0: BAR 8: no space for [mem size 0x20000000] [ 4608.182700] pci a000:00:00.0: BAR 8: failed to assign [mem size 0x20000000] [ 4608.189674] pci a000:00:00.0: BAR 9: assigned [mem 0xc0100000-0xc02fffff 64bit pref] [ 4608.197414] ====================__find_resource: 650=============== [ 4608.203764] pci a000:00:00.0: BAR 7: no space for [io size 0x10000] [ 4608.210127] pci a000:00:00.0: BAR 7: failed to assign [io size 0x10000] Что может быть причиной таких сообщений? Может ли это влиять на чтение BAR ов устройств, подключенных к RC?

Доброго времени суток. Разбираюсь с написанием PCI драйвера для PCIe EP устройства на Linux для PowerPC (P2020 процессор, кастомная плата). Для эксперимента использую сетевую плату Intel X520. Конфигурационные регистры читаются/записываются без проблем, но чтение BAR всегда возвращает 0xffffffff. Для эксперимента скомпилировал мой драйвер под x86_64 Arch Linux. BAR читается без проблем, значит дело не в моем драйвере. Сравнивая выводы lcpi -vvv для Arch и для Embedded Linux я заметил, что в Embedded для PCI bridge не назначен Interrup pin (конфигурационный регистр 0x3D = 0x00) С чем связана невозможность чтения BAR на кастомной плате PowerPC? 1 Может быть причина в отсутствии interrupt pin для pcibridge в embedded linux? 2 Разная разрядность? Область BAR 64 разрядная. Мой драйвер нормально читает BAR на 64 разрядной Arch, но не может прочитать на 32 разрядной Embedded Linux lspci -vvv для PCI bridge на Embedded linux # lspci -s a000:00:00.0 -vv a000:00:00.0 PCI bridge: Freescale Semiconductor Inc P2020 (rev 21) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin ? routed to IRQ 24 Region 0: Memory at <ignored> (32-bit, non-prefetchable) [size=1M] Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00000000-00000fff Memory behind bridge: c0000000-dfffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable+ DSel=0 DScale=0 PME- Capabilities: [4c] Express (v1) Root Port (Slot-), MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag- RBE- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+ RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x4, ASPM L0s, Exit Latency L0s <2us, L1 unlimited ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna+ CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: pcieport Добавил исходный код драйвера, dmesg загрузки/выгрузки драйвера, полный вывод lspci -vvv. Ремаппинг для BAR0 происходит в probe, чтение из BAR0 в sol_write(). Карта X520 имеет два номера функции, драйвер ремапит и читает bar в a000:01:00.1 powerPC.txt lspci.txt sol_driver.txt

Разобрался. Макрос configUSE_TRACE_FACILYTI нужно устанавливать только при трассировке с записью в буфер, при этом надо выделить память под буфер и задать на него указатель. Другая проблема, в некоторые отладочные макросы, к примеру traceTASK_CREATE(pxTask), передается указатель на структуру блока управления задачей tskTaskControlBlock. Как из этого указателя вытащить данные о задаче (к примеру, имя задачи, приоритет)? Для этого указатель надо привести к типу tskTaskControlBlock, но поскольку определение структуры находиться в с-файле, компилятор не видит его в файле, где я переопределяю трассировочные макросы. Возможные варианты решения: 1. Определить смещение нужных полей от начала структуры 2. Определить свою структуру, с полями идентичными полям структуры tskTaskControlBlock и приводить указатель к указателю на нее. Оба решения негибки и не очевидны. Наверное, авторы предусмотрели более простое решение. Хотелось бы знать, какое? P.S. Непонятно, зачем потребовалось размещать определение структуры tskTaskControlBlock в с-файле. Или это такая защита от случайного доступа к полям структуры?

Доброго времени суток. При попытке скомпилировать проект, с использованием трассировочных макросов (установка configUSE_TRACE_FACILYTI в 1 в "FreeRTOSConfig.h") компилятор выдает ошибку "type mismatch in assigment" на строчку /* Write the details of all TCB's in pxList into buffer. */ listGET_OWNER_OF_NEXT_ENTRY( pxFirstTCB, pxList); в файле "tasks.c" При установке configUSE_TRACE_FACILYTI в 0 все компилируется нормально. Версия FreeRTOS 7.2.0 Компилятор C18

Написал коррелятор на 8-битном сдвиговом регистре. Вход тактовая частота, сигнал. Выход : значение корреляционной функции (5 бит, старший знак) + 0-й бит сдвигового регистра, для возможного расширения. Опорная последовательнось подается на параллельный вход. Среда ise WebPack, ПЛИС xc95288. Результаты: Macrocells : 84 terms : 971 Register : 8 Functional Block 284 То есть я ошибся в предположении, что схема будет жадной до регистров, функциональные блоки закончаться раньше. Я испоьзовал в большинстве блоков параллельные операторы. В связи с этим вопрос по VHDL. Можно ли сэкономить функциональные блоки, за счет использования последовательных опреаторов, вместо параллельных?

На вход ПСП и синхронизирующая частота.

Нет, гораздо меньше. Последовательность несинхронизирована, и это главная проблема. Синхронизация по методу зачетного отрезка, как было замечено выше, ухудшаеться помехоустойчивость. Метод последовательной обработки, как предложил bogaev_roman, тоже приходил в голову, но стоит ли огород городить? Метод сдвигового регистра простой быстрый , а метод циклической обработки сложный, более критичен по времени. Похоже, подберу ПЛИС для варианта со сдвиговым регистром.

Требуется детектор двоичной псевдослучайной последовательности. На вход поседовательность и тактовый сигнал. Два выхода: корреляция ("1" - положительная корреляция, "0" - отрицательная корреляция), и выход обнаружения сигнала ("1" - есть сигнал, "0" - нет сигнала). Видел схему на сдвиговом регистре, разрядностью равной длина ПСП, но эта схема жадная на триггеры (для последовательности 127 бит нужно 127 триггеров). Есть другие варианты, схем и (желательно) описание на VHDL?

Просто, что бы было понятно. Проблема исчезла после того как более внимательно выставил биты конфигурации. Как они влияли на скважность ШИМ так и не понял.

Доброго времени суток. Нужно сделать ГКЧ от 50 до 150кГц на 18f452. Использую ШИМ. Пересчитываю частоту в период, и соответственно изменяю время заполнения, что бы при любом периоде скважность была 50%. На частотах близких к 50кГц скважность 50%. С ростом частоты скважность почему-то увеличивается (примерно 80% на 150кГц), что для ГКЧ не есть хорошо. В моделях MPLAB и Proteus скважность выдерживается. Инициализация ШИМ unsigned int imp; PR2 = (char)(1000/((float)f*0.2) + 0.5) - 1;//4Tosc = 0.2мкс, предделитель не используется, f - частота в кГц imp = 2*PR2 + 2; // длительность импульса 1/2 периода (CCPR1L:CCP1CON<5:4>) = 2[(PR2) + 1] CCPR1L = (imp >> 2) & 0xFF; // старшие 8 бит CCP1CONbits.DC1B0 = imp & 0x01; CCP1CONbits.DC1B1 = (imp >> 1) & 0x01; // младшии 2 бита

Схему можете привести?

Доброго времени суток. Для счетчика Гейгера требуется питание 400в. Требуется получить их от 3-х элементов тип AAA. Старый вариант использовал блокинг генератор, но для его питания нужно минимум 6 Вольт.

В эррате описана только одна ошибка, связанная с EEPROM. Повышенное потребление в ждущем режиме, если EEADDR указывает на значение отличное от 0xFF. Обнаружил следующую вещь: если прочитать EEPROM после долгого выключения, то чтение вернет 0, но последующие чтения будут возвращать уже 255. Что это? Уже проблема чтения или записи? (В промежутке между чтениями производится запись в EEPROM)

EEPROM используется для запоминания настроек устройства при его отключении. Запись производится каждый раз при отключении питания, поэтому не хочу использовать флэш. Еще идеи? Если у МК есть EEPROM, то он должен писаться, по моему так.

Записать EEPROM программатором не удалось, выдает ошибку при верификации. Есть еще идеи?

Добавил перед чтением ожидание сброса флага WR. Это ничего не меняет, в моей программе чтение происходит гарантированно через промежуток времени, достаточный для записи.

Запись с проверкой уже сделал, чтение возвращает 0xff. Записывать EEPROM программатором пока не пробовал.

В МПлаб и протеус все работает, не работает в железе.

Доброго времени суток. pic16lf876a не идет запись во встроенный EEPROM. Компилятор HT-PICC, частота 1MHz (XT), питание 4В. Чтение возвращает 0xFF. Копировал алгоритм записи в EEPROM из даташита, использовал макросы из родного хидера, менял напряжение питания. Все бесполезно.

Пробовал нормировать входной сигнал в разных диапазонах, везде одна проблема, сигнал (синусоида), корректно восстанавливается в течении 0.2, 1.7 с, после чего амплитуда резко возрастает, и кодек ее "режет". Добавил "костыль", при превышении восстановленным сигналом заданного диапазона, устаналиваю начальные условия (предыдущий осчет и индекс шага квантования) в 0. Собираюсь проверить, как это отразиться на звуке. Не нравиться мне такое решение.

Батарея состоит из 6 аккумуляторов, естественно, дельта V может быть выражен не сильно. Для дополнительного контроля будет таймер (заряд не более 4 часов), также контроль по уровню напряжения. Контроллер предполагается использовать обычный. Мне нужна методика расчета дельта V и периода измерения.

Подскажите, как найти значения параметров, для контроля заряда никель-металлгидридных аккумуляторов, с использованием метода ΔV? Конкретно интересует величина ΔV и с каким периодои нужно замерять напряжение, что бы не пропустить снижение?