ИМХО, хуже: даже будучи хорошо вооруженным, проверить досконально все не получится. Всегда остается вероятность, что при некотором стечении обстаятельств случится бяка.

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

Мы про какие два слоя говорим? -
Только два сигнальных? Или два сигнальных плюс два питания?

Только два сигнальных, естественно.

Естественно, про ОБЩЕЕ количество . А то рассуждая о выделенных слоях под питания и земли для какой-нибудь по нынешнми временам вполне обычной FPGA можно ооочень глубоко зарыться в слои .


C Выделенными земляными уже можно и думать, и моделировать и на опыт опираться... А вот без них совсем шаманство

Да, выразился неудачно Имелось в виду общее количество, разумеется.

Понятно.
Пока мнение такое, что лучше зарыться в слои, чем в проблемы.

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

Повторяю свой вопрос!
Где взять бут для LPC2378 работающий через USB?
Тут много любителей LPC, неужели вы не знаете где можно его достать.

А к чему это здесь? Да и еще повторять?

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

Опять минус LPC, они даже не удосужились модифицировать этот бут для новых серий контроллеров.Это единственная причина не работающего бута на LPC23XX?. Теперь еще и придется читать манул на LPC21XX и сравнивать. Откуда мне, начинающему с контроллерами LPC знать что там менять. NXP даже лень создать какой-нибудь Migration для модификации бута. Я был лучшего мнения о них. На рассыпуху у них документация хорошая. А тут полный бардак.

Мануалы хорошие - мусора мало , можете вообще почитать мануалы от ARM - оба контроллера прерываний из ARM PrimeCell набора.

Так Вы хотите стать не начинающим? Тогда придется узнавать много нового , ну а если только поговорить на тему "как сделать так, что-бы ничего не делать", то для этого на форуме есть специальный раздел.

Пока я бардак наблюдаю в другом месте - это Кейловский пример под их борду. Как водится "приняты меры", дабы не портировалось легким движением руки под другой компилятор и другой контроллер. Но за часок-другой можно выкинуть кейловские прибамбасы, левые хидеры и запустить.

Вот где количество мусора запредельное, так это в Атмеловских даташитах на AVR'ки. Когда они добавили примеры работы в описание периферии, пользоваться мануалом стало ну очень неудобно

А мне вот в LPC нравится что таймеры 32 битные еще и с прескалером 32 битным! и PWM контроллер тоже. Мелочь конечно, но приятно
У Атмела конечно PDC очень прост в использовании, но зато у переферии вообще нет фифо! что очень неудобно. и приходится использвать PDC буквально на пару байтов.

Ну, дык, я о том-же, правда у AVR это еще усугубляется подходом "делаем,думаем,переделываем".
Тут относительно недавно "все в одном и больше ничего знать не желаю" на одну из самых правильных TI MSP430 документаций (вот где вопрос типа, "а чем конкретно отличается железо LPC23 и LPC214" решился-бы пулей) наезжали. Душераздерающее зрелище.

Зато у NXP маразматичные UART'ы в духе '550. FIFO есть, зато нет возможности прочитать его текущий уровень. И возможности управления драйвером RS485 нет. Хотя в другом их продукте (весьма, кстати, замечательном) - SC16IS762 - все это предусмотрено.

Не в духе, а в миимальном варианте они и есть. Классика, есть курутонавороченнее, но и IBM PC и NXP вполне работоспособны . В свежих чипах добален и ряд наворотов в частности и аппаратный flow control.

Но ведь можно же сделать нормальный продукт, даже не ломаю "классику", и IS16SC762 тому пример.

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

Я не впадаю в депрессию, меня лишь удивляет бездумное копирование устаревших и неоптимальных решений в современных продуктах, точнее, только одного решения. И созданием похожих на '550 UART'ов, порой даже абсолютно не совместимых с оригиналом, грешит не только NXP.

Во! Ну для начала, пожалуй, не стоит-ли задать себе вопрос об использовании в "современных продуктах" UART/RS485 . Лично у меня его использование закончилось во времена XT/AT286 с теми самыми еще 8250 ну и 8251 в периферии (причем без неразрешенных проблем!). Ну а классическому использованию 82550/LPC претензии-то есть?

Не надо перекладывать с больной головы на здоровую. От RS485 еще очень долго никто не откажется.


Дык я тоже не изобретаю велосипед. Но мои эстетические чуства все же страдают, когда я встречаю очередной 550.

RS232, пожалуй, "вечен" а вот вариации.. Я, например, отказался от RS485 (и отнюдь не по причине засилья 550 ). Просто массовые кабели под LAN или даже телефонные четырехпроводные стоят неприлично дешево, а канал хочется все побольше и побольше .... Посему, RS422 еще как-то используется в простейших применениях, ну а вообще меня много-много больше волнует (и не только с эстетической точки зрения) качество CAN, Еthernet, USB, SPI, SPORT,...

