Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: eCos 3.0 for Microblaze
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
KOLOBOK123124356
Доброго всем времени суток. Работаю над портированием eCos 3.0 для Microblaze 8.2 в EDK 13.2. В качестве примера использовал mONeCos (http://www.monstr.eu/wiki/doku.php?id=ecos:ecos) - это порт eCos 2.0 на Microblaze 7.0. Много чего почерпнул оттуда, подправил код в соответствие со своей конфигурацией. Успешно запустил на своей плате eCos 2.0 из дистрибутива. Для сборки своего образа eCos 3.0 использовал GNU тулзы из дистрибутива mONeCos - microblaze-uclinux. Но при линковке получал ошибку : ../microblaze-uclinux/bin/ld.real: --relax and -r may not be used together. Потому линковал библиотеку extras.o из консоли командой. Затем собрал тесты eCos, но что насторожило, что размер всех тестов от 300 до 500 kb а вот тест, который собственно и нужен а именно tm_basic получился размером 50,5 Mb)) причем основную часть занимает .bss секция. Пробовал залить tm_basic тест и попрыгать по коду через GDB но в итоге Microblaze загибался с ошибкой “Microblaze pipeline stalled on a blocking instruction or invalid bus access”
Какие нибудь идеи по этому поводу?? в частности причины ошибки линовки и какой то чересчур большой размер tm_basic.elf

KOLOBOK123124356
Доброго всем времени суток! Теперь такая проблема: использую GNU tools из дистрибутива SDK 13.2, собираю с их помощью образ eCos 3.0. В итоге компиляция вылетает с ошибками в ассемблерном файле
/opt/project/s605_install/include/cyg/hal/arch.inc:78: Error: Macro with this name was already defined
/opt/project/s605_install/include/cyg/hal/arch.inc:84: Error: Macro with this name was already defined
/opt/project/s605_install/include/cyg/hal/arch.inc:111: Error: Macro with this name was already defined
никаких повторяющихся объявлений макросов нет. Может кто сталкивался или есть советы куда копать по поводу этих ерроров??
gosha
QUOTE (KOLOBOK123124356 @ Aug 26 2011, 22:26) *
Доброго всем времени суток! Теперь такая проблема: использую GNU tools из дистрибутива SDK 13.2, собираю с их помощью образ eCos 3.0. В итоге компиляция вылетает с ошибками в ассемблерном файле
/opt/project/s605_install/include/cyg/hal/arch.inc:78: Error: Macro with this name was already defined
/opt/project/s605_install/include/cyg/hal/arch.inc:84: Error: Macro with this name was already defined
/opt/project/s605_install/include/cyg/hal/arch.inc:111: Error: Macro with this name was already defined
никаких повторяющихся объявлений макросов нет. Может кто сталкивался или есть советы куда копать по поводу этих ерроров??


какие макросы пере- определены (стр 78 arch.inc)?
Как собираете? В отдельном дереве?
CODE
#ecosconfig --config=filename tree
#make


Собирал ecos кросс-коплилятором от Debian- всё было ok.

http://www.emdebian.org/debian/pool/main/g/gcc-4.1/
asket
Доброе время суток!
Поскольку тема про ecos, чтобы не создавать новый топик, хотел бы спросить где можно скачать полноценный пакет ecos с сопутствующими средствами разработки? Я в этом деле начинающий..
Зашел как-то на сайт https://www.ecoscentric.com/cgi/nph-epdk.cgi чтобы скачать пакет для at91sam9263-ek, но при попытке скачать, ругнулся что нужен контракт, eCOS разве несвободный?
gosha
тим всё выкачивается с помощью утилиты cvs

http://ecos.sourceware.org/anoncvs.html

snapshot:
http://hg-pub.ecoscentric.com/ecos/archive/tip.tar.bz2
http://hg-pub.ecoscentric.com/ecos/

Личто я пользуюсь для сборки кросс компиляторами от Debian.
http://www.emdebian.org/debian/pool/main/g/gcc-4.1/

Собираю на Debian 6.0 х86 инструментальной машине так:

#ecosconfig -- config= config_file_name.ecc tree
#make

config_file_name.ecc:
CODE
cdl_option CYGBLD_GLOBAL_COMMAND_PREFIX {
    # Flavor: data
    user_value mips-linux-gnu
    # value_source user
    # Default value: mipsisa32-elf
};


В прикреплённом файле: утилита ecosconfig c с исходниками собранная для debian 6 инструментальной машины.
И утилите gui конфигурации ./tools/bin/configtool.
KOLOBOK123124356
Здравствуйте! Возникла новая проблема при портировании eCos на Microblaze - сейчас работает UART, пытаюсь запустить тест tm_basic но при этом в системе не определяются системные тики. На сколько я понял тики генерятся от прерываний таймера, я настроил таймер чтобы давал прерывания каждые 10 мс. Что мне нужно допилить для определения в системе тиков??? Уже неделю бьюсь, помогите люди((
gosha
QUOTE (KOLOBOK123124356 @ Oct 18 2011, 14:30) *
Здравствуйте! Возникла новая проблема при портировании eCos на Microblaze - сейчас работает UART, пытаюсь запустить тест tm_basic но при этом в системе не определяются системные тики. На сколько я понял тики генерятся от прерываний таймера, я настроил таймер чтобы давал прерывания каждые 10 мс. Что мне нужно допилить для определения в системе тиков??? Уже неделю бьюсь, помогите люди((


Обработчик прерывания по таймеру работает?
Должен вызываться.hal_clock_initialize(CYGNUM_HAL_RTC_PERIOD);
Там должен обработчик прерывания по таймеру завеситься на нужное irq при помощи HAL_INTERRUPT_ATTACH()
После прерывания должны размаскироваться HAL_INTERRUPT_UNMASK()

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

Это работает?


Я бы еще поставил печать отладочных сообщений в ф-ии (вызываются они или нет):
void hal_clock_initialize(cyg_uint32 period)
void hal_clock_read(cyg_uint32 *pvalue)
void hal_clock_reset(cyg_uint32 vector, cyg_uint32 period)
asket
Вопрос новичка, у нас проблема с сетью, контроль трафика, прокси в домене и все такое, я хочу поставить на виртуальную машину ecos без подключения к сети, закачал два архива из http://sources-redhat.mirrors.airband.net/ecos/ , поставил без проблем gnutools, достаточно разархивировать и прописать путь в PATH, теперь хочу установить сам ecos, закачал из http://sources-redhat.mirrors.airband.net/...ses/ecos-3.0b1/ , далее я так понимаю нужно откомпилировать или что с ним делать? На официальном сатйе приводится порядок установки с помощью скрипта sh ecos-install.tcl, но у меня этот номер не работает, поскольку требует подключения сети, прошу помочь разобраться, как установить ecos не подключаясь к сети? Спасибо.
KOLOBOK123124356
Цитата(gosha @ Oct 20 2011, 12:58) *
Обработчик прерывания по таймеру работает?
Должен вызываться.hal_clock_initialize(CYGNUM_HAL_RTC_PERIOD);
Там должен обработчик прерывания по таймеру завеситься на нужное irq при помощи HAL_INTERRUPT_ATTACH()
После прерывания должны размаскироваться HAL_INTERRUPT_UNMASK()

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

Это работает?


Я бы еще поставил печать отладочных сообщений в ф-ии (вызываются они или нет):
void hal_clock_initialize(cyg_uint32 period)
void hal_clock_read(cyg_uint32 *pvalue)
void hal_clock_reset(cyg_uint32 vector, cyg_uint32 period)

Спасибо большое - все заработало
KOLOBOK123124356
Доброго всем времени суток! Настройка таймера прошла успешно, теперь запускается таймер, соответственно планировщик, появились наконец то системные тики, успешно запускаются тесты ядра, а именно tm_basic, вывод у них осуществляется через diag_printf(). Сейчас стоит задача запустить UART. С этим возникла проблема, а именно с обработчиком прерывания UART. При появлении прерывания от UART проц переходит на выполнение default_interrupt_isr, то есть затычки которая делает только return. Вообще судя по коду должен выполняться cyg_hal_plf_serial_isr, но этого не происходит. При запуске тестов из каталога io процессор просто крутит idle process. Помогите пожалуйста в чем может быть проблема?
asket
Может кто посоветует, где взять порты под ecos на плату at91sam9263-ek?
KOLOBOK123124356
Нужна помощь в запуске UART под eCos. На данный момент при появлении прерывания с UART проц переходит к обработчику прерывания по умолчанию - простой затычке, которая делает только return. Вообще должна вызываться функция обработки прерывания UART, которая описана в файле hal_diag.c

cyg_hal_plf_serial_isr(channel_data_t *chan, int *ctrlc,.
CYG_ADDRWORD vector, CYG_ADDRWORD data)
{
chan->ctrlc = ctrlc;
XUartNs550_InterruptHandler(&chan->dev);
HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector);
return CYG_ISR_HANDLED;
}

При инициализации channel 0 обявляется этот обработчик

void
cyg_hal_plf_serial_init(void)
{
hal_virtual_comm_table_t* comm;
int cur = CYGACC_CALL_IF_SET_CONSOLE_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);

// Disable interrupts.
HAL_INTERRUPT_MASK(channels[0].isr_vector);

// Init channels
init_serial_channel(&channels[0]);

// Setup procs in the vector table

// Set channel 0
CYGACC_CALL_IF_SET_CONSOLE_COMM(0);
comm = CYGACC_CALL_IF_CONSOLE_PROCS();
CYGACC_COMM_IF_CH_DATA_SET(*comm, &channels[0]);
CYGACC_COMM_IF_WRITE_SET(*comm, cyg_hal_plf_serial_write);
CYGACC_COMM_IF_READ_SET(*comm, cyg_hal_plf_serial_read);
CYGACC_COMM_IF_PUTC_SET(*comm, cyg_hal_plf_serial_putc);
CYGACC_COMM_IF_GETC_SET(*comm, cyg_hal_plf_serial_getc);
CYGACC_COMM_IF_CONTROL_SET(*comm, cyg_hal_plf_serial_control);
CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
CYGACC_COMM_IF_GETC_TIMEOUT_SET(*comm, cyg_hal_plf_serial_getc_timeout);
// Restore original console
CYGACC_CALL_IF_SET_CONSOLE_COMM(cur);
}

Но в итоге при появлении прерывания не проходит подтверждение прерывания (interrupt acknowledge), прерывание не сбрасывается и проц крутит постоянно обработку прерывания в виде return. Помогите разобраться в чем проблема?
gosha
QUOTE (KOLOBOK123124356 @ Oct 26 2011, 17:33) *
Доброго всем времени суток! Настройка таймера прошла успешно, теперь запускается таймер, соответственно планировщик, появились наконец то системные тики, успешно запускаются тесты ядра, а именно tm_basic, вывод у них осуществляется через diag_printf(). Сейчас стоит задача запустить UART. С этим возникла проблема, а именно с обработчиком прерывания UART. При появлении прерывания от UART проц переходит на выполнение default_interrupt_isr, то есть затычки которая делает только return. Вообще судя по коду должен выполняться cyg_hal_plf_serial_isr, но этого не происходит. При запуске тестов из каталога io процессор просто крутит idle process. Помогите пожалуйста в чем может быть проблема?

На требуемый вектор прерывания должен завеситься обработчик isr:

Обработчик завешивается?

http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos
CODE
    CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
static int
cyg_hal_plf_serial_isr(void *__ch_data, int* __ctrlc,
                       CYG_ADDRWORD __vector, CYG_ADDRWORD __data)
{
    int res = 0;
    channel_data_t* chan = (channel_data_t*)__ch_data;
    char c;
    cyg_uint8 lsr;
    CYGARC_HAL_SAVE_GP();

    cyg_drv_interrupt_acknowledge(chan->isr_vector);

    *__ctrlc = 0;
    HAL_READ_UINT8(chan->base+CYG_DEV_LSR, lsr);
    if ( (lsr & SIO_LSR_DR) != 0 ) {

        HAL_READ_UINT8(chan->base+CYG_DEV_RBR, c);
        if( cyg_hal_is_break( &c , 1 ) )
            *__ctrlc = 1;

    }

    res = CYG_ISR_HANDLED;
    
    CYGARC_HAL_RESTORE_GP();
    return res;
}



QUOTE (KOLOBOK123124356 @ Oct 28 2011, 12:53) *
Нужна помощь в запуске UART под eCos. На данный момент при появлении прерывания с UART проц переходит к обработчику прерывания по умолчанию - простой затычке, которая делает только return. Вообще должна вызываться функция обработки прерывания UART, которая описана в файле hal_diag.c

cyg_hal_plf_serial_isr(channel_data_t *chan, int *ctrlc,.
CYG_ADDRWORD vector, CYG_ADDRWORD data)
{
chan->ctrlc = ctrlc;
XUartNs550_InterruptHandler(&chan->dev);
HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector);
return CYG_ISR_HANDLED;
}

При инициализации channel 0 обявляется этот обработчик

void
cyg_hal_plf_serial_init(void)
{
hal_virtual_comm_table_t* comm;
int cur = CYGACC_CALL_IF_SET_CONSOLE_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);

// Disable interrupts.
HAL_INTERRUPT_MASK(channels[0].isr_vector);

// Init channels
init_serial_channel(&channels[0]);

// Setup procs in the vector table

// Set channel 0
CYGACC_CALL_IF_SET_CONSOLE_COMM(0);
comm = CYGACC_CALL_IF_CONSOLE_PROCS();
CYGACC_COMM_IF_CH_DATA_SET(*comm, &channels[0]);
CYGACC_COMM_IF_WRITE_SET(*comm, cyg_hal_plf_serial_write);
CYGACC_COMM_IF_READ_SET(*comm, cyg_hal_plf_serial_read);
CYGACC_COMM_IF_PUTC_SET(*comm, cyg_hal_plf_serial_putc);
CYGACC_COMM_IF_GETC_SET(*comm, cyg_hal_plf_serial_getc);
CYGACC_COMM_IF_CONTROL_SET(*comm, cyg_hal_plf_serial_control);
CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
CYGACC_COMM_IF_GETC_TIMEOUT_SET(*comm, cyg_hal_plf_serial_getc_timeout);
// Restore original console
CYGACC_CALL_IF_SET_CONSOLE_COMM(cur);
}

Но в итоге при появлении прерывания не проходит подтверждение прерывания (interrupt acknowledge), прерывание не сбрасывается и проц крутит постоянно обработку прерывания в виде return. Помогите разобраться в чем проблема?



Функция обработчика вызывается?
Снимается ли причина прерывания? Флаги наличия прерывания в UART?
Если снимается причина прерывания, я бы посмотрел макрос HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector); Флаги прерывания в регистрах контроллера до его вызова и после.
Разбирался бы с логикой работы контроллера прерываний.


