Atmel или NXP, помогите выбрать Опции

[Lotor]

Время поспело, в моей конторе дали добро переходить на современный МК. Выбор пал на ядро arm7. Осталось определиться с производителем. Если не трудно, можете назвать плюсы или минусы микроконтроллеров NXP и атмела. Объективно, без священной войны и шапкозакидательства. Занимаемся измерительными приборами, в основном простыми - из периферии только таймеры и уарт, SPI и I2C реализую программно (так проще). Но в скором времени будет проект с CAN. Во-общем хочется выбрать семейство МК на вырост. Производство серийное, цена значение тоже имеет. Еще некоторые приборы идут жить к военным, они почему-то легче соглашаются с мк производства атмел. У NXP напрягло отсутствие подтяжек - место на плате дорогого стоит, но главный его плюс - наличие литературы на русском и дешевые отладочные платы... Буду рад Вашим ответам.

[aaarrr]

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

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

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

[zltigo]

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

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

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

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

[aaarrr]

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

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

Правильно. Вот это надежно без резкого падения скорости невозможно - поди разберись сколько там процесс приема успел вычитать и снаружи вдули (только чтением заполнения FIFO не обойтись) - вот тут действительно кучу кода наворотить придется и тех-же железных ресурсов типа таймеров потратить и причем БЕЗ гарантии надежной работы.

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

А требования к толщине каналов растут и растут в отличии от давно эксплуатирумого RS485 в промышленном оборудовании.

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

[zltigo]

Результаты работы с аппаратным управлением потоком под виндой...

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

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

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

А в программе это таймер...

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

и дополнительные тормоза.

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

[aaarrr]

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

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

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

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

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

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

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

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

[zltigo]

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

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

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

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

Удобно?

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

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

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

[aaarrr]

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

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

...имеющихся в избытке UART

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

Ну и что? Подчинить выбор контроллера исключительно наличию прямого управления передатчиком у UART?

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

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

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

[zltigo]

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

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

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

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

[aaarrr]

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

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

[zltigo]

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

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

[aaarrr]

Ну а провода на нескольких метрах межблочных экономить достаточно мелочно, тем более, что в реальности это массовые 2/4 витые пары, к счастью, распространившиеся вместе с Ethernet. Приемо-передатчики тоже не по одному корпусированы.

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

Кроме того это не "практически 485" - "лишняя" пара проводов это это дуплекс с выбранным или любым другим slavе, экстенное прерывание передающего фрейм,...

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