Выбор 16-ти разрядного контроллера - Page 2

Hallo!

проводам.

Кстати, у меня тут вырисовалась очередная непонятка. Для HC12A4, когда пишу
в пословно в EEPROM это удаётся только в Special Wide Mode, а в Normal Wide
Mode записи почему-то не происходит. Могу привести тут и исходник...
Что-нибудь по этой проблеме известно?



Андрей

Tue Nov 16 2004 17:08, Vladimir Vassilevsky wrote to Yuriy K:

 YK>> Freescale
 YK>> MC9S12C32MFA16 - корпус 9x9 с ногами, но нет I2C.
 YK>> Контроллер как контроллер. :-)))

 VV> Rulez. ... Отныне все будем делать на HCS12 и BlackFin-е.

"Кому и кобыла невеста" (с)
Архитектурно НС12 ничего особенного не представляет, имхо, это "механически
нарощенный" 8-битник НС11. Который, в свою очередь, был неплох в 70-80-х,
когда все программировалось в основном на асме. Так что НС12, по сути,
мастодонт, живущий в основном из-за того, что он "главный американский
автомобильный проц". То есть, США из политических соображений не даст ему
"утонуть", каким бы отстоем он ни был. Ну, еще флэш в нем и правда хорош, и
номенклатура довольно обширная. ("Да, он не умен. Но куртка его хороша"(с))

Аналогично, европейцы из политических (хотя бы) соображений не дадут утонуть
С163/ST10.

Из процев, мною перечисленных, архитектура лучше всех у H8S, бо дралась с
PDP-11. Однако остальные фички у него так себе, а "японскость" является
минусом (гемор с докой). Тем не менее, он делит первое место по мировой
популярности с М16С.

Что же касается М16С и МВ90, то они в чем-то похожи: архитектурно оба являются
достаточно удачными _компромиссами_. Ну вроде как 51-й у 8-битников: вроде бы
ничего особенного, но все фишки есть, и все более-мене удобно.

Почему малоизвестный во всем мире МВ90 стал так популярен в России - загадка.
Похоже, Фуджики в свое время просто сильно заложились на этот рынок, поскольку
в другие места всерьез им втиснуться не дали более сильные конкуренты.

Пока,                                 Алексей

Wed Nov 17 2004 13:28, Alex Kouznetsov wrote to Vladimir Vassilevsky:

 
 VV>> Rulez. ... Отныне все будем делать на HCS12 и BlackFin-е.

 AK> "Кому и кобыла невеста" (с)
 AK> Архитектурно HС12 ничего особенного не представляет,

 А что, бывает что-то особенное? Hу разве что идиотский PIC или
 редкостно кривые архитектуры типа TMS24xx/28xx.

 AK> имхо, это
 AK> "механически нарощенный" 8-битник HС11.

 Вовсе нет. 16-битная шина, намного более быстрая растактовка,
 существенно расширенная система команд. Как числомолотилка и пиномахалка
 где-то на уровне 240x серии от TI.

 AK> Который, в свою очередь, был
 AK> неплох в 70-80-х, когда все программировалось в основном на асме.

 ????
 Структура ядра и система команд HC11/12 идеальна для C. Cтековые кадры и
 операции регистр - память. Там нечего оптимизировать, язык чисто ложится
 на архитектуру.

 AK> HС12, по сути, мастодонт, живущий в основном из-за того, что он "главный
 AK> американский автомобильный проц". То есть, США из политических
 AK> соображений не даст ему "утонуть", каким бы отстоем он ни был.
 AK> Аналогично, европейцы из политических (хотя бы) соображений не дадут
 AK> утонуть С163/ST10.

 :))))) Заговор мирового правительства.
 
 Интересная точка зрения. Hадо будет обсудить ее с моими знакомыми из
 automotive индустрии. BTW, на этот маркет лезут и Microchip, и TI, и даже
 AD, только без особого успеха. Видишь ли, в отличие от многих других
 применений писание automotive embedded software implies liabilities and the
 serious investments. Поэтому там все очень консервативно и чтобы менять
 платформу, нужны крайне существенные причины.

 AK> флэш в нем и правда хорош, и номенклатура довольно обширная. ("Да, он не
 AK> умен. Hо куртка его хороша"(с))

 Указом Президента всем предписано использовать PIC :-)))

 AK> Из процев, мною перечисленных, архитектура лучше всех у H8S, бо дралась с
 AK> PDP-11.

 Архитектура по большому счету пофиг, так как ее не очень видно
 под компилятором. Размер кода тоже у всех примерно одинаковый
 с точностью +/- полтора раза, что, как правило, неважно.
 Самое существенное - это удобный набор периферии.

 AK> Почему малоизвестный во всем мире МВ90 стал так популярен в России -
 AK> загадка.

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

 AK> Похоже, Фуджики в свое время просто сильно заложились на этот рынок,

 Велик ли рынок по масштабам Фуджицы? Хотя бы 100k процессоров в год будет?
 AFAIK местные игры более мелкого уровня.

 VLV