У меня, к сожалению, специфика продуктов - промышленная автоматика - не позволяет отказаться от RS485.

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

Ну явно демонизируете мелкую проблему. Вот, например, что делать если у контроллера вообще нет изохронного режима USB, или эндпойнтов по минимуму, или в Ethernet контроллер по производительности уперлись - это проблема.

Я не демонизирую, а добросовестно не понимаю, что побуждает производителя делать так

И не такая уж это и мелкая проблема: попробуйте на классическом 550 управлять драйвером RS485. Будет очень криво.

А они, понимаете ли, flow-control аппаратный добавляют...

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

Правильно. Вот это надежно без резкого падения скорости софтом решить невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы. А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании. И подстройка бодов под почти любой кварц (тот-же USB 12MHz) эта та проблема которую никак не решить, если подстройки нет. Ее в свежих чипах и добавили. C тем-же некошерным с точки зрения UART 12MHz/произвольным кварцем проблемы работы bootloader на высоких скоростях - тоже не решаемая проблема, если производитель ее не решит. Ее решили.

Но очень плохо решаема. Накладные расходы для решения в железе равны 1 триггеру для бита, разрешающего вывод сигнала TEMPT на пин. А в программе это таймер и дополнительные тормоза.


Результаты работы с аппаратным управлением потоком под виндой дали обратные результаты - для надежной работы нужен большой софтварный FIFO, т.к. после выставления RTS может свалиться еще байт 20-60. Trigger level у меня использовался 64, с меньшим были проблемы. А Auto-RTS пришлось выкинуть за бесполезностью.


RS485 может быть и 20 мбит/с.

Для связи с Виндой в общем случае это глухой номер, именно по причине отсутствия железной поддержки со стороны PC железа усугубляемой зачастую и большей глубиной TX FIFO (у меня, например мультипортовки по 128-256 байт). Это, увы, уже только для раскочегаривания канала между контроллерами.

Естественно, я эти приемопередатчики на синхронных 2-4-8-16 мегабитах широко пользую, вопрос на каких скоростях Вы работаете в симплексе со своим промышленным RS485 оборудованием ?


Ну или обработка эха, или второй UART, или...

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

Ну вот, а часто ли Вам нужен канал между контроллерами с управлением потоком?


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


Или еще что-нибудь в этом роде - ПЛИСка там внешняя, например. Удобно?


На 115.2 килобит уже не совсем символические.

Не пользовал, но почему-бы и нет? Тот-же RS422, банальный 4x2 витой кабель и простейший, но мегабитный межблочный канал готов.

Вот только нафиг там RS485, а не TTL/RS422/....

Нот. Но не не слишком и хлопотно во многих случаях можно поступить, например, при работе без parity или с менее, чем 8bit подключаем TX одного имеющихся в избытке UART прямо к управлению предатчиком и запихнув в него нолик с нулевой parity получаем желаемое управление без потери, возможно, нужного таймера. Есть более удобные железки - есть! Есть UART железо максимально приближающееся к идеалу - есть! (у Am186, например). Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

Повторяю вопросы - на каких скоростях работает существующее промышленное оборудование и зачем закладывать RS485 в новое? "Громадность" затрат я представляю более, чем хорошо.

Дык межблочный, один мастер - N слейвов. Рядом килоамперы разрываются.


Не имелись они в избытке до последних времен.


Я разве это предлагал? Но учитывать эту особенность приходится.


1. 19200, 115200.
2. Оборудование не только мое, так что от RS485 никуда не деться.

Ну так - RS422, все сидят слушают мастера. Получив свой адрес подключает передатчик и вперед. Получив не свой адрес - отключает. Линия приема мастера почти всегда хорошо подтянута одним из передатчиков- меньше помех.

Ну дык, естественно, приходится.

Работа идет в стиле запрос-ответ. В результате получаем практически тот же 485, только проводов больше.

Ну а что еще из 485/422 красивого в случае шины сделаешь
Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.
Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...
Все это по здравому размышлению приводит к малоцелесообразности использования RS485, там где это не навязано внешними неподвласными факторами.

Проблема не в проводах, а в разъемах и месте в них.


Дуплекс мне даром не нужен. В оличие от RS485 экстренно передающий слейв в RS422 не увидит конфликта на шине с другим.

Потому, что у Вас его нет . Вы вроде не испытывете никаих особых проблем от отсутствия дуплекса (точнее обходите его отсутствие - вот сразу уже разговоры о коллизиях начались), а я от отсутствия "очень нужного бита" для управления передатчиком. Проблема имеющее решение и не проблема вовсе. Дальше голые эмоции "да как могут в современном чипе не приделать прямое управление передатчиком RS485", ну или "да как можно в современном чипе не использовать имеющийся CAN" .

