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 в новое? "Громадность" затрат я представляю более, чем хорошо.