QUOTE (asket @ Oct 27 2011, 10:35) *
Может кто посоветует, где взять порты под ecos на плату at91sam9263-ek?


Под мою плату также не было порта.
Я собирпл порт из кубиков (компонент из комплекта eCos) при помощи GUI утилиты настройки bp rjvgktrnf eCos : ./tools/bin/configtool

http://caxapa.ru/upload/files/58bbd5554bd7...83f4372e73d8f79
Стр 248
KOLOBOK123124356
Цитата(gosha @ Nov 1 2011, 08:02) *
На требуемый вектор прерывания должен завеситься обработчик isr:

Обработчик завешивается?

http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos
Код
    CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
static int
cyg_hal_plf_serial_isr(void *__ch_data, int* __ctrlc,
                       CYG_ADDRWORD __vector, CYG_ADDRWORD __data)
{
    int res = 0;
    channel_data_t* chan = (channel_data_t*)__ch_data;
    char c;
    cyg_uint8 lsr;
    CYGARC_HAL_SAVE_GP();

    cyg_drv_interrupt_acknowledge(chan->isr_vector);

    *__ctrlc = 0;
    HAL_READ_UINT8(chan->base+CYG_DEV_LSR, lsr);
    if ( (lsr & SIO_LSR_DR) != 0 ) {

        HAL_READ_UINT8(chan->base+CYG_DEV_RBR, c);
        if( cyg_hal_is_break( &c , 1 ) )
            *__ctrlc = 1;

    }

    res = CYG_ISR_HANDLED;
    
    CYGARC_HAL_RESTORE_GP();
    return res;
}






