Форум разработчиков электроники ELECTRONIX.ru > Как писать на С++ при создание приложений под ARM

Помощь - Поиск - Пользователи - Календарь

Полная версия этой страницы: Как писать на С++ при создание приложений под ARM

Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM

Страницы: 1, 2, 3, 4

brag

Jun 19 2012, 22:38

PoР - это что такое, просветите плиз..гугл выдает совсем не то

про "кишащий багами софт" я так немного утрируя написал, но,блин, я на эти крайне редкие баги попадаю не совсем крайне редко

)

про драйвер - да, из личного опыта. хоть то була не Linux, a FreeBSD, был LPT-порт и нужно его было запахать в режиме DMA со спецефической приблудой на другом конце порта и спецефическим алгоритмом(часть на уровне драйвера, часть уже на софте) - так помнится я тогда запарился на 1.5 месяца точно, хотя такая же задача на МК делается за пару-тройку дней.
под винду еще сложнее(интерфейс у них сложный), пишу иногда дрова под свои приблуды на USB. мож из за привычки к голому железу, хз.. но тут уж выбора нету

про время освоения: возьмем простую задачу - сделать какой-нибудь умный терморегулятор,многоканальный пусть будет(ну или там какой-то источник питания управляемый умный, что кому по вкусу) с маленьким дисплейчиком и несколькими кнопочками. Задача чисто на алгоритмы и вышку, остальное дело одного дня если с нуля. Ну во первых как-то рука не поднимется пихать тяжеловес на такую финтиклюшечку, а во вторых запахать тайм-критические алгоритмы на ос с неизвестными внутренностями будет однозначно дольше. ну и сложная 4-слойная плата + дубовые силовые ключи в ТО-247 как-то не очень клеится

AVR

Jun 19 2012, 22:52

Цитата(brag @ Jun 20 2012, 02:38)

PoР - это что такое, просветите плиз..гугл выдает совсем не то

тортик

у меня на столе лежит две платы где память DDR2 на проц именно таким способом напаяна и никаких проблем с разводкой разумеется

Цитата

про драйвер - да, из личного опыта. хоть то була не Linux, a FreeBSD

ааа... BSD, всё ясно, у Linux-а то более простые драйверы в плане написания, причем для упрощения и унификации нередко могут ядро перепахать от и до, да и литературы больше - вот у меня в подписи - бесплатные обучающие слайды

там вообще по всем подсистемам, например PCI или USB - разжевано досконально, а иди попробуй на голом железе USB-host драйвера написать или адаптировать демку от разработчиков - реально тяжелее

у windows конечно вообще жуть дрова писать - приходилось знакомиться с сим процессом

Цитата

возьмем простую задачу

не, ну такие простые задачи мы не рассматриваем, там действительно проще самому напахать на голом железе

brag

Jun 20 2012, 01:14

та все так, согласен.. а простые задачи рассматриваем тк там тоже уместен C++ и много чего другого

sasamy

Jun 20 2012, 05:48

Цитата(brag @ Jun 20 2012, 02:38)

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

проще купить готовые китайские - намного дешевле и быстрей будет, а то пока вы С++ выучите ждать не охота

KRS

Jun 20 2012, 06:38

AVR,
а вам встречались industrial варианты PoP?

dxp

Jun 20 2012, 06:40

QUOTE (AVR @ Jun 20 2012, 03:34)

не совсем понял, это скорее намек или вопрос? я полагаю что энергопотребление при работе Linux и Qt будет несколько выше

Это вопрос. Неспешно оцениваем возможность применения толстой платформы для закрытия таких мест, как GUI (на Qt поприятнее это делать, нежели голом железе), работа с флешь накопителями и прочее. Но вопрос энергопотребления стоит довольно жестко, поэтому вопрос не праздный.

QUOTE (AVR @ Jun 20 2012, 03:34)

я сравнивал официальные отчеты от Ti для OMAP3 - при максимальной нагрузке - разницы между потреблением с ОС и без нее - не нашел, при отсутствии нагрузки - да, у Linux было процентов на 15 выше, не более