Его увидет master и аккуратно заткнув текущего спросит "ну кто там хотел экстренно столько-то времени тому назад передать". Вообще-то если, как мне показалось,мы уже ведем разговор о своем оборудовании, то... то CAN, а не пляски с двумя проводами RS485 смотрятся много более уместно.

Мы вроде уже до разговора о межблочных связей, причем в своем оборудовании, докатились? А блок, по крайней мере в моем понятии, штука большая, c солидной начинкой, со своим питанием... Какое такое "место в разьеме"?
P.S.
Может в теме обсудим более суровую периферию чипов поминаемых в топике произволителей? А то ведь, действительно докатимся до споров об оттенках черного у корпусов .

Так, докатились до CAN'а Скажите, а зачем я должен отказываться от RS485? Из-за наличия у используемого мной контроллера поддержки CAN'а?
Но это уже даже больший маразм, чем:

Ибо уровень решения и объем последствий несоразмерен.

CAN меня не устраивает по причине очень уж короткого поля данных.


Давайте. Только вот действительно суровой периферии у них нет практически.

По большому счету у 485 оно вообще байт - все остальное уже протоколы верхнего уровня.Тем не менее все устраивает .

Неожиданное утверждение. Пожалуй тогда не буду продолжать разговоры - хватит мне UARTа.

Рад за Вас. Меня, скажем так, устраивает почти все, но это можно пережить


Обсуждать действительно почти нечего: EMAC, USB, архитектура подсистемы памяти и т.п. у Atmel'а объективно хуже, чем аналогичные модули современных NXP. Хотя вполне работоспособны.

Если вернуться к теме топика, то имею сказать следующее :
Продукты атмела не АВР использовать можно только после предварительной обкатки на всевозможные глюки периферии, про которые не вы, не ерата ничего не знаете. Последняя никогда так и не узнает. Вы старательно читаете даташит, не упускаете и ерату, изготавливаете плату а потом начинаете биться с недокументированными багами (те на которые я наступил: SDRAM от samsung и sam7SE512, SSC и передача последнего бита). И если вы думаете, что атмел выпустит ревизию чипа с исправленными багами, то вы ошибаетесь - их инженеры торопятся выпустить новых уродцев не пытаясь лечить старых. И как после этого можно обсуждать преимущества их периферии если при этом она может работать не так как написано в документации.
С тех пор у меня отвращение к атмелу.

PS: Может пост получился совсем мрачным - просто накипело (четыре месяца работы в трубу).

Можете поподробнее описать глюк?


Глюки бывают у всех производителей, в том числе и у NXP. Заносят в еррату и исправляют неохотно тоже все.

Не скажите. NXP вроде правит. А ST например (судя по докам на str9 например) вобще молодцы. Атмел в этом смысле не правит пчти ничего. WDT вот в Sках 7ых подправили, остальное вроде так и осталось. Хотя не с атмелом вплотную не общался может чего не знаю.

Цеплял кодек к этому интерфейсу все было более менее нормально, а когда им же попытался грузить альтеру выяснилось, что при передаче в режиме мастера последний бит всегда равен нулю, хоть тресни ( камень sam7s256). На звук это не влияло почти никак. Подозреваю что глюк перекачевал во все их последующие кристаллы.

Тут позвольте не согласиться - у NXP ревизии камней выходят, чего не скажешь про атмел (где исправленный rm9200, sam7Sxx, sam7se и тп)?

А вот тут я с вами не соглашусь. Уже в нескольких своих устройствах прекрасно гружу Альтеру (Циклоны-2,3, ArriaGX) именно sam7s256. Никаких проблем не было.

У NXP последние полгода или уже год как подорожали процы. Слишком много багов фиксят?

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

А вот похоже и плюсы со стороны LPC. Я правильно поянл что у LPC23xx выводы UART продублированы на несколько портов. Например TXD1 и RXD1 встречаются дважды. Значит можно из UART1 получить сразу два UART если они не будут работать одновременно? Что произойдет если я назначу TXD1 на два GPIO. Вроде защиты от этого в контроллере не предусмотрено.

"Месье знает толк в извращениях"

Еще из плюсов - UART в LPC23xx еще поддерживает дробный делитель для генератора baudrate. Я уже опробовал - весчь.
А вот GPDMA - слабоват - каналов мало, да и память не вся через него доступна. Если используется SD/MMC то один канал DMA надо отдать сразу, иначе читать из карточки очень некомфортно и еще дополнительно начинается геморрой из-за недоступности памяти - в общем случае приходится копировать данные из/в промежуточный буфер. Второй канал DMA желательно отдать USB, и все - DMA в LPC23xx на этом закончился. В моих изделиях идет массированный реалтаймовый обмен по SPI, пришлось второй DMA на него отдать, а вот контроллер USB c DMA обломался .