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]

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

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

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

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

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

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

[zltigo]

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

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

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

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

[aaarrr]

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

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

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

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

[Diman_]

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

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

[aaarrr]

SSC и передача последнего бита

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

С тех пор у меня отвращение к атмелу.

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

[Diman_]

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

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

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

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

[vmp]

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

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