[gormih 0]

Вообщем стоит такая задача - подобрать такой процессор, который будет способен дать поток данных около 4 мегабит по SPI, основным содержанием которого будут с АЦП того же процессора. Таких, как известно много, но есть одно "но" - процессор очень хочется найти в дубовом корпусе DIP, PDIP и прочее. Основная причина: Механическая прочность пайки независимо от квалификации монтажника (изделие практически еденичные (100 шт в год максимум), и паять их будут вручную), то есть технологичность изготовления самого изделия. Цена не напрягает :-)

 

ARM нашел только в соике, и их как то мало. Фрискэйл на своем фирменном сайте тупо не указал в парметрическом поиске типы корпусов... АВР в дип корпусах все слабые для этой задаче, пики тем более.

 

Если у кого нить есть инфа - прошу поделиться.

[DRUID3 0]

Ну разве что dsPIC таким извратом страдает, я DIP сам люблю за "совместимость" со стандартными макетками, но это уже ностальгия. О более мощных процах в DIP и слыхом не слыхивал.

 

P.S.: dsP - это у MicroCHIP загон такой, с их оперативой, тактовой и быстродействием они разве что для привода какого-нить сгодятся.

[ESL 0]

А может проще и дешевле вместо дипа использовать что-нибудь типа AVR-CRUMB128?

[gormih 0]

А может проще и дешевле вместо дипа использовать что-нибудь типа AVR-CRUMB128?

 

 

 

Отличная идея. Хотя наверняка не дешевле :-)

Но если не будет других вариантов...

 

 

Кстати именно AVR CRUMB128 не подойдет для данной задачи, так как там установлен проц Atmega128, который имеет тактовую частоту всего 16 Мгц максимум, что неприемлимо.

[=GM= 0]

Вообщем стоит такая задача - подобрать такой процессор, который будет способен дать поток данных около 4 мегабит по SPI, основным содержанием которого будут с АЦП того же процессора. Таких, как известно много, но есть одно "но" - процессор очень хочется найти в дубовом корпусе DIP, PDIP и прочее. Основная причина: Механическая прочность пайки независимо от квалификации монтажника (изделие практически еденичные (100 шт в год максимум), и паять их будут вручную), то есть технологичность изготовления самого изделия. Цена не напрягает :-)

 

ARM нашел только в соике, и их как то мало. Фрискэйл на своем фирменном сайте тупо не указал в парметрическом поиске типы корпусов... АВР в дип корпусах все слабые для этой задаче, пики тем более.

 

Если у кого нить есть инфа - прошу поделиться.

Ну, если основная задача - чтение АЦП и передача по SPI на скорости 4 мбит/с, то подойдёт любой АВР МК в дип корпусе, скажем, Atmega16 или даже ATtiny2313 (если только АЦП не 16-битный).

[rezident 0]

процессор очень хочется найти в дубовом корпусе DIP, PDIP и прочее. Основная причина: Механическая прочность пайки независимо от квалификации монтажника (изделие практически еденичные (100 шт в год максимум), и паять их будут вручную), то есть технологичность изготовления самого изделия. Цена не напрягает :-)

Не понял связи между DIPом и квалификацией монтажника. Качественно запаять TQFP-64 с шагом 0.5 на нормальной печатной плате ничуть не сложнее, чем DIP-40. Или планируется каждое изделие на макетке паять? Тогда, ой! :blink:

[gormih 0]

Ну, если основная задача - чтение АЦП и передача по SPI на скорости 4 мбит/с, то подойдёт любой АВР МК в дип корпусе, скажем, Atmega16 или даже ATtiny2313 (если только АЦП не 16-битный).

 

Не уверен... если взять тактовую частоту 16 МГц, то получается, что через каждые примерно (16/4)*8 = 32 такта процессор должен подготавливать новый байт данных, что даже при написании кода на языке ассемблера по моему нереализуемо.

Все же, понимая что всетаки по spi будет передаваться количество бит больше чем 8 за одну передачу, все равно встает задача другого порядка - хотелось бы данные, получаемые с АЦП некоторым (пока не ясно каким) образом успеть обработать. Какой нибудь простенький алгоритм для дальнейшего восстановления данных на принимающей части.

 

 

Не понял связи между DIPом и квалификацией монтажника. Качественно запаять TQFP-64 с шагом 0.5 на нормальной печатной плате ничуть не сложнее, чем DIP-40. Или планируется каждое изделие на макетке паять? Тогда, ой! :blink:

 

