prst 0 31 мая, 2007 Опубликовано 31 мая, 2007 · Жалоба Использую: BF-532 на BlackFin есть PPI он использует 4 пина чисто под PPI и 12(из 16ти) от GPIO. в разрабатываемом мной устройстве - PPI должен быть в режиме ПРИЕМ-ДАННЫХ (input) и соответственно шина данных с АЦП тоже - 16ти битная, тоесть на полную шину PPI... В Datasheet документации на BlackFin везде сказано - что эти пины PPI используются и также сказано - что 4 пина GPIO[3..0] отсутствуют для PPI, но тут же сказано что используются для режима ITU-656 (режим видео-потока) и что якобы там на этих 4х чтото для режита ITU-656, но он мне не нужен, нужен саммый классический PPI... Таблица 11-1. Выводы PPI. Название сигнала | Функция | Направление | Альтернативная PPI15 | Данные | Двунаправленный | PF4, выход разрешения PPI14 | Данные | Двунаправленный | PF5, выход разрешения PPI13 | Данные | Двунаправленный | PF6, выход разрешения PPI12 | Данные | Двунаправленный | PF7, выход разрешения PPI11 | Данные | Двунаправленный | PF8, выход разрешения PPI10 | Данные | Двунаправленный | PF9, выход разрешения PPI9 | Данные | Двунаправленный | PF10, выход разрешения PPI8 | Данные | Двунаправленный | PF11, выход разрешения PPI7 | Данные | Двунаправленный | PF12, выход разрешения PPI6 | Данные | Двунаправленный | PF13, выход разрешения PPI5 | Данные | Двунаправленный | PF14, выход разрешения PPI4 | Данные | Двунаправленный | PF15, выход разрешения PPI3 | Данные | Двунаправленный | Отсутствует PPI2 | Данные | Двунаправленный | Отсутствует PPI1 | Данные | Двунаправленный | Отсутствует PPI0 | Данные | Двунаправленный | Отсутствует PPI_FS3 | Кадровая синхронизация 3/поле | Двунаправленный | PF3, выход разрешения PPI_FS2 | Кадровая синхронизация 2/VSYNC | Двунаправленный | Таймер 2 PPI_FS1 | Кадровая синхронизация 1/HSYNC | Двунаправленный | Таймер 1 PPI_CLK | Сигнал тактовой синхронизации с | Входной | Отсутствует корень вопроса таков - можно ли использоать пины PGIO[3..0] как пользовательские - если используется режим PPI (не в стандарте ITU-656 ) Тоесть у меня явная нехватка пинов и я хочу эти 4 пина PGIO[3..0] использовать с пользой и по своему назначению... и как с этими PGIO[3..0] битами работать? дело в том что у BlackFin всего 16 бит пользовательский рессурс PF[15..0] по пинам всего, а тут если верить DataSheet- то с использованием PPI они тупо отсутствуют... еще вот что нашел в русском перефоде даташита ... Поле DLEN[2:0] определяет разрядность данных PPI-порта в любом режиме. Необходимо отметить, что поддерживаются данные любой разрядности от 8 до 16, за исключением 9-разрядных данных. Любые выводы PF, которые не задействуются PPI-портом по результатам настройки поля DLEN, могут использоваться для реализации других функций. ... и как в назло тут же пишут следующее ... В режимах ITU-R 656 разрядность данных, задаваемая полем DLEN, не должна превышать 10. В противном случае лишние выводы резервируются PPI-портом и становятся недоступными для других периферийных устройств. ... тоесть получается PPI откусывает все GPIO пины и недает их для других задач? Могу ли я это понимать что PGIO[3..0] - я таки могу использовать под желаемые мне цели? Если да - то как? Какие есть мысли по этому поводу? Подскажите пожалуйста, посоветуйте...! Документация на BF бледная как непонятно кто... надеюсь на Вашу помошь! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pathfinder 0 31 мая, 2007 Опубликовано 31 мая, 2007 · Жалоба Вы все поняли правильно, в режиме PPI общего назначения (не ITU-656) пины PF0-PF3 доступны как программируемые флаги. Описание работы с PF приводится в Hardware Reference процессора, в разделе Programmable Flags. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 23 1 июня, 2007 Опубликовано 1 июня, 2007 · Жалоба Вы все поняли правильно, в режиме PPI общего назначения (не ITU-656) пины PF0-PF3 доступны как программируемые флаги.Небольшая поправка.. В BF532 пины PF0-PF2 с PPI никак не пересекаются, поэтому могут использоваться с любым PPI-режимом: PF0/SPISS PF1/SPISEL1/TMRCLK PF2/SPISEL2 Что касается флага PF3, то им тоже можно пользоваться, если не использовать режим "2-frame-sync": PF3/SPISEL3/PPI_FS3 "If a particular mode shows a given PPI_FSx frame sync not being used, this implies that the pin is available for its alternate, multiplexed processor function (that is, as a timer or flag pin). The exception to this is that when the PPI is configured for a 2-frame-sync mode, PPI_FS3 cannot be used as a general-purpose flag, even though it is not used by the PPI." - См. HRM, стр. 11-20. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prst 0 6 июня, 2007 Опубликовано 6 июня, 2007 · Жалоба Небольшая поправка.. В BF532 пины PF0-PF2 с PPI никак не пересекаются, поэтому могут использоваться с любым PPI-режимом: PF0/SPISS PF1/SPISEL1/TMRCLK PF2/SPISEL2 Что касается флага PF3, то им тоже можно пользоваться, если не использовать режим "2-frame-sync": PF3/SPISEL3/PPI_FS3 "If a particular mode shows a given PPI_FSx frame sync not being used, this implies that the pin is available for its alternate, multiplexed processor function (that is, as a timer or flag pin). The exception to this is that when the PPI is configured for a 2-frame-sync mode, PPI_FS3 cannot be used as a general-purpose flag, even though it is not used by the PPI." - См. HRM, стр. 11-20. Так понятно, тоесть Вы утверждаете что пины PF0-PF2 таки можно использовать как свободные пины? а если PPI включу в режиме работы 8 бит? в Datasheet говорят что это еще и самый быстрый режим работы... правда реч идет про режим ITU-656... а мне бы хотелось иметь 8 бит интерфейса PPI и 8 пользовательских пинов, что бы можно было дергать переферией своей на плате.... а 8 бит PPI пустить на свой АЦП... в даташите про это ничего не говорится (ADSP-BF531/ADSP-BF532) http://www.analog.com/UploadedFiles/Data_S...BF531_BF532.pdf ... PROGRAMMABLE FLAGS (PFx) The ADSP-BF531/ADSP-BF532 processor has 16 bidirectional, general-purpose programmable flag (PF15–0) pins. Each programmable flag can be individually controlled by manipulation of the flag control, status and interrupt registers: • Flag direction control register – Specifies the direction of each individual PFx pin as input or output. • Flag control and status registers – The ADSP-BF531/ ADSP-BF532 processor employs a “write one to modify” mechanism that allows any combination of individual flags to be modified in a single instruction, without affecting the level of any other flags. Four control registers are provided. One register is written in order to set flag values, one register is written in order to clear flag values, one register is written in order to toggle flag values, and one register is written in order to specify a flag value. Reading the flag status register allows software to interrogate the sense of the flags. • Flag interrupt mask registers – The two flag interrupt mask registers allow each individual PFx pin to function as an interrupt to the processor. Similar to the two flag control registers that are used to set and clear individual flag values, one flag interrupt mask register sets bits to enable interrupt function, and the other flag interrupt mask register clears bits to disable interrupt function. PFx pins defined as inputs can be configured to generate hardware interrupts, while output PFx pins can be triggered by software interrupts. • Flag interrupt sensitivity registers – The two flag interrupt sensitivity registers specify whether individual PFx pins are level- or edge-sensitive and specify—if edge-sensitive— whether just the rising edge or both the rising and falling edges of the signal are significant. One register selects the type of sensitivity, and one register selects which edges are significant for edge-sensitivity. PARALLEL PERIPHERAL INTERFACE The processor provides a parallel peripheral interface (PPI) that can connect directly to parallel A/D and D/A converters, ITU-R 601/656 video encoders and decoders, and other generalpurpose peripherals. The PPI consists of a dedicated input clock pin, up to three frame synchronization pins, and up to 16 data pins. The input clock supports parallel data rates up to half the system clock rate. In ITU-R 656 modes, the PPI receives and parses a data stream of 8-bit or 10-bit data elements. On-chip decode of embedded preamble control and synchronization information is supported. Three distinct ITU-R 656 modes are supported: • Active video only – The PPI does not read in any data between the end of active video (EAV) and start of active video (SAV) preamble symbols, or any data present during the vertical blanking intervals. In this mode, the control byte sequences are not stored to memory; they are filtered by the PPI. • Vertical blanking only – The PPI only transfers vertical blanking interval (VBI) data, as well as horizontal blanking information and control byte sequences on VBI lines. • Entire field – The entire incoming bitstream is read in through the PPI. This includes active video, control preamble sequences, and ancillary data that may be embedded in horizontal and vertical blanking intervals. Though not explicitly supported, ITU-R 656 output functionality can be achieved by setting up the entire frame structure (including active video, blanking, and control information) in memory and streaming the data out the PPI in a frame sync-less mode. The processor’s 2-D DMA features facilitate this transfer by allowing the static frame buffer (blanking and control codes) to be placed in memory once, and simply updating the active video information on a per-frame basis. The general-purpose modes of the PPI are intended to suit a wide variety of data capture and transmission applications. The modes are divided into four main categories, each allowing up to 16 bits of data transfer per PPI_CLK cycle: • Data receive with internally generated frame syncs • Data receive with externally generated frame syncs • Data transmit with internally generated frame syncs • Data transmit with externally generated frame syncs These modes support ADC/DAC connections, as well as video communication with hardware signaling. Many of the modes support more than one level of frame synchronization. If desired, a programmable delay can be inserted between assertion of a frame sync and reception/transmission of data. Подскажите плиз...! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dinam 1 7 июня, 2007 Опубликовано 7 июня, 2007 · Жалоба Пару лет назад делал так и всё работало - PPI(7 downto 0) <= (PF12 downto PF15, PPI3 downto PPI0) :) Oстальными (PF11 downto PF0) спокойно дергал как хотел. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prst 0 7 июня, 2007 Опубликовано 7 июня, 2007 · Жалоба Пару лет назад делал так и всё работало - PPI(7 downto 0) <= (PF12 downto PF15, PPI3 downto PPI0) :) Oстальными (PF11 downto PF0) спокойно дергал как хотел. Во! Вот это вот замечательно! значит остальные PF не заблокированны!!! Огромное спасибо! а перерь еще важный вопрос из вашего поста что значит - PPI(7 downto 0) <= (PF12 downto PF15, PPI3 downto PPI0) ??? объясните плз... . Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dinam 1 8 июня, 2007 Опубликовано 8 июня, 2007 · Жалоба а теперь еще важный вопрос из вашего поста что значит - PPI(7 downto 0) <= (PF12 downto PF15, PPI3 downto PPI0) ??? объясните плз... А это я так написал каким линиям порта PPI какие ножки BF532 соответсвуют :) . И ещё совет - повнимательнее читайте Processor Anomaly List на Blackfin, вдруг там выплывет глюк какой-нибудь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
