|
LPC1766: порты ввода-вывода тормозят? |
|
|
|
Sep 27 2012, 12:39
|
Участник

Группа: Участник
Сообщений: 28
Регистрация: 4-07-11
Пользователь №: 66 052

|
Завязка: К отладочной плате olymex была варварски припаяна (так как свободно-торчащих пинов на плате нет) самодельная светодиодная матрица 2х2 (схему матрицы могу приложить, если нужно). Какое-то время мой код для работы с этой матрицей работал без нареканий, а потом в один прекрасный момент я решил поднять частоту процессора (заюзав PLL) до 100 МГц. Светодиоды гореть перестали. Это явление было не очень стабильным, на разных частотах код вел себя по-разному и не всегда одинаково. На четвертый день разборок бажный код редуцировался до вот такого фрагмента, который должен выключать все светодиоды. В таком виде код работает.: Код LPC_GPIO1->FIOPIN |= (1<<14 | 1<<15); LPC_GPIO1->FIOPIN &= ~(1<<16 | 1<<17); А вот в таком - нет. PLL в обоих случаях отключен, проц тактируется от внутренней цепочки на 4Мгц. Код uint32_t tempPin; uint32_t mask;
uint32_t temp; tempPin = LPC_GPIO1->FIOPIN; mask = (1<<14 | 1<<15); tempPin |= mask; LPC_GPIO1->FIOPIN = tempPin;
tempPin = LPC_GPIO1->FIOPIN; mask = (1<<16 | 1<<17); tempPin &= ~mask; При пошаговой отладке работают оба варианта. Если вот этот момент Код LPC_GPIO1->FIOPIN = tempPin; tempPin = LPC_GPIO1->FIOPIN; не делать (или вставить задержку в пару тактов между этими строчками), то все работает. Т.е., насколько я понимаю, значение в регистре толи меняется, толи считывается недостаточно быстро. Вопрос: прав ли я или проблема может быть в чем-то другом? Если я прав, где в даташите это описано или как это вообще гуглить, что делать? <_>
|
|
|
|
|
Sep 27 2012, 13:42
|
Участник

Группа: Участник
Сообщений: 28
Регистрация: 4-07-11
Пользователь №: 66 052

|
Цитата(RabidRabbit @ Sep 27 2012, 17:33)  А почему бы не заюзать FIOSET/FIOCLR, удобней же (на мой взгляд)?
И 3 последние строчки
tempPin = LPC_GPIO1->FIOPIN; mask = (1<<16 | 1<<17); tempPin &= ~mask;
вроде вообще не нужны? что они делают? Таки да, FIOSET/FIOCLR заюзать можно и работают они корректно. Просто я к портам по указателям обращаюсь и так пришлось бы хранить два указателя, вместо одного. К тому же FIOPIN должен работать точно так жеТри последние строчки - это запись нулей в 16 и 17 бит, то же самое, что FIOPIN &= ~(1<<16 | 1<<17); чтобы выключить столбцы матрицы.
|
|
|
|
|
Sep 28 2012, 04:55
|
Частый гость
 
Группа: Участник
Сообщений: 107
Регистрация: 26-09-10
Пользователь №: 59 748

|
Цитата(poganoe_lamerishe @ Sep 27 2012, 17:42)  FIOPIN &= ~(1<<16 | 1<<17); Это три инструкции: считать, наложить маску, записать. Set/Clr - одна. У кортекса можно вообще обращаться через битовую память. А причина такого поведения может быть, если между read/set другой процесс также ставит свои биты в порте. Попробуйте прерывания запретить.
|
|
|
|
|
Sep 28 2012, 05:49
|

Местный
  
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091

|
Цитата(poganoe_lamerishe @ Sep 27 2012, 18:42)  Три последние строчки - это запись нулей в 16 и 17 бит, то же самое, что FIOPIN &= ~(1<<16 | 1<<17); чтобы выключить столбцы матрицы. В первом варианте Вы записываете нули в 16-й и 17-й биты LPC_GPIO1->FIOPIN, а во втором - в 16-й и 17-й биты переменной tempPin. Записи переменной tempPin в LPC_GPIO1->FIOPIN в приведенном Вами фрагменте кода нет (точнее, оно производится до обнуления 16-го и 17-го битов). Таким образом, приведенные Вами фрагменты кода не эквивалентны. По поводу Код LPC_GPIO1->FIOPIN = tempPin; tempPin = LPC_GPIO1->FIOPIN; Я не знаком именно с LPC, но в некоторых контроллерах такой код, действительно, может прочитать старое (еще не измененное) состояние ног. Если для LPC это справедливо - то в данном фрагменте у Вас race condition, чем и объясняется зависимость результата от частоты.
Сообщение отредактировал alx2 - Sep 28 2012, 05:50
--------------------
Всего наилучшего, Alex Mogilnikov
|
|
|
|
|
Sep 28 2012, 11:12
|
Участник