Это только кажется. В тех условиях, что работают люди на моем предприятии - это совсем не так, поверьте. Здесь даже провода к разъему иногда нормально не могут припаять, чего уж говорить о TQFP с шагом 0.5 :(

[mse 0]

Это только кажется. В тех условиях, что работают люди на моем предприятии - это совсем не так, поверьте. Здесь даже провода к разъему иногда нормально не могут припаять, чего уж говорить о TQFP с шагом 0.5 :(

Бли-ин...Даже китайтсы умеют. Надо дрессировать, аназначна.

[SM 0]

Это только кажется. В тех условиях, что работают люди на моем предприятии - это совсем не так, поверьте. Здесь даже провода к разъему иногда нормально не могут припаять, чего уж говорить о TQFP с шагом 0.5 :(

 

Так если это Ваше предприятие, то либо смените людям условия, либо займитесь чем либо другим :)

[gormih 0]

Так если это Ваше предприятие, то либо смените людям условия, либо займитесь чем либо другим :)

 

Это не совсем в моих полномочиях - менять услвовия. Приходится подстраиваться под то, что есть. Предприятие не моё, я всего лишь рядовой разработчик на нем.

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

[=GM= 0]

Ну, если основная задача - чтение АЦП и передача по SPI на скорости 4 мбит/с, то подойдёт любой АВР МК в дип корпусе, скажем, Atmega16 или даже ATtiny2313 (если только АЦП не 16-битный).

Не уверен... если взять тактовую частоту 16 МГц, то получается, что через каждые примерно (16/4)*8 = 32 такта процессор должен подготавливать новый байт данных, что даже при написании кода на языке ассемблера по моему нереализуемо.

Ещё как реализуемо! Взять байт из порта и пихнуть его в регистр SPI займет ровно 2 такта, остальные 30 - ваши! Вгрубе, 28/30 времени, т.е. 93%, процессор будет простаивать! Можно и по прерыванию сделать. Поищите на форуме АВР МК, там была тема передачи по SPI на скорости 8 мбит/с, я даже код приводил, причем проц простаивал ~50% времени.

 

Все же, понимая, что всё-таки по spi будет передаваться количество бит больше чем 8 за одну передачу, все равно встает задача другого порядка - хотелось бы данные, получаемые с АЦП некоторым (пока не ясно каким) образом успеть обработать. Какой нибудь простенький алгоритм для дальнейшего восстановления данных на принимающей части.

Многое зависит от алгоритма, конечно. Если хотите как-то обрабатывать, фильтровать там или еще что, не парьтесь, ставьте ДСП и забудьте про дип.

[SpyBot 0]

Ну, если основная задача - чтение АЦП и передача по SPI на скорости 4 мбит/с, то подойдёт любой АВР МК в дип корпусе, скажем, Atmega16 или даже ATtiny2313 (если только АЦП не 16-битный).

Не уверен... если взять тактовую частоту 16 МГц, то получается, что через каждые примерно (16/4)*8 = 32 такта процессор должен подготавливать новый байт данных, что даже при написании кода на языке ассемблера по моему нереализуемо.

Ещё как реализуемо! Взять байт из порта и пихнуть его в регистр SPI займет ровно 2 такта, остальные 30 - ваши! Вгрубе, 28/30 времени, т.е. 93%, процессор будет простаивать! Можно и по прерыванию сделать. Поищите на форуме АВР МК, там была тема передачи по SPI на скорости 8 мбит/с, я даже код приводил, причем проц простаивал ~50% времени.

 

Все же, понимая, что всё-таки по spi будет передаваться количество бит больше чем 8 за одну передачу, все равно встает задача другого порядка - хотелось бы данные, получаемые с АЦП некоторым (пока не ясно каким) образом успеть обработать. Какой нибудь простенький алгоритм для дальнейшего восстановления данных на принимающей части.

Многое зависит от алгоритма, конечно. Если хотите как-то обрабатывать, фильтровать там или еще что, не парьтесь, ставьте ДСП и забудьте про дип.

 

Не, ну конечно 2 такта это слишком оптимистично, т.к. данные надо ещё забрать, сформировать строб для АЦП и т.д. Другое дело, что можно глянуть CPLD в корпусе PLCC. Либо у техаса древние ДСП-контроллеры в PLCC были.

[=GM= 0]

Не, ну конечно 2 такта это слишком оптимистично, т.к. данные надо ещё забрать, сформировать строб для АЦП и т.д. Другое дело, что можно глянуть CPLD в корпусе PLCC. Либо у техаса древние ДСП-контроллеры в PLCC были.

Не надо никакой CPLD в корпусе PLCC. Вот код

    in   r16,portd    ;1mc
    out  spdr,r16     ;1mc

Ну а стробы для АЦП надо формировать с помощью таймера и модуля сравнения, т.е. аппаратно, эт-да, само собой разумеется.

[gormih 0]

вообщем понятно - самым оптимальным считаю вот такое решение.

Всем спасибо за помощь :a14:

[npu3pak13 0]

Что ты мучаешься - поставь БлекФин 531\532 в LQFP

частота до 400 МГц быстрые SPI :)