реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> LPC2129 UART+PLL, Настройки PLL и UART
HSA
сообщение Feb 25 2005, 17:09
Сообщение #1


Участник
*

Группа: Свой
Сообщений: 42
Регистрация: 10-01-05
Из: Санкт-Петербург
Пользователь №: 1 862



Есть плата от МТ. Все работает, тикает и мигает.
Помогите разобраться с UART.

Подключаю PLL:

//Документ UM_LPC21XX_LPC22XX_2.pdf, стр.80
//Расчет PLL
//Частота кварца - Fosc = 11,059200 МГц
//Fcclk = 60 МГц
//M = Fcclk / Fosc = 5,42 (=5) В соответствии с табл. в рег-р записываем - 4
//Fcclk = 11,059200 * 5 = 55,296 МГц
//Fcco выбираем из интервала: 156МГц - 320МГц
//Fcco = 156 МГц
//P = 156 / (2*55,296)=1,41 (=2) В соответствии с табл. врег-р записываем 1.
//Fcco = 2*2*55.96=223.84МГц

PLLCFG_bit.MSEL=4;
PLLCFG_bit.PSEL=1;
feed();
PLLCON_bit.PLLE=1; // Enable the PLL
feed();
while(!(PLLSTAT & PLOCK)); // Wait for PLL to lock

//Init MAM & Flash memory fetch
MAMCR_bit.MODECTRL=2;
MAMTIM_bit.CYCLES=4;
VPBDIV_bit.VPBDIV=1;

Затем инициализирую UART:
unsigned int divisor = getperipheralClockFreq() / (16 * baud);
U0LCR_bit.DLAB=1; //Enable DLAB
U0LCR_bit.WLS=3; //8 bits
U0LCR_bit.SBS=1; //1 stop bit
U0DLL = (divisor&0xFF);//LSB(divisor);
U0DLM = ((divisor>>8)&0xFF);//MSB(divisor);
U0LCR_bit.DLAB=0; //Disable DLAB
PINSEL0 = PINSEL0 & ~0xF | 0x5;

Проблема в том, что когда работа без PLL - все работает, на компе с UART данные снимаю правильно. Как только пробую работать с PLL - UART выдает ошибки, вернее какую-то лобуду. Понимаю, что где-то в этих настройках (PLL или UART) я баг прописал. Но где не найду. Смотрел примеры и в даташите - так вроде все правильно. Да, то что регистры прописаны, как структуры - взял пример от IAR, там файл макросов есть - iolpc2129.h
Go to the top of the page
 
+Quote Post
-Tумблер-
сообщение Mar 2 2005, 11:20
Сообщение #2


Частый гость
**

Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040



Цитата(HSA @ Feb 25 2005, 20:09)
5,42 (=5)

*


А это не слишком ли большое округление ?
0.42 от 5.42 составит ~ 7.75 %.
sad.gif


--------------------

- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
Go to the top of the page
 
+Quote Post
fate
сообщение Mar 2 2005, 19:09
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 107
Регистрация: 12-01-05
Пользователь №: 1 915



Вот здесь очень внятно и понятно изложенно все про максимально допустимые ошибки при подсчете baud rate, это кусочек AVR datasheet, но именно это место общее для всех UART
Прикрепленные файлы
Прикрепленный файл  Async.pdf ( 52.78 килобайт ) Кол-во скачиваний: 147
 
Go to the top of the page
 
+Quote Post
-Tумблер-
сообщение Mar 3 2005, 11:35
Сообщение #4


Частый гость
**

Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040



Цитата(fate @ Mar 2 2005, 22:09)
это место общее для всех UART
*


Честно говоря, я не знаю точно, к каким именно последствиям приведет
указанное округление для ARM. Но для вообше UART-a
расчет выглядит так:

1. Очевидно, что если тактовая частота UART-a отличается
от стандартной, скорость UART-а будет отличаться от стандартной.
Как оценить допустимые пределы частоты ?
Очевидно, сначала нужно определиться с форматом передачи.
Допустим весьма распространенный случай: 8N2.
1 старт, 8 бит данных, 1 стоп = всего 10 бит.

2. если ошибка выбора в частоте составляет N процентов,
то ошибка в длительности во время пиема M бита составит: M*N.
Значит - 1% в частоте при приеме 10 бита составит 10% по длительности.

3. Существует еще постоянная, не накапливающаяся ошибка, вызванная
самим цифровым методом приема. Поскольку частота заполнения
бита выбирается обычно в 16 раз выше скорости - это значит
в худшем случае появится методическая погрешность 1/16 скорости.
Т.е. ~6%.

4. А какие наши резервы ?
Очевидно, чтобы правильно принять 10 бит, нельзя ошибиться >50%.
Поскольку биты принимаются "по серединкам".

5. Как будем делить эти 50 % ?
Во первых сразу:
50% - 6% = 44%.
Но эти 44 надо делить пополам.
Раз мы для себя делаем допуск, то очевидно и абонент
подключенный к нашему устройству имеет те же права.
44/2 = 22%. Это теоретически предельная ошибка в длительности
для правильного приема 10 бита.
Вот теперь и поделим на 10, чтобы узнать предельное отклонения
в частоте.
22/10 = 2.2 %.
Казалось бы, по даташиту еще более жестко.
Но на самом деле придется учитывать искажения драйверов/буферов.
Которые период импульсов конечно не изменят. А вот длительности - запросто.
Относительные длительности 0-й и 1-ц.
А если речь пойдет о гальванической развязке и оптронах, то .....
Так что 1 % - это еще многовато..
К этому 1 %, указанному в даташите, надо подходить творчески.
smile.gif


--------------------

- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
Go to the top of the page
 
+Quote Post
Karol
сообщение Mar 4 2005, 06:44
Сообщение #5


Участник
*

Группа: Новичок
Сообщений: 20
Регистрация: 23-06-04
Пользователь №: 150



Как работает ваша функция getperipheralClockFreq() ?
Если не ошибаюсь, она дложна вернуть 55296000.
Go to the top of the page
 
+Quote Post
HSA
сообщение Mar 5 2005, 13:59
Сообщение #6


Участник
*

Группа: Свой
Сообщений: 42
Регистрация: 10-01-05
Из: Санкт-Петербург
Пользователь №: 1 862



Цитата(Karol @ Mar 4 2005, 09:44)
Как работает ваша функция  getperipheralClockFreq() ?
Если не ошибаюсь, она дложна вернуть 55296000.
*


Да, так и возвращает.
Go to the top of the page
 
+Quote Post
HSA
сообщение Mar 5 2005, 14:06
Сообщение #7


Участник
*

Группа: Свой
Сообщений: 42
Регистрация: 10-01-05
Из: Санкт-Петербург
Пользователь №: 1 862



Спасибо всем, кто обратил внимание на эту ветку, так же как и за помощь. Раньше ответить не мог, не было доступа к инету.
С UART, к счастью, разобрался. Шлет, то штонужно и без багов. Осталось поднять АЦП... Буду очень благодарен, если кто поможет рзобраться. В мануале только несколько строк по нему, примеров не нашел, к сожалению. Теперь хоть можно через UART контролировать выполнение процесса.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 3rd June 2024 - 17:44
Рейтинг@Mail.ru


Страница сгенерированна за 0.01409 секунд с 7
ELECTRONIX ©2004-2016