caxapa.ru :: Как ни странно, в контексте этой темы Вы очень даже правы. Так сказать, дрим-борда образца 2011 года.

Evgeny_CD, Архитектор (13.01.2011 16:37, просмотров: 171) ответил fk0 на Профессионалы программируют PIC18.

Как ни странно, в контексте этой темы Вы очень даже правы. Так сказать, дрим-борда образца 2011 года. http://www.dcd.pl/acore.php?idcore=36
Пусть у нас есть UART, к которому подключен сотовый мудем. И вот у нас в FIFO приплыли аж целых 14 байт данных, и - т это да! - дернулся сигнал квитирования. И что, будить чудо проц по такому поводу? Куда проще поставить DRPIC1655X ->, чтобы он принял поток, декодировал там пакеты, разложил пакет в C структуру, через DMA переслал все это в память, и только потом разбудил "большой проц". 22 нм DRPIC1655X при тактовой мегов 50 (а больше незачем) жрать будет совсем немного :)

Ответить

- Говноархитектура. Совершенно непонятно как софт поддерживать размазанный по разным архитектурам и компиляторам. Как обновлять и т.п. На "большом проце" же есть свои FIFO и DMA на случай чтоб часто не будиться. Да и прерывания не особо тяжкие fk0(85 знак., 13.01.2011 18:01)
  - Все понятно. Мелкий проц реализует законченный кусок работы, связанный с большой системой небольшим числом простых связей. Код для мелкого проца можно отладить полностью. Грузить его туда просто как бинарный имидж. В интеловские же процы грузится Evgeny_CD(35 знак., 13.01.2011 18:17)
    - Ага, большой проц грузит бинарник программы процов помельче, те грузят в совсем мелкие и т.д. she(103 знак., 13.01.2011 18:23)
      - И если к моменту загрузки всех процов аккумулятор еще жив - устройство пробудет стартовать :) На самом деле, переход к "интеллектуальной периферии" важен и с точки зрения надежности и упрощения разработки "большого" ПО. - Evgeny_CD(13.01.2011 18:26)
        
        с точки зрения надёжности это скорее путь в ж(*)у. Это же не распараллеливание на равноправных CPU, а исключительно иерархическая структура, которая однозначно рушится при поломке верхних звеньев koyodza(107 знак., 13.01.2011 23:31)
        
        Если при монопроцессоре он сдохнет, то сдохнет все. Если же сдохнет "сопроцессор UART", то "большой процессор", как минимум, оставит матерную запись в логе. А как сделать так, чтобы сошедший с ума "мелкий сопроцессор" не вынес моск большому Evgeny_CD(43 знак., 14.01.2011 10:19)
        
        Дада! На каждый бит по отдельному процессору -- а то вдруг сдохнет. Только эта, а почему процессор должен умирать сразу и полностью? Обычно ноги отгорают. - fk0(14.01.2011 11:43)
        
        "кто будет сторожить сторожей?" Да и нафиг нужен "большой" процессор, когда у него передохли все "мелкие"? Или даже не все, но жизненно важные. Пусть не передохли, но подвисли - всё равно скорее всего всю систему перегружать придётся koyodza(395 знак., 14.01.2011 10:26)
        
        Дада. ВО ВСЁМ ВИНОВАТЫ ПРОГРАММИСТЫ! Имбецилы, олигофрены, идиоты! Только они идут в программисты. А нормальные люди -- в сантехнки. Ага. - fk0(14.01.2011 11:43)
        
        Не могу найти ссыллку. В одной защигательной исламистской стране взяли и казнили метеорологов за неверный прогноз погоды. Я чет-както сомневаюсь, что прогнозы от этого стали лучше. - Evgeny_CD(17.01.2011 13:52)
        
        прогнозы стали более расплывчаты)))) - antm(17.01.2011 14:03)
        
        Но как ни крути - армия - самая здоровая часть общества(С):) - Vit(14.01.2011 23:52)
        
        В вашем лице юстиция потеряла генерального прокурора. - General(14.01.2011 23:49)
        
        да что там прокурора. сразу целую тройку НКВД! - Snaky(18.01.2011 12:57)
        
        Сдается мне, он еще молод. Так что случаи всякие бывают, может и не потеряла :) - Evgeny_CD(17.01.2011 19:35)
        
        про имбицилов никто не говорил, но виноваты программисты по определению :=) - koyodza(14.01.2011 21:31)
        
        Вначале программисты исправляют все чужие просчёты, а потом на них как всегда традиционно дерьмо выливают, мол во всём виноваты. И всегда так. Доколе? Что не бывает лажи в ТЗ, в электронике? Да полно. Вообще на уровне проектирования, не знаю fk0(130 знак., 15.01.2011 00:06)
        
        Анекдотики припомились Vit(225 знак., 15.01.2011 00:49)
        
        Про современных сантехников мне даже думать страшно. Что у них там с эффективностью :) - Evgeny_CD(14.01.2011 11:47)
        
        "если бы программисты строили туалеты" - koyodza(14.01.2011 21:45, картинка)
        
        "Чего же хотел заказчик" Evgeny_CD(14.01.2011 21:55)
        
        [:]||||||||[:] и к тому же "широкополосный" koyodza(80 знак., 14.01.2011 21:56)
        
        Но именно этот вариант этого баяна "правильный". Скопированный из книжечки по программированию, или, скорее, об упрощении отладки :-) (у меня её упёрли лет десять назад :-( ). Книжечка переводная середины 80-ых, и там была ссылка на журнал ReAl(44 знак., 15.01.2011 01:23)
        
        В соседней конференции. Только не про сантехников, а про маляров. - vmp(14.01.2011 12:25, ссылка)
        
        Сильно! - Evgeny_CD(14.01.2011 12:27)
        
        Сторожей оставляем в покое. Суть в том, что программисты живут не сами по себе, а по планам, составленным менеджерами. А тем надо быть лучше менеджеров в соседней комнате. И критерий "лучшести" - более эффективно изнасиловать своих Evgeny_CD(116 знак., 14.01.2011 10:32)
        
        это давно известно. И Вы предлагаете усугубить ситуацию? Не надо подбрасывать менеджерам подобных новых идей, спокойнее будет koyodza(53 знак., 14.01.2011 10:44 - 10:51)
        
        Нет, сейчас я в engineering_mode - Evgeny_CD(14.01.2011 10:56)
        
        Усложнение архитектуры системы упрощает разработку только в мечтах ИМХО :) - she(13.01.2011 18:28)
        
        Ну, так усложнения разные бывают. Тут есть сравнение x86 и ARM. А я мог бы сравнить Bill(204 знак., 14.01.2011 07:46 - 08:29)
        
        О, так все асмачники всегда говорили :) - Evgeny_CD(13.01.2011 21:56)
        
        и были правы. Сравните сложность современной х86 и ARM. Чего там в х86 сейчас только не понапихано, о чём мы даже уже и не подозреваем, и всё для того, чтобы сделать её быстрее при сохранении совместимости - koyodza(13.01.2011 23:34)
        
        В точку. И как выяснилось, надурить природу и в этот раз не вышло. Перетяжеленность x86 на наших глазах ломает ему хребет. - Evgeny_CD(14.01.2011 10:20)
        
        Перетяжелён х86 или нет - отдельная тема. Для начала ответьте: что в нём лишнего, относительно RISCов аналогичной производительности? :-) - =AlexD=(14.01.2011 12:09 - 12:12)
        
        Как мы уже выясняли, ->, при обычных целочисленных задачах Atom не имеет заметного преимущества над старшими ARM и MIPS. При этом последние достигают такого же перфоманса с гораздо меньшими извращениями на кристаллле, и при гораздо меньшем Evgeny_CD(144 знак., 14.01.2011 12:21, ссылка)
        
        У меня выводы совсем другие - сравнимые по частоте ARMы по потреблению дышут Атому в затылок, на частоте 2ГГц в затылок дышит уже Атом :-)), производительность на мегагерц с повышением частоты должна уменьшаться, это вообще не показатель, =AlexD=(292 знак., 14.01.2011 14:34)
        
        Зрим в корень -> Atom; Cortex A9 --> Evgeny_CD(1744 знак., 14.01.2011 15:51, ссылка, ссылка)
        
        -> Судя по всему, Nvidia взяла LP вариант Cortex A9 (площадь кристалла и тактовая 1 Ггц), т.е. если бы она взяла оптимизированный по перфомансу вариант, Atom был бы полность порван. - Evgeny_CD(14.01.2011 16:06, ссылка)
        
        И, между прочим, добавила туда 1Мб L2-кэша. Так что у Tegra-2 его в 2 раза больше, чем у Атома Dir(202 знак., 14.01.2011 23:11)
        
        да, там круто все замешано. Собственно, Cortex A9 занимает вообще 10% площади камня :) - Evgeny_CD(17.01.2011 13:35)
- Неее... Как раз в контексте этой темы он не прав. Теперь даже мысли ни у кого не возникнет, что что-нибудь кроме АРМов применять можно... Король умер! Да здравствует король! ;) Dir(319 знак., 13.01.2011 17:42)
  - Угу. Закон Мура для железа никто не отменял. А для моска среднего программиста он обратный. - fk0(13.01.2011 18:04)
  - Да, Cortex-M0 - он более халяльный. - Evgeny_CD(13.01.2011 17:48)

Средства и методы разработки