Функция обработчика вызывается?
Снимается ли причина прерывания? Флаги наличия прерывания в UART?
Если снимается причина прерывания, я бы посмотрел макрос HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector); Флаги прерывания в регистрах контроллера до его вызова и после.
Разбирался бы с логикой работы контроллера прерываний.




Под мою плату также не было порта.
Я собирпл порт из кубиков (компонент из комплекта eCos) при помощи GUI утилиты настройки bp rjvgktrnf eCos : ./tools/bin/configtool

http://caxapa.ru/upload/files/58bbd5554bd7...83f4372e73d8f79
Стр 248

Здравствуйте, спасибо за ответы. Я понимаю что CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr); привязывает обработчик прерывания, но не совсем понятен механизм привязки. У меня сейчас при появлении прерывания проц переходит на адрес 0x00000010 где содержится команда перехода на стандартный обработчик прерывания, который как я уже писал представляет собой простую затычку. Вопрос в том к какому прерыванию привязывает эта функция CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);??? Потому как cyg_hal_plf_serial_isr корректный обработчик прерывания, так как он выполняет HAL_INTERRUPT_ACKNOWLEDGE и по коду должен сбрасывать флаги прерывания и корректно его обрабатывать но нет привязки его к прерыванию от UART.

Насколько я понял в eCos существует 2 так называемых канала связи - консоль и отладочный канал через который как я понял работают стандартные diag_printf для вывода сообщений при выполнении тестов. Вот как раз отладочный канал работает без нареканий, то есть diag_printf выводит)) а вот если проводить запись с помощью API функций типа cyg_io_write то - все глухо, причем API функция cyg_io_lookup находит устройства /dev/ser0, /dev/tty но при записи в в эти устройства ничего не выводится.И еще такой вопрос - физически устройства для консольного и отладочного каналов должны быть разными?? потому как на плате только 1 UART порт, не совсем ясно потому как если они должны работать с разными физическими устройствами то rx tx надо распиновать отдельно и ставить еще один UART компонент, заранее спасибо за любую помощь в понимании вопроса
gosha
QUOTE (KOLOBOK123124356 @ Nov 1 2011, 11:50) *
Здравствуйте, спасибо за ответы. Я понимаю что CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr); привязывает обработчик прерывания, но не совсем понятен механизм привязки. У меня сейчас при появлении прерывания проц переходит на адрес 0x00000010 где содержится команда перехода на стандартный обработчик прерывания, который как я уже писал представляет собой простую затычку. Вопрос в том к какому прерыванию привязывает эта функция CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);??? Потому как cyg_hal_plf_serial_isr корректный обработчик прерывания, так как он выполняет HAL_INTERRUPT_ACKNOWLEDGE и по коду должен сбрасывать флаги прерывания и корректно его обрабатывать но нет привязки его к прерыванию от UART.