Интересно было бы узнать в мВт.

QUOTE (AVR @ Jun 20 2012, 03:34)

да и сама ОС Linux жрет скорее оперативку, чем процессор - что приятно

Это радует.

QUOTE (AVR @ Jun 20 2012, 03:34)

P.S.
понимаю какое отвращение могут вызвать мои слова у профессионалов, пишущих на голом железе для экономии энергии, но мне-то хорошо - ценой некоторого потребления и стоимость DDR2 - получаю платформу для легкой и быстрой разработки

Никакого отвращения - все средства хороши к месту. Ресурсы и дальше будут расти и дешеветь, а время, затрачиваемое на разработку и поддержку, наоборот уменьшаться (количество задач растёт) и дорожать. Целесообразность рулит, а рассуждения "тру (Ъ) - не тру" - досужее.

brag

Jun 20 2012, 09:44

Цитата

Интересно было бы узнать в мВт.

при выполнении реального приложения, а не тупого висения голой ОС в спячке.

Цитата

Это радует.

любая ос такой должна быть

Цитата

проще купить готовые китайские - намного дешевле и быстрей будет, а то пока вы С++ выучите ждать не охота

если возможность есть, то однозначно проще.

AVR

Jun 20 2012, 10:53

Цитата(dxp @ Jun 20 2012, 10:40)

по этой ссылке есть оценки потребления для AM335x Cortex-A8) подробно в мВт - я так понимаю что AM335X родственник OMAP3 но без DSP ядра, но зато с 3D, типа Freescale iMX (да, кстати, как OpenGL-то без полновесной ОС юзать?

)
+ есть платка для оценки этого проца - это опенсорсный проект (так что тут никакой рекламы), есть исходники чертежа платы и всего прочего

No OS : DDR Access = 455.31 mWt
No OS : Static Image Display = 419.36 mWt
Linux PSP : No application running after boot = 486.51 mWt

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

дабы не сочли рекламой Ti, могу сказать что эти оценки можно смело применить для многих других ARM различных происзводителей и к Atmel и прочим

равно как и обучающие материалы у меня в подписи - распространяются под лицензией Creative Commons Attribution-ShareAlike 3.0, т.е. свободные бесплатные материалы, где все доходчиво и досконально разжевано

ЗЫ
пиарю за идею, просто нравится ОС Linux

nicks80

Jun 20 2012, 11:30

Цитата(andrewlekar @ Jun 22 2011, 08:57)

Расказ про ООП конечно увлекательный, но стоит учитывать, что как только вы вылезете за область применения, описанную dxp (наследование от интерфейса и поточная обработка), то тут же вся система станет крайне неустойчивой. Конкретно: множественное наследование сразу ставит крест на проекте, перегрузка функций и операторов приводит к очень хитрым багам, развесистая иерархия наследования приводит к хрупкости системы - очень высокая связность элементов... Использование паттернов не имеет отношения к С++, но в микроконтроллерах не имеет особого смысла. Куда можно в AVR засунуть синглтон?! Использование шаблонов С++ сильно тормозит компиляцию и плохо контролируется по расходу памяти.
В общем, это неправда, что С++ оправдан везде, где оправдан С.

Точно и сразу зарплата этого программиста вырастает ).
Задача всегда такая. Как сделать быстро, качественно, надежно, поддерживаемо и дешево. И ОПП впишется наверно в единичные случаи без MMU.

Axel

Jun 20 2012, 11:53

Цитата(AVR @ Jun 20 2012, 13:53)

No OS : DDR Access = 455.31 mWt
No OS : Static Image Display = 419.36 mWt
Linux PSP : No application running after boot = 486.51 mWt

А если "No OS" и "No DDR" то сразу на 200mWt меньше...

sasamy

Jun 20 2012, 13:10

Цитата(Axel @ Jun 20 2012, 15:53)

А если "No OS" и "No DDR" то сразу на 200mWt меньше...

То что реализовано даже в базовом образе того же андроида вы и ваша фирма не реализуете за всю жизнь - так что милливатты хоть и играют роль но стоят где-то на последнем месте в современном мире