"Evil will prevail because good is dumb" (c)  Dart  Weider

Hello Vladimir.

18 Nov 04 01:08, Vladimir Vassilevsky wrote to Alex Kouznetsov:

 VV>  ????
 VV>  Структура ядра и система команд HC11/12 идеальна для C. Cтековые кадры и
 VV>  операции регистр - память. Там нечего оптимизировать, язык чисто ложится
 VV>  на архитектуру.

1)

 AK>> флэш в нем и правда хорош, и номенклатура довольно обширная.

2)

 VV>  Архитектура по большому счету пофиг, так как ее не очень видно
 VV>  под компилятором.

3)

 AK>> Почему малоизвестный во всем мире МВ90 стал так популярен в России -
 AK>> загадка.

1) + 2) + 3) + Сеpгей Пинигин (я не шyчy :)

к 1) также можно добавить богатyю адpесацию.
к 2) - поpядка 50 наименований МК _с одним ядpом_
       и богатым набоpом пеpифеpии.
к 3) - аpхитектypа хоpоша для preemtive RTOS.
Hавскидкy - для фyджиков есть поpты uCOS-II, CMX, embOS, Euros, RealOS.

Hаличие офиц.бесплатного компилятоpа Си - тоже плюс.

 AK>> Похоже, Фуджики в свое время просто сильно заложились на этот рынок,

Политикy не обсyждаю :).

Alexey

Привет, Alexey!
Вы писали to Vladimir Vassilevsky on Thu, 18 Nov 2004 08:49:54 +0300:

 AK>>> Почему малоизвестный во всем мире МВ90 стал так популярен в
 AK>>> России - загадка.
 AM> 1) + 2) + 3) + Сеpгей Пинигин (я не шyчy :)

 AM> к 2) - поpядка 50 наименований МК _с одним ядpом_
 AM>        и богатым набоpом пеpифеpии.

 Периферия фуджиков меня расстроила :( I2C реализован криво, т.е. SDA и
SCL на высокой частоте (кстати больше 400кГц он не может) при
формировании START-STOP переключаются одновременно или даже в обратной,
от нужной, последовательности. При понижении частоты становится заметен
"правильный" сдвиг, но он такой маленький, а ожидаешь переключение по
середине ... SPI реализован то же криво, т.е. возможно он прямой для
кого-то, но для памяти 25Сххх он кривой. Проблема в том, что исходное
состояние SCL=1, а нужно SCL=0, хотя переключения происходят по
правильным фронтам. При чтении, на эту последовательность память еще
соглашалась отзываться, а при записи ни как. Пришлось запись формировать
вручную. Максимальная частота SPI 1МГц, но при работе на ней шли
постоянные сбои, пришлось уходить на 500кГц там сбоев нет. В блоке UART
нет признака окончания передачи последнего бита, что создает изрядные
проблемы при формировании RS485. Правда этого признака почти ни у кого
нет ... Другой периферией не пользовался.
 Да, все это относится к MB90F574A который есть у меня, возможно у
других все гораздо лучше.

With best regards, Leha Bishletov.  E-mail: snipped-for-privacy@rol.ru

Fri Nov 19 2004 14:05, Leha Bishletov wrote to Alexey Musin:

 LB>  Периферия фуджиков меня расстроила :( I2C реализован криво,

 А вообще есть контроллер, в котором I2C реализован без извращений и
 никому не нужных премудростей с арбитражем и пр.?
 Мне приходилось воевать с аппаратным I2C в ATMega и в HCS12.
 Вручную махать пинами намного проще, чем разбираться, какой бит куда должен
 быть установлен.

 LB> SCL на высокой частоте (кстати больше 400кГц он не может)

 Больше 400kHz и не должен.

 VLV

"Evil will prevail because good is dumb" (c)  Dart  Weider

Thu Nov 18 2004 00:08, Vladimir Vassilevsky wrote to Alex Kouznetsov:

 AK>> Архитектурно HС12 ничего особенного не представляет,

 VV>  А что, бывает что-то особенное?

Бывает. Например, MISC-процессоры (RTX2000 и пр.)

 AK>> имхо, это "механически нарощенный" 8-битник HС11.

 VV>  Вовсе нет. 16-битная шина, намного более быстрая растактовка,
 VV>  существенно расширенная система команд. Как числомолотилка и пиномахалка
 VV>  где-то на уровне 240x серии от TI.

С чем же ты не согласен?  Принципиальной разницы между 11 и 12 нет: у 12-го
шина вдвое шире, регистров и команд побольше, тактовая повыше.

 AK>> Который, в свою очередь, был
 AK>> неплох в 70-80-х, когда все программировалось в основном на асме.

 VV>  ????
 VV>  Структура ядра и система команд HC11/12 идеальна для C. Cтековые кадры и
 VV>  операции регистр - память. Там нечего оптимизировать, язык чисто ложится
 VV>  на архитектуру.

Все регистровые архитектуры по сути есть отрыжка АСМ-овских времен. Кстати,
Це, как известно, это тоже в общем-то ассемблер ;-)

Пока,                                 Алексей

Hello, Alex!
You wrote to Vladimir Vassilevsky on Thu, 18 Nov 2004 09:10:41 +0000 (UTC):

 AK> Кстати,
 AK> Це, как известно, это тоже в общем-то ассемблер ;-)

    Ну и где для 16-ти разрядных реализован полный Це++ ?