Насколько я понял в eCos существует 2 так называемых канала связи - консоль и отладочный канал через который как я понял работают стандартные diag_printf для вывода сообщений при выполнении тестов. Вот как раз отладочный канал работает без нареканий, то есть diag_printf выводит)) а вот если проводить запись с помощью API функций типа cyg_io_write то - все глухо, причем API функция cyg_io_lookup находит устройства /dev/ser0, /dev/tty но при записи в в эти устройства ничего не выводится.И еще такой вопрос - физически устройства для консольного и отладочного каналов должны быть разными?? потому как на плате только 1 UART порт, не совсем ясно потому как если они должны работать с разными физическими устройствами то rx tx надо распиновать отдельно и ставить еще один UART компонент, заранее спасибо за любую помощь в понимании вопроса


Привет!

Для моего процессора MIPS RM 7000 на все прерывания процессор прыгает по одному и тому же адресу, по которому находится ф-я:
main_exception_vsr()
http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos

Он вызывает ф-ю __ hal_intc_decode(), hal_intc_translate() которая анализирует регистры применяемого в Вашем случае контроллера прерываний.
" .macro hal_intc_decode vnum "
http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos
Находит соответсввия адресов обработчиков и номеров прерываний.
И вычисляет адрес обработчика прерывания.
Передает ему управление.