Группа: Участник
Сообщений: 28
Регистрация: 4-07-11
Пользователь №: 66 052

|
Цитата(alx2 @ Sep 28 2012, 09:49)  В первом варианте Вы записываете нули в 16-й и 17-й биты LPC_GPIO1->FIOPIN, а во втором - в 16-й и 17-й биты переменной tempPin. Записи переменной tempPin в LPC_GPIO1->FIOPIN в приведенном Вами фрагменте кода нет (точнее, оно производится до обнуления 16-го и 17-го битов). Таким образом, приведенные Вами фрагменты кода не эквивалентны. Да, пропустил последнюю строчку, где LPC_GPIO1->FIOPIN = tempPin еще раз. Невнимательный стал. Цитата(alx2 @ Sep 28 2012, 09:49)  По поводу Код LPC_GPIO1->FIOPIN = tempPin; tempPin = LPC_GPIO1->FIOPIN; Я не знаком именно с LPC, но в некоторых контроллерах такой код, действительно, может прочитать старое (еще не измененное) состояние ног. Если для LPC это справедливо - то в данном фрагменте у Вас race condition, чем и объясняется зависимость результата от частоты. Ну я подозреваю, что так и происходит, только в даташите или юзер-мануале ничего подобного не увидел. Может быть такое поведение и нормально, только вот как я о нем догадаться был должен? Цитата А причина такого поведения может быть, если между read/set другой процесс также ставит свои биты в порте. Попробуйте прерывания запретить. Прерывания, разумеется, запрещены. Цитата Да зачем два? Адрес FIOnCLR = Адрес FIOnSET + 4 А так получается платформозависимо  Но, вообще, сейчас мне пришло в голову, что идеально было бы юзать bit-banding. Тогда пришлось бы хранить только один указатель, а сейчас - указатель и маску. Ладно, это потом как-нибудь. -_-
|
|
|
|
|
Oct 1 2012, 15:25
|
Участник

Группа: Участник
Сообщений: 28
Регистрация: 4-07-11
Пользователь №: 66 052

|
В целом, вопрос следующий - это вообще нормальное поведение для регистров порта? Или это косяк LPC? Или или или что это вообще.
|
|
|
|
|
Oct 1 2012, 17:55
|

Нечётный пользователь.
     
Группа: Свой
Сообщений: 2 033
Регистрация: 26-05-05
Из: Бровари, Україна
Пользователь №: 5 417

|
Такое поведение (когда запись на выход может в следующем такте не прочитаться со входа) — так это запросто. Вот из документации на AVR ATmega8 Цитата Reading the Pin Value Independent of the setting of Data Direction bit DDxn, the port pin can be read through the PINxn Register Bit. As shown in Figure 22, the PINxn Register bit and the preceding latch constitute a synchronizer. This is needed to avoid metastability if the physical pin changes value near the edge of the internal clock, but it also introduces a delay. ... When reading back a software assigned pin value, a nop instruction must be inserted as indicated in Figure 24. У AVR эта задержка гарантирована и фиксирована, а у LPC могло на низких частотах успевать «аналоговые» задержки (в буферах) до следующего такта выбрать, а на высоких — нет и появилась дополнительная задержка. И NOP не поможет, он растворится между двумя командами обращения к шине периферии. По хорошему, если нужно узнать, что мы вівели в порт (а не что на него пришло снаружи), то читать надо FIOSET (текущее значение регистра выхода), это не будет зависеть ни от задержки выходного буфера от регистра до ножки, ни от задержки входного буфера и подсинхронизации после него, что всё вместе влияет на прохождение сигнала до FIOPIN. А передавать надо один указатель на порт (структуру порта), а там уже port->FIOPIN = port->FIOSET & ~mask; если по какой-то причине не хочется писать port->FIOCLR = mask;
--------------------
Ну, я пошёл… Если что – звоните…
|
|
|
|
|
Oct 1 2012, 23:51
|
Участник

Группа: Участник
Сообщений: 28
Регистрация: 4-07-11
Пользователь №: 66 052