пусть чипмейкеры заботятся о милливаттах.

AVR

Jun 20 2012, 15:28

Цитата(Axel @ Jun 20 2012, 15:53)

А если "No OS" и "No DDR" то сразу на 200mWt меньше...

откуда вязалсь цифра на 200 mWt меньше? это есть по моей ссылке или это Ваши измерения?

Axel

Jun 21 2012, 02:25

Цитата(AVR @ Jun 20 2012, 18:28)

откуда вязалсь цифра на 200 mWt меньше? это есть по моей ссылке или это Ваши измерения?

Из datasheet-ов на DDR чипы и собственных измерений - сопоставлял потребление EVB, на которых DDR память была и своих устройств, где ее не было.

brag

Jun 21 2012, 09:47

Цитата

И ОПП впишется наверно в единичные случаи без MMU.

идет на ура даже на avr. после некоторого времени на освоение и наработки библиотек процесс проектирования стал проще, быстрее и интереснее. скорость добавления новых фич возрасла раз в 3-10. Еще руки не дошли ось переписать на c++, тогда еще вкуснее станет

brag

Jul 5 2012, 00:34

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

CODE

class CdllNode{
public:
	void Enqueue(CdllNode *node);
	...
private:
	CdllNode *next;
	CdllNode *prev;
};

class SomeClass{
public:
	virtual void someMethod();
private:
	CdllNode n1;
	CdllNode n2;
	CdllNode n3;
};

CdllNode queue1;
CdllNode queue2;
CdllNode queue3;
SomeClass someobj;

void f(){
	queue1.Enqueue(&someobj.n1);
	queue2.Enqueue(&someobj.n2);
	queue3.Enqueue(&someobj.n3);
}

Адресоватся в итоге нужно как-то так просто

Код

void f1(){
SomeClass *body=queue2.next;
body->someMethod();
}

Пока работает на offsetof(), но это не безопасно и вообще запрещено стандартом для nonPOD-классов (хотя именно такая реализация на данный момент работает).
Добавлять в класс CdllNode указатель на обьект SomeClass'а не конает - embedded,мало памяти,все дела.. так же, как и использование множественного виртуального наследования. тоесть должно быть максимум оптимизировано по быстродействию и обьему оперативной памяти.

neiver

Jul 5 2012, 12:29

А может эти списки реализовать как массивы указателей, типа ArrayList? Расход памяти будет меньше. Поиск будет быстрее, удаление из середины можно сделать посредствам записи нуля в соответствующий указатель. Если нужно много добавлять-удалять в конец и начало - можно на кольцевом буфере сделать - тоже очень быстро. Вставка в середину будет медленнее.
Так для чего нужны эти списки? Может и не надо на двухсвязных узлах их делать?

brag

Jul 5 2012, 13:42

Ну пока были задачи такого плана:
Добвалять нужно в конец списка. Удалять как с начала так и с середины.
Массивы не подходят, тк код обычно библиотечный(и зачастую прекомпиленный) - юзеру передоставлять библиотеке кучу хранилищ для этих массивов и везде уследить за размером будет гемор жуткий. В виде двусвязанных списков все становится самоорганизованно - в либе выделяется несколько голов списков(фиксировано) а юзер может создавать сколько угодно обьектов и передавать ссылки библиотеке.

neiver

Jul 5 2012, 14:43

В таком случае всё-таки лучше укзатель на объект в CdllNode положить. Реализация с offsetof() очень шатка. Добавится (или удалистя) в SomeClass еще одно поле и прекомпиленная библиотека сломается.
А хранилище под эти очереди можно и пользователя попросить выделить, где и сколько ему нужно.

brag

Jul 5 2012, 15:41

Указатель - эт костыль по сути, тк он всегда будет равен адресу CdllNode-какое-то смещение, + 1 слово памяти + пару тактов на чтение.
offsetof согласен, опасная штука.
В случаи с предоставлением хранилищ - юзер может и не уследить за размером либо делать проверку на рантайме, что тож не хотелось бы.
Пока наколбасил такое