Так что бы труп страуса остался доволен.
    Или ты про визуальные, так сказать, средства проектирования -
игрушки, не более.

With best regards, Alexey Kovalev

Thu Nov 18 2004 11:17, Alexey Kovalev wrote to Alex Kouznetsov:

 AK>> Кстати, Це, как известно, это тоже в общем-то ассемблер ;-)

 AKov>     Hу и где для 16-ти разрядных реализован полный Це++ ?
 AKov> Так что бы труп страуса остался доволен.

Я ++ вообще не упоминал, непонятно с чего вдруг возник твой вопрос. Но раз уж
тебя этот вопрос интересует, то - 8086

 AKov> Или ты про визуальные, так сказать, средства проектирования -
 AKov> игрушки, не более.

Опять непонятно, как это ты перескочил на визуальные ср-ва проектирования,
если я про них ни словом не обмолвился, да и в мыслях их не держал. Или ты
думаешь, что Це неразрывно связан с гуями, и без них существовать не может? А
где гуя, там ++, так что ли? Странные у тебя ассоциации...
Я про то, что Це является языком среднего уровня, недалеко ушедшим от
ассемблера.

Пока,                                 Алексей

Hello, Alex!
You wrote to Alexey Kovalev on Thu, 18 Nov 2004 10:19:13 +0000 (UTC):

 AK> Я ++ вообще не упоминал, непонятно с чего вдруг возник твой вопрос.
 AK> Но раз уж тебя этот вопрос интересует, то - 8086

    Это микропроцессор, а не микроконтроллер (см. сабж)

 AK> Я про то, что Це является языком среднего уровня, недалеко ушедшим
 AK> от ассемблера.

    Так что же вместо него нужно использовать?

With best regards, Alexey Kovalev

Thu Nov 18 2004 12:51, Alexey Kovalev wrote to Alex Kouznetsov:

 AK>> Я ++ вообще не упоминал, непонятно с чего вдруг возник твой вопрос.
 AK>> Hо раз уж тебя этот вопрос интересует, то - 8086

 AK>     Это микропроцессор, а не микроконтроллер (см. сабж)

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

 AK>> Я про то, что Це является языком среднего уровня, недалеко ушедшим
 AK>> от ассемблера.

 AK>     Так что же вместо него нужно использовать?

Кому нужно, тебе? Ищи ответ сам. Вопрос твой - неприкрытая провокация флейма.

Пока,                                 Алексей

Hello, Alex!
You wrote to Alexey Kovalev on Thu, 18 Nov 2004 11:19:43 +0000 (UTC):

 AK>>> Hо раз уж тебя этот вопрос интересует, то - 8086
 AK>>     Это микропроцессор, а не микроконтроллер (см. сабж)
 AK> Не вижу принципиальной разницы. И х86 существует в виде
 AK> микроконтроллеров, и многие микроконтроллеры могут работать с
 AK> внешней памятью.

    Разница между микроконтроллером и микропроцессором не в этом.

 AK>>> Я про то, что Це является языком среднего уровня, недалеко ушедшим
 AK>>> от ассемблера.
 AK>>     Так что же вместо него нужно использовать?
 AK> Кому нужно, тебе? Ищи ответ сам. Вопрос твой - неприкрытая
 AK> провокация флейма.

    Ну зачем так. Я подумал, что ты скажешь: "Це является языком среднего
уровня, недалеко ушедшим от ассемблера. А вот под семейство X сделали
реализацию языка Y, который уже не среднего уровня, и  что мол он рулез
и я, мол, им пользуюсь."
    Собственно, это впрямую к сабж. относится.

With best regards, Alexey Kovalev

Добрый день.


 


Тогда 186 - уж это то точно микроконтроллер, хотя и с внешней памятью.
 

 


Это скорее филосовский вопрос, чем практический.  8-)

Hello, Alexey Kovalev !

 >  DO>>> Какой у них интерфейс с АСУ ТП?
 >>> Из родоначального письма этой темы видно что CAN.
 >  DO> Тогда - С.

 >     Это как то связано?

