[drozel 0]

+1. Запустить UART - это вообще тривиально.

Ну тривиально, тривиально. Также, как и SPI. Может я неправильно устроен, но, когда я таскаю из проекта в проект вывод printf в UART/USB, мне хочется запихать это уже в законченный .c + .h и подключать, как модуль.

А ведь периферии много. И UARTов может быть много, а это, как правильно подметили, 1% от серьезной программы. Код неплохо было бы иметь читаемый, а не CR |= 0x01b1;

Изменено 6 октября, 2015 пользователем drozel

[ViKo 1]

Код неплохо было бы иметь читаемый, а не CR |= 0x01b1;

Например:

  USART2->CR1 =
    USART_CR1_SBK        * 0 |    // Send Break
    USART_CR1_RWU        * 0 |    // Receiver wakeup
    USART_CR1_RE        * 1 |    // Receiver Enable
    USART_CR1_TE        * 1 |    // Transmitter Enable
    USART_CR1_IDLEIE    * 0 |    // IDLE Interrupt Enable
    USART_CR1_RXNEIE    * 1 |    // RXNE Interrupt Enable
    USART_CR1_TCIE        * 0 |    // Transmission Complete Interrupt Enable
    USART_CR1_TXEIE        * 0 |    // TE Interrupt Enable
    USART_CR1_PEIE        * 0 |    // PE Interrupt Enable
    USART_CR1_PS        * 0 |    // Parity Selection - Even
    USART_CR1_PCE        * 0 |    // Parity Control Enable
    USART_CR1_WAKE        * 0 |    // Wakeup method
    USART_CR1_M        * 0 |    // Word length: 1 Start bit, 8 Data bits, n Stop bit
    USART_CR1_UE        * 1 |    // USART Enable
    USART_CR1_OVER8        * 0;    // USART Oversampling by 8 enable

[Golikov 0]

Дак так и получается, если делать не один проект, то все-равно дорабатываешь либы под себя и убираешь ошибки. Но ИМХО, писать с нуля, например усб стеки - ну это для отпетых "гурманов"

не путайте теплое с мягким....

 

Одно дело написать один свой, нужный именно тебе функционал и проверить его.

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

 

При этом он (куб) реально очень перепутанный и на много что завязан, так что фиг его просто сократишь до нужного.

 

 

 

 

 

 

 

[_Pasha 0]

Сабж нормальный. Но API в некоторых местах не нравится.

Именно, gpio , rcc и dma

Нужно более юзабельные вещи.

gpio вообще хорошо бы кросс-платформенным сделать

т.е. настройка пинов как в SPL - с одним аргументом указателем на структуру.

Структура является надмножеством всех известных опций для нескольких архитектур.

 

rcc - управление клоками и ресетом - лучше с привязкой к адресу периферии.

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

в принципе - небольшая табличка во флеше решает проблемы с необходимостью лазать по даташиту.

 

 

[drozel 0]

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

в принципе - небольшая табличка во флеше решает проблемы с необходимостью лазать по даташиту.

Ну так это и есть библиотека более высокого уровня. Что-то вроде того и реализовано в Cube, но, говорят много ошибок и недоработок.

[_Pasha 0]

Ну так это и есть библиотека более высокого уровня. Что-то вроде того и реализовано в Cube, но, говорят много ошибок и недоработок.

Из куба один раз попробовал запустить что-то с usb, быстро перехотелось.

 

Высокого уровня... вот например - годами одна и та же функция настройки

int uart_setup( // >0 - configured yet 0-service busy <0 - error
    char n,// which one 
    baud_t baud, // may be long or int32 
    char bits,      // ['5'..'9']
    char parity,  // ['E','O','N']
    char stops); // ['1','2']

не включает в себя экзотику типа multiprocessor mode или 1.5 стопа

но я что-то не припомню когда ими пользовался...

 

 

 

 

[drozel 0]

Люди, помогите с либой.

Пытаюсь завести USB CDC с libopencm3 и вот этим примером.

Я допускаю, что туплю, библиотека написана с каким то жонглированием указателями, которое мне пока непривычно + пришлось немного портировать на IAR, т.к. либа содержит много директив от GCC. На данный момент USB поднимается, но устройство не опознается, PID и VID комп видит нулевые.

Конкретный вопрос:

usbd_device *usbd_init(const usbd_driver *driver,
               const struct usb_device_descriptor *dev,
               const struct usb_config_descriptor *conf,
               const char **strings, int num_strings,
               uint8_t *control_buffer, uint16_t control_buffer_size)
{
    usbd_device *usbd_dev;

    usbd_dev = driver->init();

    usbd_dev->driver = driver;
    usbd_dev->desc = dev;
    usbd_dev->config = conf;
    usbd_dev->strings = strings;
    usbd_dev->num_strings = num_strings;
    usbd_dev->ctrl_buf = control_buffer;
    usbd_dev->ctrl_buf_len = control_buffer_size;

    usbd_dev->user_callback_ctr[0][USB_TRANSACTION_SETUP] =
        _usbd_control_setup;
    usbd_dev->user_callback_ctr[0][USB_TRANSACTION_OUT] =
        _usbd_control_out;
    usbd_dev->user_callback_ctr[0][USB_TRANSACTION_IN] =
        _usbd_control_in;

    int i;
    for (i = 0; i < MAX_USER_SET_CONFIG_CALLBACK; i++) {
        usbd_dev->user_callback_set_config[i] = NULL;
    }

    return usbd_dev;
}

