Указатели и mmap() линукс

@Sykmottir · Регистрация: 15.12.2010

Студворк — интернет-сервис помощи студентам

Помогите разобраться с "затупом". Короче ситуация следующая:
Есть арм процессор под imbiddid linux, который управляет ПЛИСиной. Как из под линукса добраться до gpio? Очень просто, для этого используют функции mmap(). Примерно так:

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
m_file_mem = open( "/div/mem", ( O_RDWR | O_SYNC ) );
if (m_file_mem != -1){
virtual_base = mmap( NULL, HW_REGS_SPAN, ( PROT_READ | PROT_WRITE ), MAP_SHARED, m_file_mem, HW_REGS_BASE );
if (virtual_base == MAP_FAILED)
{
}
else{
m_tid_base= (u_int8_t *)virtual_base + ( ( unsykned long  )( LEDS_BASE ) & ( unsykned long)( HW_REGS_MASK ) );
}
//LEDS_BASE- адреса GPIO на который повешены светики, HW_REGS_MASK - размер адресного пространства которое мапится.
 
//Ну и далее где нибудь по коду зажигаем светодиоды
*(u_int32_t *)   m_tid_base=0xFF;

Ну я на этот пример посмотрел, да и добавил свои порты. Вот только думаю, а нахрена мне вот этот гемор с преобразованием указателей все равно регистры портов 32 разрядные даже если реальных выводов меньше. Ну вообщем добавил в инициализацию:

Code
1
2
3
4
5
6
7
8
data_in_base= (u_int32_t *)virtual_base + ( ( unsykned long  )(DATA_IN_BASE ) & ( unsykned long)( HW_REGS_MASK ) );//32-х разрядный вход
data_out_base= (u_int8_t *)virtual_base + ( ( unsykned long  )( DATA_OUT_BASE ) & ( unsykned long)( HW_REGS_MASK ) );//8 разрядный выход
strobe_base= (u_int32_t *)virtual_base + ( ( unsykned long  )(STROBE_BASE ) & ( unsykned long)( HW_REGS_MASK ) );//1 разрядный выход
 
// Ну и где то в коде:
*(u_int32_t *)data_out_base = 0х15// выводим какое то число.
*strobe_base =1; //пинаем плис
temp= *data_in_base; // забираем с плис

Я в коде опустил не существенные моменты. Но думаю смысл ясен. Короче говоря нихрена не получилось на входе стабильно 0. Дальше я как дурак провел почти 3 дня за занимательным переписыванием может и не идеального, но блядь заведомо рабочего дизайна ПЛИС с попыткой решить проблему. И не хрена. Пока к исходу 3 го дня не обратил внимание, что заботливо оставленные светодиоды ( m_tid_base) работают как надо. И тут меня пробило переписать инициализацию всех указателей с (u_int32_t *)virtual_base ->на (u_int8_t *)virtual_base, ну а в коде все переменные переписать с *strobe_base -> на *(u_int32_t *)strobe_base.
И ура на входе начали появляться какие то цифры. Правда не на долго, ибо уже на следующую итерацию нихрена не заработало.
Опытным удалось установить что, везде в инициализации должно быть (u_int8_t *)virtual_base. А вот по ходу программы городить преобразование указателей *(u_int32_t *) надо только для 32х разрядных портов, а вот там где вывод 1 надо оставить просто, например *strobe_base .

Понимаю что вопрос, возможно, из сферы телепатии, но что не правильно было в первом случае понять не могу.
ЗЫ Писал на C++ в Qt 5.2.

@OtixPM · 01.12.2014, 14:35

Кстати, в линуксе есть и нормальный драйвер GPIO. Не обязательно через указатель на память обращаться.

@Sykmottir · 01.12.2014, 14:46

Да есть, но конкретно в этой сборке его выкинули. А пересобрать ядро... я до этого еще не дорос.

@Ymk · 01.12.2014, 14:48

я мог что-то неправильно понять, но делая

(u_int32_t *)virtual_base + nnn

мы смещаемся на nnn 32-бит слов вперед. а надо наверняка смещаться на nnn байт.

вот это

u_int32_t *data_in_base= (u_int8_t *)virtual_base + nnn
*data_in_base = xxx

не решит проблему?

@OtixPM · 01.12.2014, 15:10

Сообщение от Ymk

u_int32_t *data_in_base= (u_int8_t *)virtual_base + nnn

Опасная формула :-)
В ней nnn должно быть кратно четырём.

