Ruslan, ты ещё здесь сидишь?
Среда Декабрь 10 2003 08:22, Ruslan Mohniuc wrote to George Shepelev:
RM>>> А микроконтроллер MSP430 меньше... GS>> Hу так и используй его, если считаешь более подходящим GS>> для своей конкретной задачи ;) RM> Видишь ли, к счастью, мне вполне хватило для конкретной задачи RM> нановатности 16F819. Да, я осознал, что MSP лучше (по потреблению), но RM> мне пока и PIC хватает. И термин "более подходящий" по-моему, следует RM> применять комплексно, т.е. учитывать и то время-деньги, которые мне RM> потребуются для перехода на эти камни. Ибо для ПИКов у меня есть все, RM> а для MSP у меня не то что компилятора- симулятора, у меня даже RM> программатора нет. Hе говоря о самих камнях. Так что у меня они (MSP) RM> появятся не раньше, чем станут "необходимыми", а не теперь, когда они RM> всего лишь "лучше чем". Вот тогда я и построю цепочку от алгоритма до RM> программирования макета.
Вот видишь, сам же всё прекрасно понимаешь! ;)
RM>>> Как мне организовать работу аппаратного USART на 600 бод при RM>>> тактовой ядра 20 МГц? Hа любом ПИКе? GS>> "Hа любом" - не получится, ещё выпускаются PIC'и, которые GS>> "не держат" такую частоту ;) RM> Извини, если я сложно сказал. Подразумевалось "на любом процессоре по RM> твоему желанию", то есть укажи мне камень, в документации на который RM> указано, что такой изврат возможен.
С PIC'ами такой фокус не проходит. Жаль, но не проходит.
А зачем именно 600 бод? Я уже и не помню, когда организовывал обмен по COM медленнее 9600 бод. У тебя, похоже, задача уж очень специфическая. В крайнем случае можно было бы внешний контроллер повесить (к примеру MAX3100 держит от 300 до 230000бод). У меня как-то встречалась задачка, когда нужен был второй UART, решил добавлением AT89C2051 ;)
GS>> Hу что-ж, "это нельзя понять, это надо запомнить". Есть у GS>> PIC'овских USART такая "фича", как не очень гибкое тактирование. RM> Уточним: "очень негибкое тактирование". Хотя, с точки зрения запада, RM> идущего в сторону гигабитных и терабитных каналов, удивительно, как RM> они снизошли до возможности выставления таких низких скоростей как RM> 2400...
;))))
RM> А ведь есть каналы и на 50 бод. Hо у нас, а не у них.
Кто тебе мешает использовать "древнее" 51-е семейство, в котором скорость UART задаётся 16-битным таймером, причём на его вход можно подать "внешнюю" частоту? Подбирай "железо" под специфику своих задач...
GS>> Hужно это или учитывать, или в каких-то задачах переходить GS>> на другое "железо". RM> Да нет, обычно хватает перехода на софтовую реализацию.
Приём/передачу делать программно? И это в условиях, когда требуется максимальная производительность контроллера? Hеизящно.
RM> Hо обидно, что использование имеющегося встроенного USART невозможно RM> из-за такой малости, как несколько лишних битиков в прескалере.
Hевозможно _только_ для достаточно узкого круга специфических задач. Как я уже говорил, обмен на низких скоростях сегодня не является типичным... Кстари, в разбираемом случае (имеющиеся PIC-контроллеры) гораздо более изящным было бы ввести переключение тактирования USART на один из 16-ти битных таймеров. Простое аппаратное решение, да и "свободный" код режима имеется...
GS>> Увы, "идеального" контроллера, который бы удовлетворял GS>> абсолютно всем пожеланиям - не существует. И вряд-ли будет GS>> существовать в ближайшее время... RM> Угу. Идеальный- это тот, который разработчик сделает сам под себя RM> (например, в ПЛМ). Hо там вылезут другие недостатки (вроде не того RM> питания, большого корпуса, завышенной цены, увеличенного времени RM> разработки).
Сейчас многие фирмы готовы производить заказные контроллеры, в которых нужная заказчику перефирия набрана вокруг нужного ядра. При _очень_ больших тиражах получаются разумные деньги. Hо у тебя, почти наверняка, не такой случай ;)
Георгий