Что при этом возвращает функция? Указатель на локальную переменную (стек)?

Ведь переменная локальная, выделена не динамически. Я просто в ступоре.

 

---

UPD все, наладил, проблема была у меня.

Тем не менее, прошу ликбеза по си..

Изменено 8 октября, 2015 пользователем drozel

[SapegoAL 0]

Что при этом возвращает функция? Указатель на локальную переменную (стек)?

Функция возвращает указатель на структуру типа usbd_device. То есть фактически, на адрес в памяти, где находится переменная.

Ведь переменная локальная, выделена не динамически. Я просто в ступоре.

Локальная - не есть выделенная динамически. Локальная выделяется на стеке и уничтожается при выходе из процедуры (точнее становится непредсказуемой). Выделена динамически, значит размещена на куче. Она уничтожается только явно процедурой free.

В данном случае локально объявляется указатель. Далее запускается driver->init(), что похоже динамически выделяет память и инициализирует структуру. П/п возвращает этот указатель.

В чём вопрос?

[drozel 0]

В чём вопрос?

Да, запарился с этой либой, затупил.

[_Pasha 0]

usbd_device *usbd_init

возвращает указатель на static а не локальную.

usbd_dev = driver->init(); здесь он получает указатель

 

этот статик хранится в физике типа usb_f103.c и иже с ними

просто он там потому что самое большое число связей с ним именно там.

[drozel 0]

Да, уже нашел, спасибо. Просто непривычно: вместо того, чтоб сделать ее глобальной делают ее глобальным статиком и передают указатель через череду фукнций.

Более правильно, согласен.

В стдлибе от СТМ кстати, именно глобальные структуры

Изменено 9 октября, 2015 пользователем drozel

[esaulenka 7]

Да, уже нашел, спасибо. Просто непривычно: вместо того, чтоб сделать ее глобальной делают ее глобальным статиком и передают указатель через череду фукнций.

Более правильно, согласен.

Ну это такой сиплюсплюс из костылей: "класс" логики работает с "классом" физического драйвера через указатель на последний.

Если понимать принципы C++, всё понятно и очевидно.

Но работать всё равно неудобно - IDE не "прыгает" при чтении кода к соотв. функции, да и ошибиться при заполнении структуры с указателями куда легче...

[drozel 0]

Почти мигрировал с stdlib и cube на сабж.

Остался вопрос, нужна помощь.

Где файл, прописывающий в память таблицу векторов прерываний? В stdlib был стартап файл на асме, здесь уже перерыл все, в упор не вижу.

[_Pasha 0]

Почти мигрировал с stdlib и cube на сабж.

Остался вопрос, нужна помощь.

Где файл, прописывающий в память таблицу векторов прерываний? В stdlib был стартап файл на асме, здесь уже перерыл все, в упор не вижу.

это содержимое папки dispatch и далее по дефайну.

 

 

 

собирайте сразу в статик либу. гемора потом вообще 0.0%

правда, я перед этим выдрал из usb отдельно SCSI и компильнул либы без него.

потому что msc полно сюрпризов.

 

[drozel 0]

это содержимое папки dispatch и далее по дефайну.

Там 2 файла: vector_chipset.c и vector_nvic.c

Первый инклудит аналогичный файл из папки f4 (в моем случае), который просто включает сопроцессор:

static void pre_main(void)
{
    /* Enable access to Floating-Point coprocessor. */
    SCB_CPACR |= SCB_CPACR_FULL * (SCB_CPACR_CP10 | SCB_CPACR_CP11);
}

 

Второй соответственно ищет vector_nvic.c в папке семейства, но его там нет.

 

Зато есть зацепка в папке scripts, скрипт irq2nvic_h, вроде на питоне (судя по строке #!/usr/bin/env python), содержащий, помимо всего прочего,такие строки

"""Generate an nvic.h header from a small JSON file describing the interrupt
numbers.

Code generation is chosen here because the resulting C code needs to be very
repetetive (definition of the IRQ numbers, function prototypes, weak fallback
definition and vector table definition), all being very repetitive. No portable
method to achive the same thing with C preprocessor is known to the author.
(Neither is any non-portable method, for that matter.)"""

 

Я на питоне не силен, скачал интерпретатор под винду, пытаюсь его как-то запустить. Пока неудачно, но это вопрос скорее в тему по питону.