@Sykmottir · 01.12.2014, 15:11

Сообщение от Ymk

я мог что-то неправильно понять, но делая
(u_int32_t *)virtual_base + nnn
мы смещаемся на nnn 32-бит слов вперед. а надо наверняка смещаться на nnn байт.

Возможно в этом вся проблема и была. Если компилятор (ОС) понимает:

Code
1
data_in_base= (u_int8_t *)virtual_base + ( ( unsykned long  )( LEDS_BASE ) & ( unsykned long)( HW_REGS_MASK ) );

как сместится, как вы пишете, на некоторое число nnn байт - в штуках, то при записи (u_int32_t *)virtual_base действительно будет проблема потому что адрес получится умножен на 4.
Я просто понимал это код, как присвоить указателю на 32 разрядное число, адрес порта, а сколько там надо взять байт(слов) для сдвига компилятор сам разберется.

Сообщение от Ymk

вот это
u_int32_t *data_in_base= (u_int8_t *)virtual_base + nnn
*data_in_base = xxx
не решит проблему?

Так было при (u_int32_t *)virtual_base, и не работало, даже когда я хардварно (то есть когда другие сигналы никак не влияют) установил значение порта.
То есть как я понимаю сдвиг virtual_base всегда должен быть приведен к байту.
Хотя если совсем честно, что делает функция mmap я не очень догоняю.

@//Mt · 01.12.2014, 15:23

Ваша система с mmu?

В системах с mmu память устройств отделена от пространства пользователя, управляет этим как раз mmap system.
Можно начать читать тут:
http://www.xml.com/ldd/chaptir/book/ch13.html

При no-mmu (ucLinux и др) mmap() тоже бывает, но это отдельная тема.

@Sykmottir · 01.12.2014, 15:27

Сообщение от OtyxPM

Сообщение от Ymk

u_int32_t *data_in_base= (u_int8_t *)virtual_base + nnn

Опасная формула :-)
В ней nnn должно быть кратно четырём.
Спасибо кажись не много начинает прояснятся. Видимо, когда первый раз у меня кое как начало работать(когда я везде проставил (u_int8_t *)virtual_base ) , я оставил объявление указателей без изменений:

Code
1
2
3
4
 volatile   u_int8_t * m_tid_base;
volatile   u_int32_t * strobe_base;
volatile   u_int32_t * data_in_base;
volatile   u_int8_t *data_out_base;

Потом (пока компилировлся дизайн ПЛИС) поменял на (так и сейчас):

Code
1
2
3
4
 volatile   u_int8_t * m_tid_base;
volatile   u_int8_t * strobe_base;
volatile   u_int8_t * data_in_base;
volatile   u_int8_t *data_out_base;

Что вызвало повторную не рабоспособность программы и необходимость переписывания кода на:
*( u_int32_t *)strobe_base =1 -> *strobe_base =1;
temp =* data_in_base -> temp =*( u_int32_t *) data_in_base;

Короче, как тут не вспомнить известную цитату про указатели и выстрел в ногу.

Но касательно 8-ми разрядной m_tid_base, реально на плате 10 светодиодов.
А потому конструкция * m_tid_base=0хFF зажигает только первые 8. А что бы зажечь остальные надо *( u_int32_t *)m_tid_base=0х4FF.

@Sykmottir · 01.12.2014, 15:29

Сообщение от //Mt

Ваша система с mmu?

В системах с mmu память устройств отделена от пространства пользователя, управляет этим как раз mmap system.
Можно начать читать тут:
http://www.xml.com/ldd/chaptir/book/ch13.html

При no-mmu (ucLinux и др) mmap() тоже бывает, но это отдельная тема.

