LINUX.ORG.RU
ФорумMobile

Вторая жизнь HP iPaq 214

 , , , ,


0

3

Решил закрыть старый гештальд и собрать образ для сия детища от HP. Благо документации навалом, даташиты, в большинстве своём, опубликовали. От тогоже Oliford'а и парней которые портируют(али) Android (Не уверен что оно ещё живо).

Ковыря исходники U-Boot совместно с даташитами и смахивая скупые слёзы, поймал себя на мысли, что сюда весьма неплохо вписываются современные С++17 с его constexpr и повсеместным использованием ссылок, т.к. память на старте не инициализированна, да и никаких аллокаторов у нас нет, посему ограничимся стэком. Немного помучавшись, получился такой интерфейс для моргания диодами через GPIO:

void start(void) {
 PXA310 cpu;
 cpu.gpio[5].direction = out;
 cpu.gpio[5].value = hi;
}

Что скажите за такой подход в целом?

★★

Ответ на: комментарий от RazrFalcon

Их как грязи на рынке, я новый в открытой коробке за 10 евро купил. Апарат весьма интересный, да и начинка весьма неплоха, имхо тогда ХПшники не смогли раскрыть потенциал чипа нормально на винмобле, а вот все болячки винды притащили

sparks ★★ ()

Если у тебя используется та самая идиома, которая позволяет вокруг операторов вызывать служебный код на основе raii - то да. Блин не могу вспомнить как оно зовётся, ну это, типа когда по operator [] возвращает rvalue которое в конструкторе/деструкторе например лочит мутех, и имеет оператор приведения на ссылку сутевого типа(честно сходу как с точкой сделать я х3, гораздо проще всё с operator -> и operator*). Иначе, если ты локаешь весь cpu - это слегка не комильфо.

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от pon4ik

чёта нее до конца понял, у меня тут по operator[] возвращяется инстанс класса описывающий интерфейсы пина по ссылке.

Marwell pxa используют 4 набора регистров для управления 128 GPIO, и тут по сути мапинг происходит, для замены вот такого стиля на более читабельный:

_REG(0x40ff0010) |= 0x28;
sparks ★★ ()
Последнее исправление: sparks (всего исправлений: 2)
Ответ на: комментарий от sparks

Эмм, ну я примерно про такое(не компилил):


void report(std::string&& r) {
   cout << r << std::endl;
}

struct Resource {
 void process() { report("I'm resourcE");}
};

struct Holder {
    Resource& r_;
    Holder(Resource& r) : r_(r) {  report("Begin hold resource");}
    ~Holder() { report("End hold resource");}

    Resource* operator->() { return &resource;}
}

struct ResourceStorage {
//...
  Holder operator[] (size_t i) { return Holder(real_storage[i]);}
//...
};

//...
 ResourceStorage storage;
 storage[0]->process();
//...

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

жуть какая, ты его специально запутывал?)) Я примерно понял о чем ты && и тд, да я этим пользуюсь. Т.к. пишу загрузчик/инициализатор то всё собирается с ключём -nostdlib, тут нет ни new, мьютексов, ничего))) Даже start пришлось объявить в extern «C» чтобы манглинг не лез и линковщик с ума не сходил.

походу надо нормальное описание в шапку закинуть

sparks ★★ ()
Последнее исправление: sparks (всего исправлений: 1)
Ответ на: комментарий от sparks

Я если честно - х3 как в этом вашем эмбедед устроенна синхронизация, но направление пина и значения на нём по идее должны атомарно задаваться? Чисто наивное предположение, ибо как оно на самом деле, я на 100% не знаю.

В случае диодов это наверное не роляет, а вот в случае привода ногоотрубательной машинки таки может.

_REG(0x40ff0010) |= 0x28; - это чисто теоретически вполне может быть атомарно, т.к. оба бита ты выставляешь разом, вопрос какова модель памяти.

А твой подход - говорит ‘это был вход, но ты сделай выход потупи такт, потом таки выстави туда напряжение’. За этот такт может кому-то ногу отрубить.

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

pon4ik ★★★★★ ()
Ответ на: комментарий от sparks