CODE

template<class T> class Cdll : private NonCopyable{
public:
	explicit Cdll(const T*){ Reset(); }
	
	void Reset(){
		next=prev=static_cast<T*>(this);
	}
	
	void Enqueue(T *node){ // Insert at the Tail
		node->next=static_cast<T*>(this);
		node->prev=prev;
		prev->next=node;
		prev=node;
	}
	
	T* Dequeue(){ // Remove at the Head
		T *head=next;
		next=head->next;
		next->prev=static_cast<T*>(this);
		return head;
	}
	
	void Remove(){ // remove node
		prev->next=next;
		next->prev=prev;
	}
	
	T* Next()const{ return next; }
	T* Prev()const{ return prev; }
	
	bool isEmpty()const{ return next==static_cast<T*>(this); }
	bool isBaseNode(const T *node)const{ return node==static_cast<T*>(this); }
	
private:
	T *next;
	T *prev;
};

// ------------------------------ Usage ----------------------------
class Q1 : public Cdll<Q1>{
public:
	Q1(): Cdll(this) {}
};

class Q2 : public Cdll<Q2>{
public:
	Q2(): Cdll(this) {}
};

class Tcb : public Q1,public Q2{
public:
	template<class T> static Tcb* getInst(T *node){
		return static_cast<Tcb*>(node);
	}
};

Q1 q1;
Q2 q2;
Tcb tcb1,tcb2;

int main(){
	q1.Enqueue(&tcb1);
	q2.Enqueue(&tcb1);
	q1.Enqueue(&tcb2);
	q2.Enqueue(&tcb2);
	
	Q1 *n1=q1.Dequeue();
	Q2 *n2=q2.Dequeue();
	Tcb *t1=Tcb::getInst(n1);
	Tcb *t2=Tcb::getInst(n2);
	printf("%p %p\n%p %p\n%p %p\n",
		n1,n2,t1,t2,
		Tcb::getInst(q1.Dequeue()),
		Tcb::getInst(q2.Dequeue()) );
	
	return 0;
}

00405030 00405038
00405030 00405030
00405040 00405040

Избавится бы от некоторой кривоты и было бы то, что надо...

BlackOps

Jul 9 2012, 06:34

у меня один вопрос небольшой.

предположим есть задача реализовать некую непростую систему управления, имеется stm32f405 с 1МБ Флэш памятью, АРМ с 168Мгц частотой, и блоком FPU.
Предположительно будут работать две группы:
группа 1 занимается разводкой платы с сенсорами, приводами и разъемами к рулям управления итд.,
группа 2 разрабатывает алгоритмы управления и планирует писать программу управления на С++.

Есть два варианта:

Вариант 1: Разработать плату, подключить все устройства. Написать функции доступа к различным блокам, рулям, сенсорам через периферию. А затем, достать второй дебаггер, дать его группе 2 и начать дальше вместе с этой группой разрабатывать систему управления и подключать ее к своим функциям доступа к периферии.

Вариант 2: Разработать плату, подключить все устройства к ней как в варианте 1, но потом, организовать скажем УАРТ соединение с компом т.е. написать программу на Визуал С++ для работы с УАРТ, ну а там группа 2 пристроит к ней программу управления на С++ и запускать ее будет на компе, т.е. программа управления на компе управляыет платой и устройствами подключенными к ней и читает ее сенсоры. Ну а после того как скажем все отлажено, совместно с группой 2 портировать всю их программу на stm32f405

Я просто думаю не возникнет ли каких граблей в случае с вариантом 2 при портировании написанного кода на С++ с компа на stm32f405Ну чтото вроде, их программа окажется слишком замороченной и выйдет проблем много если попытатся запустить ее как есть на stm32f405 ?

С одной стороны вроде С++ он портируемый, но с другой стороны, не возникнет ли проблем каких с памятью или еще чем?

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

Так как лучше поступить, какой вариант выбрать более правильней будет?

jcxz

Jul 9 2012, 07:00

