Завязка:
К отладочной плате olymex была варварски припаяна (так как свободно-торчащих пинов на плате нет) самодельная светодиодная матрица 2х2 (схему матрицы могу приложить, если нужно).
Какое-то время мой код для работы с этой матрицей работал без нареканий, а потом в один прекрасный момент я решил поднять частоту процессора (заюзав PLL) до 100 МГц. Светодиоды гореть перестали.
Это явление было не очень стабильным, на разных частотах код вел себя по-разному и не всегда одинаково.

На четвертый день разборок бажный код редуцировался до вот такого фрагмента, который должен выключать все светодиоды. В таком виде код работает.:

А вот в таком - нет. PLL в обоих случаях отключен, проц тактируется от внутренней цепочки на 4Мгц.


При пошаговой отладке работают оба варианта. Если вот этот момент

не делать (или вставить задержку в пару тактов между этими строчками), то все работает. Т.е., насколько я понимаю, значение в регистре толи меняется, толи считывается недостаточно быстро.

Вопрос: прав ли я или проблема может быть в чем-то другом? Если я прав, где в даташите это описано или как это вообще гуглить, что делать? <_>

А почему бы не заюзать FIOSET/FIOCLR, удобней же (на мой взгляд)?


И 3 последние строчки

tempPin = LPC_GPIO1->FIOPIN;
mask = (1<<16 | 1<<17);
tempPin &= ~mask;

вроде вообще не нужны? что они делают?

Таки да, FIOSET/FIOCLR заюзать можно и работают они корректно. Просто я к портам по указателям обращаюсь и так пришлось бы хранить два указателя, вместо одного. К тому же FIOPIN должен работать точно так же

Три последние строчки - это запись нулей в 16 и 17 бит, то же самое, что FIOPIN &= ~(1<<16 | 1<<17); чтобы выключить столбцы матрицы.

Это три инструкции: считать, наложить маску, записать. Set/Clr - одна. У кортекса можно вообще обращаться через битовую память.

А причина такого поведения может быть, если между read/set другой процесс также ставит свои биты в порте. Попробуйте прерывания запретить.

В первом варианте Вы записываете нули в 16-й и 17-й биты LPC_GPIO1->FIOPIN, а во втором - в 16-й и 17-й биты переменной tempPin.
Записи переменной tempPin в LPC_GPIO1->FIOPIN в приведенном Вами фрагменте кода нет (точнее, оно производится до обнуления 16-го и 17-го битов).
Таким образом, приведенные Вами фрагменты кода не эквивалентны.

По поводу
Я не знаком именно с LPC, но в некоторых контроллерах такой код, действительно, может прочитать старое (еще не измененное) состояние ног. Если для LPC это справедливо - то в данном фрагменте у Вас race condition, чем и объясняется зависимость результата от частоты.

Да зачем два? Адрес FIOnCLR = Адрес FIOnSET + 4

Да, пропустил последнюю строчку, где LPC_GPIO1->FIOPIN = tempPin еще раз. Невнимательный стал.



Ну я подозреваю, что так и происходит, только в даташите или юзер-мануале ничего подобного не увидел. Может быть такое поведение и нормально, только вот как я о нем догадаться был должен?



Прерывания, разумеется, запрещены.



А так получается платформозависимо Но, вообще, сейчас мне пришло в голову, что идеально было бы юзать bit-banding. Тогда пришлось бы хранить только один указатель, а сейчас - указатель и маску. Ладно, это потом как-нибудь. -_-

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

Такое поведение (когда запись на выход может в следующем такте не прочитаться со входа) — так это запросто. Вот из документации на AVR ATmega8
У AVR эта задержка гарантирована и фиксирована, а у LPC могло на низких частотах успевать «аналоговые» задержки (в буферах) до следующего такта выбрать, а на высоких — нет и появилась дополнительная задержка. И NOP не поможет, он растворится между двумя командами обращения к шине периферии.

По хорошему, если нужно узнать, что мы вівели в порт (а не что на него пришло снаружи), то читать надо FIOSET (текущее значение регистра выхода), это не будет зависеть ни от задержки выходного буфера от регистра до ножки, ни от задержки входного буфера и подсинхронизации после него, что всё вместе влияет на прохождение сигнала до FIOPIN.

А передавать надо один указатель на порт (структуру порта), а там уже
port->FIOPIN = port->FIOSET & ~mask;
если по какой-то причине не хочется писать
port->FIOCLR = mask;

Звучит правдоподобно, но вот отсутствие (или моя неспособность найти) этой информации в даташите меня угнетает. Если уж вставлять задержки, то надо знать, сколько. Шаманить-то не хочется.

Структура порта да, как вариант.

Проще всего, разумеется, ничего не читать вообще, а только писать в FIOSET и в FIOCLR, не трогая FIOPIN.

Последние три слова подтверждают то, что при чтении этого регистра подразумевается именно считывание физического состояния цифрового порта. В независимости от того, настроен порт на вход или на выход.
Читаем дальше.

Запись в этот порт имеет смысл только для пинов настроенных на выход.

А теперь самое интересное:

Вот этот регистр уже отражает именно внутреннее состояние порта (состояние выходного драйвера) на вывод.
Таким образом ваш код должен был иметь вид:

Таким образом не будет никакой "аналоговой" обратной связи по физическому уровню на пине порта.


P.S.
В начале работы с LPC сам столкнулся с такой фичей.
Это побудило просто внимательно перечитать документацию. После прочтения становится всё очевидно.

Универсальный совет :-D

Самая простая и тупая доработка:

При желании (в ущерб удобочитаемости) можно переписать в одну строку.

Ну и поддержу более правильные советы - использовать регистры SET / CLR.

Предлагаю Вам для начала посмотреть, на какой частоте у Вас работает GPIO. Может следует её поднять? Не знаю пределов, но у меня при F ядра 100 МГц и F GPIO 25 МГц всё везде успевает, даже в скоростных шинных обменах, когда PINы SETы и CLRы следуют один за другим в разных вариациях.

Предлагаю Вам для начала посмотреть, правильно ли происходит процедура инициализации частот ядра и т.п. Выложите сюда.

Если не поможет, предлагаю попробовать отключить акселератор FLASH памяти (FLASHCFG_bit.FLASHTIM)

Если и это не поможет, посмотрите настройки компилятора. Какой компилятор? Какие настройки оптимизации? Попробуйте полностью отключить оптимизацию. У меня при включенной оптимизации компилятор выдавал те ещё конструкции! Вот после такого у меня ничего не работало!

Это из серии вредных советов?

Нет, это из серии "понятия не имею о познаниях ТС".

Видимо я как-то неверно понял документацию или читал невнимательно. Спасибо вам большое!



Собственно, я в первом посте писал, что в начале так и было и тоже не очень стабильно работало




Собственно, частоту ядра я выводил на ногу и осциллографом проверял, вроде все правильно было.
С акселератором тоже игрался (его, вроде как, вообще отключить нельзя) - на любых настройках поведение было одинаковым.
Оптимизация -O0, компилятор кейловский.

Но я таки полагаю, что Petka прав.

Тут уже пошла серия совсем не про топикстартера. Это серия про шаманские танцы.



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



С этим полностью согласен.