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

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

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

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

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


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

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

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

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

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

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

Это вопрос. Неспешно оцениваем возможность применения толстой платформы для закрытия таких мест, как 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

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

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

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

Сообщение отредактировал sasamy - Jun 20 2012, 13:26

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

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

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

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

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

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