-
eventhelix.com — маленький и удобный справочник по эмбедщине и программированию реального времени
Replies (53)
-
@koshechka, eventhelix.com — вот например, пункты 15,16,21,22 спорны. вообще техническая часть относится либо к 1 проценту либо к 94
-
@koshechka, к 21 можно придраться, хотя consider — это и нестрогое указание,- но в чём провинились пункты 15, 16, 22?
-
@koshechka, Насчёт 15, 16, 21 — инкрементирую.
А вот 22 кажется мне вполне разумным. -
@jtootf,
15: "Prefer general purpose computing platforms over specialized platforms"
Очень спорный пункт. Domain purpose платформы часто стоят на порядки дешевле general purpose, они более просты и имеют больше функциональности для реализации своей предметной области. Зачем переплачивать за навороченного монстрика, который умеет всего понемногу, если есть железка, котороя умеет делать только мелкий набор вещей, но делает его хорошо? Насчёт отсутсвия специалистов — полный берд. Если человек разобрался хоть с одной general purpose платформой, то разобраться с domain purpose для него вообще не составит труда.
16: Do not use proprietary protocols/operating systems
Если проприетарное решение лучше, почему бы его не использовать? Примеров тому масса: я лучше куплю vxworks, чем буду рыться в какашках uclinux.
21: Consider hardware upgrades to reduce software effort
Спорный пункт. Зачастую переход на новый хардварь требует серьёзной модификации софтвари. -
@koshechka, система должна быть простой, насколько это возможно, но не проще; понятно, что баланс должен быть, но сделать много параметров куда проще, чем сделать мало — потому, с моей точки зрения, совет вполне здравый
-
@dk, 15 — вообще обычно domain-purpose железо стоит существенно дороже — во всяком случае весь мой опыт указывает на это, поэтому аргумент звучит чуть более, чем странно. насчёт специалистов — одно дело найти человека для работы с x86-чипом, другое дело — для работы с (например) DSP-процессором. понятно, что разобраться можно всегда и во всём, но с платформами общего назначения опыт получить куда проще, а следовательно и людей найти — тоже
-
@jtootf, Ну например mpc866 стоит ~ $50. (пруф: freescale.com
Я боюсь даже предположить, сколько стоит борда с интелом, дающая подобную функциональность.
Насчёт специалистов: если смотреть в internals инициализации контроллеров, фичей и прочего гумна x86-family, то внезапно они оказываются на порядки более сложными, чем те же армы, поверписюки и мипсы. Одни голимый APIC чего только стоит. Если человек разобрался в интерналах x86, то освоение любой другой архитектуры — это дело нескольких дней максимум. (насчёт любой я конечно загнул, какие-нибудь навороченные гадости типа cell'а или ниагары займёт поболее) -
@dk, 16 — vendor lock-in, отсутствие внешних стандартов. если ты работаешь с открытым стандартизованным протоколом, ты в любой момент можешь поменять реализацию любого из уровней OSI (в рамках доступных); если протокол приприетарный, то выбора у тебя нет. нет возможности сэмулировать проприетарное железо, потому что вендор не даст тебе спецификаций; нет возможности внести уровень абстракции в ПО, потому что вендор зафиксировал API в закрытом коде. да, иногда проприетарные решения работают лучше, но тогда их выбор — просто меньшее зло из имеющегося
-
@jtootf, Проприетарные решения, как правило — это готовые законченные продукты с достойной поддержкой пользователя и хорошей документацией. Если есть деньги, почему бы не сэкономить время? Потому что в противном случае придётся тратить немало времени на допиливание какой-то недопиленной поделки.
Да, есть достойные open-source продукты и есть достойные открытые протоколы, но их мало. Особенно под конкретные специфические цели. -
@dk, потому что времени на борьбу с их закрытостью тратится ещё больше, и никакая техподдержка тебе тут не поможет. например, в упомянутой выше задаче эмуляции проприетарной железки на виртуальной машине — ты не получишь такой возможности до тех пор, пока сам вендор не реализует эту функциональность. на спецификации под NDA можно надеятся, но гарантировать их никто не будет
-
@jtootf, Подчёркиваю: проприетарные рещения нужно использовать тогда и только тогда, когда это выгодно. Если вендор не может предоставить нормально SDK с эмуляшкой и нормальной доки, то зачем такое покупать? Почему-то нормальные вендоры всё это предоставляют. Можно посмотреть на cell SDK или, возвращаясь к FPGA, на xilinix
-
@koshechka, та, которую можно запустить на CPU, GPU, DSP-процессорах
-
@koshechka, и какую на выходе получим производительность? и ради чего?
-
@koshechka, ну вот есть у нас чип общего назначения, на котором работает реализация пары протоколов и DSP поверх операционки. можем мы перетащить эту задачу на какой-нибудь Spartan3, не потеряв производительность к чертям? стоит ли нам это делать?
-
@koshechka, допустим ещё не работает. что может побудить нас воспользоваться для этой задачи FPGA?
-
@koshechka, числа, мне нужны числа. есть сравнение производительности FPGA-решения вместо того же ARM или Atom на соответственных задачах? есть сравнение энергопотребления? что касается операционок, то up to my experience железо в подобных задачах меняется куда чаще операционки, во всяком случае такую миграцию оправдать куда как сложней
-
@jtootf, есть доска xilinx ml510 с полностью софтовым PPC440, на него некоторое время назад портировали lynxos-178. результаты performance теста всего на 10 процентов хуже чем в случае ibm440ep с такой же частотой цпу. конкретных цифр к сожалению дать не могу. NDA
-
@koshechka, а по энергопотреблению/нагреву отличается существенно?
-
@koshechka, всё, с зарплаты беру плату со спартаном — буду экспериментировать :)