Я примерно понял о чем ты && и тд, да я этим пользуюсь тут нет ни new, мьютексов, ничего

Наверное всё же не понял :) Rvalue ссылка, это рука сама написала, косточка в порядке вызовов report, если этот код дописать до конпилябельного состояния.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Я не эмбедед, так мимокрокодил. Кароче смотри, есть регистры для управления GPIO, по неким адресам:

  • 0x40ff0000 - Каждый бит задаёт направление пина 0-31
  • 0x40ff0010 - Тут каждый бит соответствует текущему значению пина 0-31
  • 0x40ff0020 - Тут каждый бит позволяет установить значение на пинах
  • 0x40ff0030 - Каждый записанный сюда бит установит значение соотвествующего пина в 0
  • На этом веселье не заканчивается

Часть пинов MultiFunctional, т.е. надо решить какой функционал они будут исполнять.

Если всё делать по «классике», то будет

volatile void *GPIO_Direction = 0x40ff0000;
volatile void *GPIO_SetValue = 0x40ff0020;
*GPIO_Direction |= 0x88;
*GPIO_SetValue |= 0x99;

UBoot да и Linux заворачивают это всё в несколько слоёв препроцессора, читать и править тяжело, я и решил попробовать что то более человекопонимаемое сделать.

Насчет атомарности операций я не уверен, в даташитах написано что писать в gpio в режиме input безопасно, да и ковыряние gpio происходит в начальной инициализации и индикации, всё остальное заворачивается в нормальные протоколы ssp/spi и тд. которые создаются на конкретных gpio.

В этом как бэ и идея, формирования иерархии

cpu->gpio->(*ssp* LCD)

Да, это голимый сахар, но если он создаёт оверхед близкий к 0, то чёб нет?

sparks ★★ ()
Ответ на: комментарий от sparks

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

pon4ik ★★★★★ ()
Ответ на: комментарий от sparks

Linux заворачивают это всё в несколько слоёв препроцессора

И не без основания

anonymous ()
Ответ на: комментарий от t184256

В чём собсно противоречие? Порт 10ти летней давности писался в отсутсвии даташитов, доступных сейчас, не используя подход с dts, и застрял в 2009 с наработками не пошедшими в мейнлайн иии увы знаний пока хватает ток на светодиоды, имхо если передать управление ядру на правильно сконфигурированному SoC, mainline должен запуститься без особых косяков, что и является конечной целью

sparks ★★ ()
Последнее исправление: sparks (всего исправлений: 1)
Ответ на: комментарий от sparks

Ну, это один из первых придуманных механизмов синхронизации, правда на уровне электрических сигналов оно скорее работает, что бы помехи не давали неоднозначности при замере.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Я к тому что ты видимо не совсем правильно понимаешь кухню армов

sparks ★★ ()
Ответ на: комментарий от pon4ik

Я понял о чем ты!!! Да, там действительно нужна атомарность. Но, насколько я знаю, так редко приходится делать, SoC внутрях уже всё это имеет, ты просто помечаешь MultiFunctionl pin'ы где будет cls, где условный d0 и там юзаешь готовый интерфейс, т.е. тот же spi для чтения sd карты как бэ и не надо реализовывать

sparks ★★ ()
Ответ на: комментарий от pon4ik

Смотри что пишут по поводу контроля пинов:

Each register operation can occur in a slightly unpredictable order, non-obvious re-ordering of completion being possible.
A completion can be checked only by performing a Read operation.
Software should not assume that pins are programmed in exactly the order of issue.

Т.е. как бэ никто ничего не гарантирует))

sparks ★★ ()
Ответ на: комментарий от sparks

Та, для этого в протоколах имеются таймауты и прочие тики, а так же всякие механизмы исправления ошибок…

Т.е. шлёшь например пакеты по 12бит и 4 ре из них это контрольная сумма, а ещё 4ре - порядковый номер.

pon4ik ★★★★★ ()
Ответ на: комментарий от sparks

Это очень вряд ли. Нафик он тогда нужен этот gpio…

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Блин не могу вспомнить как оно зовётся, ну это, типа когда по operator [] возвращает rvalue которое в конструкторе/деструкторе например лочит мутех

Execute-Around Pointer

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.