|
Цитата(ReAl @ Oct 1 2012, 21:55)  Такое поведение (когда запись на выход может в следующем такте не прочитаться со входа) — так это запросто. Вот из документации на AVR ATmega8 У AVR эта задержка гарантирована и фиксирована, а у LPC могло на низких частотах успевать «аналоговые» задержки (в буферах) до следующего такта выбрать, а на высоких — нет и появилась дополнительная задержка. И NOP не поможет, он растворится между двумя командами обращения к шине периферии.
По хорошему, если нужно узнать, что мы вівели в порт (а не что на него пришло снаружи), то читать надо FIOSET (текущее значение регистра выхода), это не будет зависеть ни от задержки выходного буфера от регистра до ножки, ни от задержки входного буфера и подсинхронизации после него, что всё вместе влияет на прохождение сигнала до FIOPIN.
А передавать надо один указатель на порт (структуру порта), а там уже port->FIOPIN = port->FIOSET & ~mask; если по какой-то причине не хочется писать port->FIOCLR = mask; Звучит правдоподобно, но вот отсутствие (или моя неспособность найти) этой информации в даташите меня угнетает. Если уж вставлять задержки, то надо знать, сколько. Шаманить-то не хочется. Структура порта да, как вариант. Проще всего, разумеется, ничего не читать вообще, а только писать в FIOSET и в FIOCLR, не трогая FIOPIN.
|
|
|
|
|
Oct 2 2012, 04:46
|
Профессионал
    
Группа: Свой
Сообщений: 1 453
Регистрация: 23-08-05
Пользователь №: 7 886

|
Цитата(poganoe_lamerishe @ Oct 2 2012, 03:51)  Звучит правдоподобно, но вот отсутствие (или моя неспособность найти) этой информации в даташите меня угнетает. Если уж вставлять задержки, то надо знать, сколько. Шаманить-то не хочется. ..... Цитата FIOPIN Fast Port Pin value register using FIOMASK. The current state of digital port pins can be read from this register, regardless of pin direction or alternate function selection (as long as pins are not configured as an input to ADC). The value read is masked by ANDing with inverted FIOMASK. Writing to this register places corresponding values in all bits enabled by zeros in FIOMASK. Important: if an FIOPIN register is read, its bit(s) masked with 1 in the FIOMASK register will be read as 0 regardless of the physical pin state. Последние три слова подтверждают то, что при чтении этого регистра подразумевается именно считывание физического состояния цифрового порта. В независимости от того, настроен порт на вход или на выход. Читаем дальше. Цитата Writing to FIOSET/FIOCLR vs. FIOPIN Writing to the FIOSET/FIOCLR registers allow a program to easily change a port’s output pin(s) to both high and low levels at the same time. When FIOSET or FIOCLR are used, only pin/bit(s) written with 1 will be changed, while those written as 0 will remain unaffected. Writing to the FIOPIN register enables instantaneous output of a desired value on the parallel GPIO. Data written to the FIOPIN register will affect all pins configured as outputs on that port: zeroes in the value will produce low level pin outputs and ones in the value will produce high level pin outputs. Запись в этот порт имеет смысл только для пинов настроенных на выход. А теперь самое интересное: Цитата Reading the FIOxSET register returns the value of this register, as determined by previous writes to FIOxSET and FIOxCLR (or FIOxPIN as noted above). This value does not reflect the effect of any outside world influence on the I/O pins. Вот этот регистр уже отражает именно внутреннее состояние порта (состояние выходного драйвера) на вывод. Таким образом ваш код должен был иметь вид: Код FIOPIN = FIOSET ^ MY_MASK; Таким образом не будет никакой "аналоговой" обратной связи по физическому уровню на пине порта. P.S. В начале работы с LPC сам столкнулся с такой фичей. Это побудило просто внимательно перечитать документацию. После прочтения становится всё очевидно.
|
|
|
|
|
Oct 2 2012, 13:16
|

Профессионал
    
Группа: Свой
Сообщений: 1 032
Регистрация: 13-03-08
Из: Маськва
Пользователь №: 35 877

|
Цитата(poganoe_lamerishe @ Oct 2 2012, 03:51)  Проще всего, разумеется, ничего не читать вообще Универсальный совет :-D Самая простая и тупая доработка: Код // было LPC_GPIO1->FIOPIN |= (1<<14 | 1<<15); LPC_GPIO1->FIOPIN &= ~(1<<16 | 1<<17);
// стало int tmp; tmp = LPC_GPIO1->FIOPIN; tmp |= (1<<14 | 1<<15); tmp &= ~(1<<16 | 1<<17); LPC_GPIO1->FIOPIN = tmp; При желании (в ущерб удобочитаемости) можно переписать в одну строку. Ну и поддержу более правильные советы - использовать регистры SET / CLR.
--------------------
Тут обсуждается творческий порыв, а не соответствие каким-либо стандартам ©
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|