Для регистрации обработчиков в таблице векторов прерываний используется макрос:

#define HAL_INTERRUPT_ATTACH( _vector_, _isr_, _data_, _object_ )
#define HAL_INTERRUPT_DETACH( _vector_, _isr_ )
#define HAL_VSR_GET( _vector_, _pvsr_ )
#define HAL_VSR_SET( _vector_, _vsr_, _poldvsr_ )
#define HAL_INTERRUPT_ACKNOWLEDGE( _vector_ )
......
и прочие аналогичные:
http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos

По поводу cyg_io_write() я бы решал проблему, с помощью изучения исходных текстов и их редактирования (вставки выдачи отладочной информации, чтобы определить - какие ф- ии вызываются)

Мы, в основном, пользуемся только начальным загрузчиком Redboot.
В данном загрузчике есть команда "channel N" - переключение консоли.
Консолью, в нашем случае, может быть: VGA+keyb, RS-232, Telnet на 9000 порт.
При подаче команды: переключить консоль("channel 2<cr>"), diag_printf() начинает выдавать отладочную информацию только на эту консоль.

Смена консоли выполняется макросом
CYGACC_CALL_IF_SET_CONSOLE_COMM(chan);
CYGACC_CALL_IF_SET_DEBUG_COMM(chan);
См макросы поиском по исходным текстам eCos:
CYGACC_CALL_IF_CONSOLE_PROCS();
CYGACC_COMM_IF_PUTC(*__chan, c);
__chan = CYGACC_CALL_IF_DEBUG_PROCS();
CYGACC_COMM_IF_PUTC(*__chan, c);
hal_virtual_comm_table_t* __chan = CYGACC_CALL_IF_CONSOLE_PROCS();
CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT
и прочие...


