[brag 0]

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

 

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

 

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

под винду еще сложнее(интерфейс у них сложный), пишу иногда дрова под свои приблуды на USB. мож из за привычки к голому железу, хз.. но тут уж выбора нету

 

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

[1891ВМ12Я 0]

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

тортик :)

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

 

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

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

 

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

 

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

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

[brag 0]

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

 

[sasamy 1]

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

 

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

[KRS 1]

AVR,

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

 

[dxp 53]

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

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

 

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

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

 

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

Это радует.

 

P.S.

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

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

 

[brag 0]

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

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

 

Это радует.

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

 

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

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

[1891ВМ12Я 0]

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

 

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

по этой ссылке есть оценки потребления для 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 0]

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

В общем, это неправда, что С++ оправдан везде, где оправдан С.

 

Точно и сразу зарплата этого программиста вырастает ).

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

 

[Axel 1]

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 1]

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

 

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

Изменено 20 июня, 2012 пользователем sasamy

[1891ВМ12Я 0]

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

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

[Axel 1]

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

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

[brag 0]

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

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

[brag 0]

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

Типа так (прямое обращение к приватам с целью сокращения строк кода, не обращайте внимания):

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,мало памяти,все дела.. так же, как и использование множественного виртуального наследования. тоесть должно быть максимум оптимизировано по быстродействию и обьему оперативной памяти.