Опять минус 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 контроллер по производительности уперлись - это проблема.