Пример использования макроса:
http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos

В нашей начальной конфигурации Redboot, и в процессе работы: отладочный канал и консоль всегда совпадают.
KOLOBOK123124356
Здравствуйте! Спасибо за Ваши ответы. Как оказалось в системе обнаруживается устройство /dev/ttydiag и когда с помощью cyg_io_lookup получаю handler на него то затем нормально работает cyg_io_write. Но возникли проблемы по работе cyg_io_read.

cyg_io_read(handle, read_string, &len_read);
printf("Reading successful!!!\n");
printf(read_string);

При выполнении этого кода плата принимает по UART и сразу же выдает наружу до получения кода клавиши Enter. В смысле cyg_io_read принимает и сразу же выдает, после получения кода клавиши Enter я получаю сообщение "Reading succesful!!!" и выдается весь принятый массив. Это корректно??? потому как в документации не совсем понял функционал команды cyg_io_read.
gosha
QUOTE (KOLOBOK123124356 @ Nov 2 2011, 13:43) *
Здравствуйте! Спасибо за Ваши ответы. Как оказалось в системе обнаруживается устройство /dev/ttydiag и когда с помощью cyg_io_lookup получаю handler на него то затем нормально работает cyg_io_write. Но возникли проблемы по работе cyg_io_read.

cyg_io_read(handle, read_string, &len_read);
printf("Reading successful!!!\n");
printf(read_string);

При выполнении этого кода плата принимает по UART и сразу же выдает наружу до получения кода клавиши Enter. В смысле cyg_io_read принимает и сразу же выдает, после получения кода клавиши Enter я получаю сообщение "Reading succesful!!!" и выдается весь принятый массив. Это корректно??? потому как в документации не совсем понял функционал команды cyg_io_read.


Если честно, немного не понял, что происходит.
cyg_io_read() , в принципе, должен работать аналогично с read().
Может быть блокирующим и не- блокирующим. Что устанавливается макросами.
Не должен он ждать "\r\n". И возвращать количество прочитанных символов.
CYG_IO_SET_CONFIG_SERIAL_READ_BLOCKING()

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.