купить evalboard на планируемый проц для группы 2.

neiver

Jul 9 2012, 08:15

Правильный вариант - это тот который максимально экономит время и деньги заказчика. А значит обе группы должны работать максимально параллельно. Судя по объёму памяти, программа будет довольно сложная. ИМХО имеет смысл делать так: пока первая группа разводит плату и т.д., вторая группа на Визуал С++ пишет и отлаживает высокоуровневые алгоритмы системы, реализовав низкоуровневые функции управления железом ввиде заглушек. А когда плата готова действовать по варианту 2, только УАРТ соединение с компом по большей части использовать для тестов и отладки "железных " функций.

Almaz1988

Oct 17 2012, 05:20

Пишу в Keil. Микроконтроллер lpc11c24.
Есть рабочий проект, использующий CAN-прерывания.
В этом проекте меняю расширение файла main.c на main.cpp.
В настройках проекта указываю --cpp.
Запускаю, прошиваю - программа стартует и работает до первого прерывания - оно не срабатывает

AHTOXA

Oct 17 2012, 05:50

к функциям-обработчикам прерываний нужно приписать
extern "C":

Код

extern "C" InterruptHandler()
{
...
}

Сергей Борщ

Oct 17 2012, 05:54

QUOTE (Almaz1988 @ Oct 17 2012, 08:20)

работает до первого прерывания - оно не срабатывает

Забыли добавить квалификатор extern "C" к обработчикам прерываний, находящимся в .cpp файлах.

SSerge

Oct 17 2012, 06:19

Цитата(Almaz1988 @ Oct 17 2012, 12:20)

Запускаю, прошиваю - программа стартует и работает до первого прерывания - оно не срабатывает

Волшебное слово extern "C" перед обработчиком прерывания не забыли?

ЗЫ. Долго думал

, опередили.
Если предполагается компилировать и в С и в С++ режиме, то так:

Код

#ifdef __cplusplus
extern "C"
#endif

Almaz1988

Oct 18 2012, 04:28

Ага, запустилась прога, спасибо)

yanvasiij

Jun 9 2014, 00:27

Насыщенная ветка получилась. Нашел ответы на многие свои вопросы тут. Может на базе этой темы запилим небольшой FAQ по C++ для эмбедед, а то на форуме уже все чаще и чаще вопросы на эту тему. Может кто подведет своеобразный итог? Предлагаю следующую структуру:
1) Настройка компиляторов для работы с C++
2) Как смешивать С и С++ в одном проекте
3) Что такое синглтон и почему он так актуален для эмбед
4) Как выделять память под объекты. Почему не стоит эти объекты просто объявлять как глобальные переменные
5) Применение STL - как и стоит ли?

ну что то типа того...

Сергей Борщ

Jun 9 2014, 02:25

Цитата(yanvasiij @ Jun 9 2014, 07:37)

Может кто подведет своеобразный итог?

Инициатива наказуема. Подводите.

AniGoch

Jun 17 2014, 06:47

Вот набрёл на библиотеку С++
http://xpcc.sourceforge.net/api/main.html

Есть кое-что и для ARMов

Копейкин

Jun 17 2014, 11:05

AniGoch, ссылка ведёт в 404

den_po

Jun 17 2014, 18:17

Цитата(AniGoch @ Jun 17 2014, 10:47)

Вот набрёл на библиотеку С++
http://xpcc.sourceforge.net/api/main.html

Есть кое-что и для ARMов

ну вот ещё несколько:
https://github.com/RickKimball/fabooh.git
https://github.com/JorgeAparicio/libstm32pp
https://github.com/pfalcon/PeripheralTemplateLibrary
http://andybrown.me.uk/wk/category/stm32plus/
последняя выглядит шикарней всего

Сергей Борщ

Jun 18 2014, 06:33

Цитата(den_po @ Jun 17 2014, 21:17)

последняя выглядит шикарней всего

Спасибо. Почитал описания и прошелся по ссылкам из описания, узнал много нового. Работа автором проделана огромная. Жаль, что это обертка над стандартной библиотекой.

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.