C CAN нет, с уровнем задач - да.


С уважением, Дима Орлов.

Hello Alex.

16 Nov 04 15:23, Alex Kouznetsov wrote to Alexey Kovalev:

 AK> Высокотемпературный флэш лучше всех делает Моторола.

Hебольшая коppекция, технология - от SST (см. маленькие бyквы в нижней части
листа с pекламой МК Freescale в каком-нибyдь жypнале).
Тy же технологию использyет не только мотоpола, но и Тошиба, напpимеp.

У Фyджицy тоже неплохой флеш, они даже с АМД скоопеpиpовались.

Alexey

Wed Nov 17 2004 08:20, Alexey Musin wrote to Alex Kouznetsov:

 AK>> Высокотемпературный флэш лучше всех делает Моторола.

 AM> Hебольшая коppекция, технология - от SST (см. маленькие бyквы в нижней
 AM> части листа с pекламой МК Freescale в каком-нибyдь жypнале).
 AM> Тy же технологию использyет не только мотоpола, но и Тошиба, напpимеp.

Технология может быть такой же, а реализация наверняка отличается. До
недавнего времени Тошибовские процы допускали всего 100 перезаписей флэша, что
есть ацтой. Что же касается флэша при высоких температурах, то Моторола -
единственная известная мне компания, которая не стесняется публиковать
результаты испытаний. Остальные об этом стыдливо умалчивают, что наводит меня
на черные мысли.

 AM> У Фyджицy тоже неплохой флеш, они даже с АМД скоопеpиpовались.

"Неплохой" - в каком смысле? АМД к автомобильному рынку относится фиолетово.
Всякая палка о двух концах (с) Вон у TI тоже "неплохой", но в автомобильные
применения они даже не суются, именно из-за проблем с сохранением данных при
высоких температурах, имхо; зато у них количество циклов перезаписи огромное.
Я думаю, Тошиба неспроста делает флэш со 100 циклами; хоть это и неудобно
разработчикам, но, наверное, надежнее при высоких температурах.

Пока,                                 Алексей

Hello, Alexey Kovalev !

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

 >  DO> А тут ты совершенно прав.

 > Кто же это делал принципиальное различие в языках программирования
 > между процессорами и контроллерами? Это не правильно.

 >    А вот разделять реализации языков программирования между
 > процессорами и контроллерами, очевидно можно. Если мы выбираем
 > контроллер но не процессор, то и компилятор (+среду разработки)
 > будем выбирать из предназначенных именно для контроллеров.

Hе вижу связи. Во времена оны прекрасно пользовался PC'шными средствами
разработки для контроллеров на базе х86.


С уважением, Дима Орлов.

Hello, Dima!
You wrote to Alexey Kovalev on Fri, 19 Nov 2004 19:00:00 +0300:

 DO> Hе вижу связи. Во времена оны прекрасно пользовался PC'шными
 DO> средствами разработки для контроллеров на базе х86.

       Не хочу контроллер из пня,
       Мне бы готовый МК.

With best regards, Alexey Kovalev

Hello, Alexey Kovalev !

 >>>     ОК. Так как с выбором не густо, спрошу "Какой либо другой язык
 >>> реализованный для 16-ти битных МК кроме С, asm, ну и Fort, конечно".
 >>> А дальше отфильтрую по субъективному критерию нравится - не нравится.

 >  DO> Под какие задачи язык?

 >     Распределенная система сбора и обработки информации. АСУ ТП.
 > Задачи контроллеров : нетривиальные  устройства сбора данных,
 > "черные ящики".

Какой у них интерфейс с АСУ ТП?

 > Вообще я не могу себе позволить под каждою задачу подбирать семейство
 > контроллеров. Иногда приходится пользоватся под что уже есть
 > средства разработки, да просто уже есть корпуса. Так что выбор должен
 > подразумевать некоторую гибкость.

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

 > ps: Под языком, подразумевается конкретная реализацией его, а не
 > что то абстрактное.

Конкретная реализация возможна только под конкретно указанный контроллер
(ядро)...

С уважением, Дима Орлов.

Hello, Dima!
You wrote to Alexey Kovalev on Fri, 19 Nov 2004 19:35:00 +0300:

 DO> Какой у них интерфейс с АСУ ТП?

Из родоначального письма этой темы видно что CAN.

 DO> Я так понимаю, что задачи у тебя достаточно низкоуровневые, и думаю,
 DO> что голый
 DO> С, ну может быть С++ будет вполне оправданным выбором

    в С мне многого не хватает. C++ да, без исп-я всех его возможностей.

 DO> Конкретная реализация возможна только под конкретно указанный
 DO> контроллер (ядро)...

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

With best regards, Alexey Kovalev