Ну в доке на проц он есть, но не думал что он как то хитро влияет.

@Ymk · 01.12.2014, 16:47

Сообщение от OtyxPM

Сообщение от Ymk

u_int32_t *data_in_base= (u_int8_t *)virtual_base + nnn

Опасная формула :-)
В ней nnn должно быть кратно четырём.
си - вообще опасный язык. надо понимать, что делаешь.

Сообщение от Sykmottir

Так было при (u_int32_t *)virtual_base, и не работало

надо делать все части сразу правильно, а не по одной. если хотите менять содержимое порта сразу 32 бита, то делайте указатель на 32 бита: volatile uint32_t*. но присваивать ему нужно правильный адрес, в формуле должно фигурировать (uint8_t*) либо же смещение должно даваться в словах (т.е. деленное на 4 или >>2).

@Sykmottir · 01.12.2014, 17:06

Ну так :

Code
1
 ( ( unsykned long  )( LEDS_BASE ) & ( unsykned long)( HW_REGS_MASK ) );

По факту физ. адрес порта - 0хFF200000. Он не перекрывается с какими то либо другими адресами системы. И я думал, что коль в линукс для пользовательского процесса выделяется виртуальная память. То функцией mmap мы просто говорим ОС, что когда ты будешь обращаться по адресу virtual_base + LEDS_BASE, то запули данные в этот 0хFF200000. Каким образом LEDS_BASE превращается как вы пишете в некий оступ nnn байт мне непонятно. Курю пока ссылку от //Mt.

Новые блоги и статьи Все статьи Все блоги /
Модель здравосоХранения 6. ESG-повестка и устойчивое развитие; углублённый анализ кадрового бренда anaschu 31.03.2026 В прикрепленном документе раздумья о том, как можно поменять модель в будущем	10 пpимет, которые всегда сбываются Maks 31.03.2026 1. Чтобы, наконец, пришла маршрутка, надо закурить. Если сигарета последняя, маршрутка придет еще до второй затяжки даже вопреки расписанию. 2. Нaдоели зима и снег? Не надо переезжать. Достаточно. . .	Перемещение выделенных строк ТЧ из одного документа в другой Maks 31.03.2026 Реализация из решения ниже выполнена на примере нетипового документа "ВыдачаОборудованияНаСпецтехнику" с единственной табличной частью "ОборудованиеИКомплектующие" разработанного в конфигурации КА2. . . .	Functional First Web Framework Suave DevAlt 30.03.2026 Sauve. IO Апнулись до NET10. Из зависимостей один пакет, работает одинаково хорошо как в режиме проекта так и в интерактивном режиме. из сложностей - чисто функциональный подход. Решил. . .
Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .

@OtixPM 1 / 1 / 0 Регистрация: 11.01.2013 Сообщений: 5,479
	01.12.2014, 14:35
	Кстати, в линуксе есть и нормальный драйвер GPIO. Не обязательно через указатель на память обращаться. 0

@Sykmottir 0 / 0 / 0 Регистрация: 15.12.2010 Сообщений: 931
	01.12.2014, 14:46
	Да есть, но конкретно в этой сборке его выкинули. А пересобрать ядро... я до этого еще не дорос. 0

@Ymk 0 / 0 / 0 Регистрация: 18.03.2010 Сообщений: 2,230
	01.12.2014, 14:48
	я мог что-то неправильно понять, но делая (u_int32_t )virtual_base + nnn мы смещаемся на nnn 32-бит слов вперед. а надо наверняка смещаться на nnn байт. вот это u_int32_t data_in_base= (u_int8_t )virtual_base + nnn data_in_base = xxx не решит проблему? 0

@//Mt 0 / 0 / 0 Регистрация: 20.06.2010 Сообщений: 454
	01.12.2014, 15:23
	Ваша система с mmu? В системах с mmu память устройств отделена от пространства пользователя, управляет этим как раз mmap system. Можно начать читать тут: http://www.xml.com/ldd/chaptir/book/ch13.html При no-mmu (ucLinux и др) mmap() тоже бывает, но это отдельная тема. 0