Перейти к содержанию
Поиск
    

repstosw

Участник
 Профиль  Обзор контента

  • Постов

    2 582

  • Зарегистрирован

  • Победитель дней

    2

 Тип контента 

Сообщения, опубликованные repstosw

  1. Опубликовано · Пожаловаться

    1 minute ago, Arlleex said:

    Полагаю, Вам нужен run-time, т.к. аргументом вызова clz() Вы хотите использовать переменную (не константу).

    да

    12 minutes ago, Arlleex said:

    P.S. CLang (ARM Compiler 6) у Keil-а из коробки поддерживает все расширения GCC - может, сойдет за аргумент к переходу.

    Насколько шланг компилирует более быстрый код по сравнению с GCC?

    Все проекты компилирую с флагом -Ofast.

  2. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    Плюс ещё на V3s для нормальной работы USB в режиме Device (виртуальный диск, который видится на ПК) надо произвести запись в этот регистр: 

    #define USB_OTG_REG_BASE 0x01C19000 /* базовый адрес регистров USB OTG */

*(IO u32*)(USB_OTG_REG_BASE+0x410)=0; //разрешает USB быть в режиме Device. Был =2

    Иначе, когда грузишься автономно с SPI NOR или SD карты, ПК не видит соединение.

    Нашёл этот регистр с помощью сравнения двух снятых дампов - с sunxi-fel и без него.

    • Upvote 1

  3. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    14 minutes ago, Arlleex said:

    Вам compile-time или run-time версия нужна?

    чем быстрее, тем лучше

    14 minutes ago, Arlleex said:

    Этого не было ни в C, ни в C++, вроде, никогда. В C23 - будет официально на уровне стандарта. На данный момент typeof - тоже расширение.

    Вот здесь oно нужно: 

    #define ALIGN(x, a) (((x) + ((typeof(x))(a) - 1)) & ~((typeof(x))(a) - 1))
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)

    Пока что сделал так: 

    #define ALIGN(x, a) (((x) + ((a) - 1)) & ~((a) - 1))
#define IS_ALIGNED(x, a) (((x) & ((a) - 1)) == 0)

     

    14 minutes ago, Arlleex said:

    P.S. CLang (ARM Compiler 6) у Keil-а из коробки поддерживает все расширения GCC - может, сойдет за аргумент к переходу.

    Не я решаю.

    Для себя пишу на GCC. Не вижу смысла лезть в Keil для Cortex A7.

  4. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    1 hour ago, haker_fox said:

    Всмысле?) Вроде есть. В документации это описано.

    И это: 

     struct 
 {
  ehci_qhd_t  qhd[HCD_MAX_ENDPOINT] __attribute__ ((aligned(32)));
  ehci_qtd_t  qtd[HCD_MAX_XFER] __attribute__ ((aligned(64)));
  ehci_itd_t  itd[EHCI_MAX_ITD]   __attribute__ ((aligned(128)));
  ehci_sitd_t sitd[EHCI_MAX_SITD]  __attribute__ ((aligned(256)));
 }device[CFG_TUSB_HOST_DEVICE_MAX];

     

    55 minutes ago, jcxz said:

    Имхо - для embedded-программиста должно быть само собой разумеющимся уметь читать и воспринимать значения в hex. Примерно так же как - уметь читать мануалы на англ.

    Это всего лишь мнение. Позвольте не согласиться.

    Лично мне иногда удобнее в двоичной системе счисления работать - в каких-то случаях это нагляднее,  a не разворачивать тетрады в уме 🙂

    55 minutes ago, jcxz said:

    А где тут "ссылки на себя"? У вас ссылки на сторонний typedef, а не "на себя". И ругается он на то, что дважды его пытаетесь объявлять. Объявление структуры тут вообще не при чём. Ругается на дублирующееся объявление typedef.

    Выдал предупреждение на этом фрагменте:

    Spoiler 
    typedef struct _sensor sensor_t;
typedef struct _sensor {
    sensor_id_t id;             // Sensor ID.
    uint8_t  slv_addr;          // Sensor I2C slave address.
    pixformat_t pixformat;
    camera_status_t status;
    int xclk_freq_hz;

    // Sensor function pointers
    int  (*init_status)         (sensor_t *sensor);
    int  (*reset)               (sensor_t *sensor);
    int  (*set_pixformat)       (sensor_t *sensor, pixformat_t pixformat);
    int  (*set_framesize)       (sensor_t *sensor, framesize_t framesize);
    int  (*set_contrast)        (sensor_t *sensor, int level);
    int  (*set_brightness)      (sensor_t *sensor, int level);
    int  (*set_saturation)      (sensor_t *sensor, int level);
    int  (*set_sharpness)       (sensor_t *sensor, int level);
    int  (*set_denoise)         (sensor_t *sensor, int level);
    int  (*set_gainceiling)     (sensor_t *sensor, gainceiling_t gainceiling);
    int  (*set_quality)         (sensor_t *sensor, int quality);
    int  (*set_colorbar)        (sensor_t *sensor, int enable);
    int  (*set_whitebal)        (sensor_t *sensor, int enable);
    int  (*set_gain_ctrl)       (sensor_t *sensor, int enable);
    int  (*set_exposure_ctrl)   (sensor_t *sensor, int enable);
    int  (*set_hmirror)         (sensor_t *sensor, int enable);
    int  (*set_vflip)           (sensor_t *sensor, int enable);

    int  (*set_aec2)            (sensor_t *sensor, int enable);
    int  (*set_awb_gain)        (sensor_t *sensor, int enable);
    int  (*set_agc_gain)        (sensor_t *sensor, int gain);
    int  (*set_aec_value)       (sensor_t *sensor, int gain);

    int  (*set_special_effect)  (sensor_t *sensor, int effect);
    int  (*set_wb_mode)         (sensor_t *sensor, int mode);
    int  (*set_ae_level)        (sensor_t *sensor, int level);

    int  (*set_dcw)             (sensor_t *sensor, int enable);
    int  (*set_bpc)             (sensor_t *sensor, int enable);
    int  (*set_wpc)             (sensor_t *sensor, int enable);

    int  (*set_raw_gma)         (sensor_t *sensor, int enable);
    int  (*set_lenc)            (sensor_t *sensor, int enable);

    int  (*get_reg)             (sensor_t *sensor, int reg, int mask);
    int  (*set_reg)             (sensor_t *sensor, int reg, int mask, int value);
    int  (*set_res_raw)         (sensor_t *sensor, int startX, int startY, int endX, int endY, int offsetX, int offsetY, int totalX, int totalY, int outputX, int outputY, bool scale, bool binning);
    int  (*set_pll)             (sensor_t *sensor, int bypass, int mul, int sys, int root, int pre, int seld5, int pclken, int pclk);
    int  (*set_xclk)            (sensor_t *sensor, int timer, int xclk);
} sensor_t;

     

     

  5. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    1 hour ago, haker_fox said:

    Где-то с IAR 9.10 появилась поддержка таких литералов.

    Ломаная версия 9.10 или старше есть в интернете?  Для себя пишу на GCC, но некоторые требуют IAR.

    Вот ещё несколько недостатков IAR:

    3) Встроенные функции подсчёта ведущих нулей или нулей с конца:  __builtin_clz(), __builtin_ctz().  Встречаются в некоторых проектах.

    Нашёл имплементацию здесь: https://embeddedgurus.com/state-space/tag/clz

    4) Нет поддержки typeof

    5) Нет поддержки выравнивания членов структуры

     

  6. Опубликовано · Пожаловаться

    Ещё пара минусов в репу IAR:

    1) отсутствует поддержка бинарных литералов - создаёт неудобства при переносе кода с GCC: 

    #define MIPI_CSI2_VCDT_RX_REG_VCDT(vc, dt) (((vc & 3 /*0b11*/ ) << 6) | (dt & 0x3F /*0b111111*/ )) /* IAR не понимает бинарных литералов */

    2) На объявления структуры со ссылками на себя - выдаёт предупреждение:

    Quote

    Warning[Pe301]: typedef name has already been declared (with same type) 

    typedef struct _sensor sensor_t;
typedef struct _sensor {
//...
    // Sensor function pointers
    int  (*init_status)         (sensor_t *sensor);
    int  (*reset)               (sensor_t *sensor);
//...
} sensor_t;

    Или я ошибаюсь?  IAR 8.50

  7. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    Пришлось временно вернуться к V3s. Провёл ревизию и кастомизацию узла захвата изображения с камеры OV5640 с MIPI CSI2 и H264 кодера.

    Выжал 1920x1080@30FPS. Пришлось поднять битрейт MIPI-лейнам до 500 Мбит/с (по умолчанию 400, максимум 1000).

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

    И кстати, схема захвата кадров с камеры (CSI) у V3s не имеет двойной буферизации. Возникла задача: как читать буфер кадра, чтобы он не накрывался новыми данными (захват работает и пишет в буфер непрерывно, когда камера в потоковом режиме - VCAP).  Иначе несколько строк сверху в кадре брались от нового захвата.

    Для этого нужно использовать два прерывания от CSI:  VSYNC_TRIG и FRAME_DONE.  Когда приходит первое - меняем адрес буфера, когда приходит второе - читаем предыдущий буфер.  В этом случае данные при чтении не накрываются новыми.

    Если же использовать одиночный захват кадра с камеры (SCAP вместо VCAP), то максимально достижимый FPS будет в 2 раза меньше, чем у VCAP. Так как в этом режиме схема захвата ждёт прихода нового кадра и пропускает текущий.

    На 1920x1080 H264 кодер вывозит сжатие на 63 ... 70 FPS (зависит от картинки, установлен уровень квантования QP=24).

    Лог в спойлере:

    Spoiler 
    === V3s OV5640 Camera @ MIPI CSI2 ===
sensor write retry=1
Width: 1920, Height: 1080
VE version 0x1681 opened
Formatting...
Disk Format OK!
Disk Mount OK!
Disk Label OK!
Encoding...

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.2 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.7 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    70.2 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    70.1 FPS 14.3 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.1 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.9 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.1 FPS 14.5 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    68.8 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.3 FPS 14.6 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    68.2 FPS 14.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    67.7 FPS 14.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    66.2 FPS 15.1 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    65.9 FPS 15.2 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    65.6 FPS 15.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    65.1 FPS 15.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    65.0 FPS 15.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.7 FPS 15.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.1 FPS 15.6 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    63.4 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    62.8 FPS 15.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    62.9 FPS 15.9 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    62.9 FPS 15.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    62.7 FPS 16.0 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    62.7 FPS 16.0 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    62.8 FPS 15.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    62.9 FPS 15.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.1 FPS 15.9 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    62.8 FPS 15.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    62.7 FPS 16.0 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.1 FPS 15.9 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    63.7 FPS 15.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.4 FPS 15.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.8 FPS 15.7 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    64.6 FPS 15.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    65.1 FPS 15.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.8 FPS 15.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    65.3 FPS 15.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    65.7 FPS 15.2 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    66.8 FPS 15.0 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    66.9 FPS 14.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.0 FPS 14.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    67.9 FPS 14.7 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    68.3 FPS 14.6 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.2 FPS 14.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.1 FPS 14.7 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    68.1 FPS 14.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.2 FPS 14.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    67.8 FPS 14.7 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    66.4 FPS 15.1 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.7 FPS 15.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.6 FPS 15.5 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    63.5 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.1 FPS 15.8 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    63.3 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.4 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.4 FPS 15.8 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    61.7 FPS 16.2 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.1 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.5 FPS 15.8 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    63.5 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.7 FPS 15.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.6 FPS 15.7 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    63.5 FPS 15.8 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.6 FPS 15.7 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    63.9 FPS 15.6 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    64.0 FPS 15.6 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.0 FPS 15.6 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    64.5 FPS 15.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    65.2 FPS 15.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    65.6 FPS 15.2 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    65.5 FPS 15.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    67.0 FPS 14.9 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    67.3 FPS 14.9 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    68.8 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.1 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.2 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.7 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    70.3 FPS 14.2 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.0 FPS 14.5 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.2 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.2 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.2 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.7 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.2 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.2 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.9 FPS 14.5 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Fme: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.7 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.7 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    70.2 FPS 14.2 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.7 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.5 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.6 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.3 FPS 14.4 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.8 FPS 14.3 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.5 FPS 14.6 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    68.6 FPS 14.6 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.0 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.1 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.4 FPS 14.4 ms

Camera Capture Frame: 30.3 FPS 33.0 ms
H264 Encode Frame:    69.0 FPS 14.5 ms

Camera Capture Frame: 30.1 FPS 33.2 ms
H264 Encode Frame:    69.0 FPS 14.5 ms
...

     

     

  8. Опубликовано · Пожаловаться

    5 hours ago, sasamy said:

    интересное тут

    Quote

    -lm_nano -lgcc -lc_nano -lgcc --start-group -lgcc -lc_nano -lnosys --end-group --start-group -lgcc -lc_nano -lnosys --end-group

     

    Кольцевые зависимости.  Впервые с этим сталкиваюсь именно в этом тулчейне.

    https://stackoverflow.com/questions/5651869/what-are-the-start-group-and-end-group-command-line-options

  9. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    52 minutes ago, sasamy said:

    а так если

    -lgcc -lm -lgcc

    Не собирает.

    Нашёл правильный порядок следования библиотек. lgcc.a с включенной секцией /DISCARD/ вообще не нужно указывать.  Строка сборки: 

    xtensa-hifi4-gcc -nostartfiles -nostdlib -nodefaultlibs -ffreestanding -ftree-vectorize -fno-math-errno ^
-u_printf_float -Llibhal -Llibjpeg8 -Llibspeexdsp -Llibcelt -T hifi4.lds -Wl,--gc-sections -Wl,--static -Wl,--strip-all ^
 ^
startup_s.o ^
startup_c.o ^
...
main.o ^
-o main.elf -Xlinker -Map=main.map ^
-ljpeg8 -lspeexdsp -lcelt -lhal -lm_nano -lc_nano -lnosys

    С выключенной секцией DISCARD: 

    %TOOLCHAIN%gcc -nostartfiles -nostdlib -nodefaultlibs -ffreestanding -ftree-vectorize -fno-math-errno ^
-u_printf_float -Llibhal -Llibjpeg8 -Llibspeexdsp -Llibcelt -T hifi4.lds -Wl,--gc-sections -Wl,--static -Wl,--strip-all ^
 ^
startup_s.o ^
...
main.o ^
-o main.elf -Xlinker -Map=main.map ^
-ljpeg8 -lspeexdsp -lcelt -lhal -lm_nano -lgcc -lc_nano -lnosys

    При этом важно, чтобы libgcc было после libm_nano. Иначе не собирается.  В обоих случаях - пользовательские библиотеки должны быть указаны раньше стандартных.

    Проект заработал в обоих случаях. Размер бинарника одинаковый.

     

    Собранный тулчейн для 32-битный винды (ABI call0, GCC v. 13): https://drive.google.com/drive/folders/1khQNuruBZ6ZkPVVlw2zFr7fz6VLOoFjg

    С удалёнными ворнингами линковщика и libnosys.a.  Там же и пересобранная либа libhal.a

     

    Скрипт для линкера (на адреса памяти DDR, в скрипт должна передаваться переменная cache = 0,1):  hifi4.lds 

    -Wl,--defsym,cache=1

     

  10. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    20 minutes ago, sasamy said:

    что за мода скидывать логи картинками ?

    Перенаправление в файл работает на результат:

    Spoiler 
    C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/bin/ld.exe: C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/lib\libm.a(libm_a-sf_lrint.o):(.literal+0x4): undefined reference to `__addsf3'
C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/bin/ld.exe: C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/lib\libm.a(libm_a-sf_lrint.o):(.literal+0x8): undefined reference to `__subsf3'
C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/bin/ld.exe: C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/lib\libm.a(libm_a-sf_lrint.o):(.literal+0xc): undefined reference to `__fixsfsi'
C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/bin/ld.exe: C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/lib\libm.a(libm_a-sf_lrint.o): in function `lrintf':
/home/tux/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-hifi4-elf/src/newlib/newlib/libm/common/sf_lrint.c:69:(.text+0x4e): undefined reference to `__addsf3'
C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/bin/ld.exe: /home/tux/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-hifi4-elf/src/newlib/newlib/libm/common/sf_lrint.c:70:(.text+0x60): undefined reference to `__subsf3'
C:/GCC_HiFi4/bin/../lib/gcc/xtensa-hifi4-elf/13.2.0/../../../../xtensa-hifi4-elf/bin/ld.exe: /home/tux/crosstool-NG/.build/HOST-i686-w64-mingw32/xtensa-hifi4-elf/src/newlib/newlib/libm/common/sf_lrint.c:84:(.text+0x8c): undefined reference to `__fixsfsi'
collect2.exe: error: ld returned 1 exit status

     

     

    20 minutes ago, sasamy said:

    я на картинке не вижу -lgcc

    Ничего не дало. Картику обновил.

     

    Строка сборки:

    Spoiler 
    xtensa-hifi4-elf-gcc -nostartfiles -u_printf_float -Llibhal -Llibjpeg8 -Llibspeexdsp -Llibcelt -T hifi4.lds -Wl,-Map=main.map,--cref -Wl,--defsym,cache=1 -Wl,--gc-sections -Wl,--static -Wl,--strip-all ^
-o main.elf ^
 ^
startup_s.o ^
....
 ^
main.o ^
 ^
-lgcc -lm -lc -lnosys -lhal -ljpeg8 -lspeexdsp -lcelt

     

    Секция DISCARD: 

    /* remove the debugging information from the standard libraries */
 DISCARD : {
            libgcc.a ( * )
            libc.a ( * )
            libc_nano.a ( * )
            libm.a ( * )
            libm_nano.a ( * )
            libstdc++.a ( * )
            libnosys.a ( * )
           }

     

  11. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    С последними конфигами libm, libm_nano криво строится: не хватает некоторых функций.  С предыдущими либами из newlib (по ссылке от японца) проект успешно строился.

    Криво работают зависимости между библиотеками. Нижеприведённые функции есть в libgcc, которая почему-то лежит не в стандартном пути lib, а в другом месте:

    ...GCC_HiFi4\lib\gcc\xtensa-hifi4-elf\13.2.0

    Все эти функции есть в libgcc.a.  Но при компоновке, линковщик их не хочет брать.

     

    Перепробовал все  последовательности  указания либ.  Эффекта не даёт: линкер считает, что этих функций нет:

    image.thumb.png.1a09f1919f61471b282faa97476a1407.png

     

    При этом если сделать так: 

    extern float __addsf3(float a,float b);
extern int __fixsfsi(float a);

int main(void)
{
 printf("\nHiFi4 DSP ... %f\n\n",__addsf3(__fixsfsi((float)AVS_CNT0_REG),(float)AVS_CNT1_REG));
//...

    То проект успешно собирается.

    Предполагаю, что это происходит из за /DISCARD/ в LD-скрите или флагов:  -nostartfiles  -ffreestanding

    Наверное пора make-файл писать вместо батника. Иначе с зависимостями между библиотеками  как-то не гибко... :boredom:

  12. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    6 hours ago, sasamy said:

    ./ct-ng menuconfig

    Binary utilities  --->
    (--enable-warn-rwx-segments=no --enable-warn-execstack=no) binutils extra config

    +

    Quote

    cd ./overlays

    mkdir xtensa_hifi4

    tar -xf xtensa_hifi4.tar.gz -C xtensa_hifi4

    find ./xtensa_hifi4 -type f -print0 | xargs -0 sed -i '/#define XSHAL_ABI/c\#define XSHAL_ABI XTHAL_ABI_CALL0'

    +

    Quote

    Для этого пришлось изменить макрос stub_warning(name), превратив его в ничто: https://github.com/espressif/newlib-esp32/blob/esp_based_on_4_1_0/libgloss/libnosys/warning.h#L40

    Пересобрал тулчейн для Win32 с вышеуказанными опциями.  Доволен. Работает в ABI=call0.  Нет никаких тупых предупреждений.

    Можно переключать на Windowed (-mabi=windowed, -Wl,--abi-windowed), но библиотеки для этого режима надо пересобирать, или взять их с тулчейна, выложенного sasamy.

     

    Разобрался, как  в ct-ng делать сохранение.  У меня он завешивает комп постоянно на билдах, много времени убил прежде чем включить сохранение:

    https://stackoverflow.com/questions/9900005/is-it-possible-to-speed-up-crosstool-ng-builds-once-errors-have-occured

    Quote

    for ct-ng menuconfig, config Paths and misc options like this 

    ───────────────────── Paths and misc options ─────────────────────
[*] Debug crosstool-NG
[ ]   Pause between every steps
[*]   Save intermediate steps
[*]     gzip saved states
[*]   Interactive shell on failed commands

    Восстанавливаться:

    Quote

    ./ct-ng list-saves

    ...список стейтов...

    ./ct-ng предпоследний стейт+

     

  13. Опубликовано · Пожаловаться

    Требуют секцию .gcc_except_table.  Несмотря на то, что компилирую с ключами: 

    -fno-rtti -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer -fno-threadsafe-statics

    C++ конечно.

    Разместил секцию в LD-скрипте. Всё работает.  Но неприятно, что ключи проигнорировались. Где-то в недрах libstdc++ наверно эти исключения используюстя.

    Надо бы им ещё сделать libstdc++_nano 🤣

  14. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    29 minutes ago, GenaSPB said:

    А сделать для таких .gnu.warning.* секций раздел DISCARD в линк скрипте?

    Не помогло. Скорее всего линковщик первее выдает предупреждения, а не смотрит что в линкер-скрипте. 

    /* remove the debugging information from the standard libraries */
 DISCARD : {
            .gnu.warning.* 
            libgcc.a ( * )
            libc.a ( * )
            libc_nano.a ( * )
            libm.a ( * )
            libm_nano.a ( * )
            libstdc++.a ( * )
           }

     

    Вот тут схожая проблема:

    https://stackoverflow.com/questions/73429929/gnu-linker-elf-has-a-load-segment-with-rwx-permissions-embedded-arm-project

    https://github.com/raspberrypi/pico-sdk/issues/1029

    Лучше бы они ничего не меняли...

    Конечно, можно линкеру приписать -Wl,--no-warn-rwx-segments   и забыть... Но я слишком педантичен, чтобы это оставлять.

    38 minutes ago, repstosw said:

    Когда их разместил в .text, то предупреждение исчезло:

    Ещё такой вариант не приводит к появлению предупреждения: 

    .ctors :
 {
  . = ALIGN(4);
  PROVIDE_HIDDEN (_ctors_start = .);
  KEEP (*(SORT(.ctors.*)))
  KEEP (*(.ctors*))
  . = ALIGN(4);
  PROVIDE_HIDDEN (_ctors_end = .);
 } > RAM AT > ROM

 .dtors :
 {
  . = ALIGN(4);
  PROVIDE_HIDDEN (_dtors_start = .);
  KEEP (*(SORT(.dtors.*)))
  KEEP (*(.dtors*))
  . = ALIGN(4);
  PROVIDE_HIDDEN (_dtors_end = .);
 } > RAM AT > ROM

     

    Задача называется "обмани линкер"

  15. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    5 hours ago, sasamy said:

    он просто так не будет орать

    https://github.com/raspberrypi/pico-sdk/issues/1029#issuecomment-1324889474

    Вот здесь об этом рассказано  по-лучше:

    https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments

    Ему не нравятся, что  конструкторы и деструкторы были описаны в отдельных блоках.  Когда их разместил в .text, то предупреждение исчезло: 

    .text    : 
  {

  *(.text*)

  . = ALIGN(4);
  PROVIDE_HIDDEN (_ctors_start = .);
  KEEP (*(SORT(.ctors.*)))
  KEEP (*(.ctors*))
  . = ALIGN(4);
  PROVIDE_HIDDEN (_ctors_end = .);

  . = ALIGN(4);
  PROVIDE_HIDDEN (_dtors_start = .);
  KEEP (*(SORT(.dtors.*)))
  KEEP (*(.dtors*))
  . = ALIGN(4);
  PROVIDE_HIDDEN (_dtors_end = .);
 } > ROM

    Мне кажется, что этот 13-й GCC слишком предвзятый.  Какие атаки могут быть на сегменты, которые выполняются в Bare Metal? :lol:

  16. Опубликовано · Пожаловаться

    3 hours ago, repstosw said:

    С objcopy не  вышло. А strip удаляет не только то, что надо.  Вариант перекомпиляции с  убраным макросом уже был.

    Вот так работает: 

    objcopy --strip-debug libnosys.a
objcopy --remove-section=.gnu.warning.* libnosys.a

    По-другому удаляться эти противные секции (.gnu.warning.*) из либы не хотят.

  17. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    35 minutes ago, sasamy said:

    венда убога как ОС, счас говорят powershell какой-то есть ?

    На счёт этого не знаю, но подозреваю, что есть. Кроме того, можно портировать вод винду то, что есть в линуксе.

    Мало того, есть Notepad++, с его мощными регулярными выражениями. Но их надо курить.

    Но в текстовых файлах исправить менее 10 дефайнов несложно 🙂

    35 minutes ago, sasamy said:

    эта замена в принципе не нужна - она совсем отключит windowed abi и нельзя будет переключить его через -mabi=windowed

    На счёт переключений видел такой вариант, но слинковать вроде как не позволит. Надо попробовать сделать, как вы написали и проверить на предмет переключаемости в линковке.

    35 minutes ago, sasamy said:

    он просто так не будет орать

    https://github.com/raspberrypi/pico-sdk/issues/1029#issuecomment-1324889474

    Согласен.

    Но у меня фон-неймановский расклад памяти, это когда можно RWX во всех регионах. Даже в коде.  Потому что нету флеша, а есть DDR.

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

     

    Меня сейчас интересует как удалить секции, которые начинаются с .gnu.warning.  в libnosys, при этом сохранить всё остальное. 

    С objcopy не  вышло. А strip удаляет не только то, что надо.  Вариант перекомпиляции с  убраным макросом уже был.

  18. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    Ранее обсуждалось, что у меня нет желания видеть ворнинги при линковке, которые говорят о дефолтной реализации функций в libnosys. И предлагал пересобрать эту либу.

    Есть способ проще - удалить секцию через objcopy или strip.

    Но objcopy не работает правильно. Делаю команду удаления всех секций по шаблону .gnu.warning.* : 

    objcopy --remove-section=.gnu.warning.* libnosys.a

    В итоге, секции остаются и выдаёт следующее :

    image.png.e313927eb6e7ce5563b000b7c5f751ed.png

    При этом через objdump делаю вывод секций- для проверки (.gnu.warning.* остались) : 

    objdump -h libnosys.a > sections.txt

    Секции: 

    In archive libnosys.a:

chown.o:     file format elf32-xtensa-le

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .literal      00000004  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .text         0000000b  00000000  00000000  00000038  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  2 .data         00000000  00000000  00000000  00000043  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000000  00000000  00000000  00000043  2**0
                  ALLOC
  4 .gnu.warning._chown 0000002f  00000000  00000000  00000043  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .debug_frame  00000020  00000000  00000000  00000074  2**2
                  CONTENTS, RELOC, READONLY, DEBUGGING, OCTETS

     

    Почему секции не подлежат сносу ?

    Если сделать strip: 

    strip -w -R .gnu.warning.* libnosys.a

    То секции с шаблоном  .gnu.warning.* сносятся (что и нужно), но кроме этого отладочные секции тоже сносятся (не нужно).

     

    Почему так всё бажно?  Стрип значит сносит, а обжкопи - нет.

     

    И ещё  теперь надо добавлять к линкеру ключ: 

    -Wl,--no-warn-rwx-segment

    А то при линковке орёт про permissions RWX в elf-секции.

  19. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    4 hours ago, sasamy said:

    результаты по нулям у всех оконных вызовов, кроме libstdc++ но он не нужен 🙂

    Нужен. Когда программа написана на C++ и использует его возможности.  Те же new, delete.

    C этой тройкой библиотек мои проекты работают (смешанные C++/C/ASM): 

    -lstdc++ -lc_nano -lnosys

    specs у меня не заработал почему-то. Да оно мне ине нужно.

     

    При этом для lc_nano для printf() нужна фукция _write( ) : 

    int _write(int fd,char *ptr,int len) //for printf
{
 (void)fd;
 int i=0;
 while(ptr[i]&&(i<len))
 {
  UART_putc(ptr[i]);
  if(ptr[i]=='\n')UART_putc('\r');
  i++;
 }
 return len;
}

     

    Делал оверлей под call0 по-другому:

    1.  Скачал несконвертированный оверлей: https://github.com/YuzukiHD/FreeRTOS-HIFI4-DSP/releases/download/Toolchains/xtensa-config-overlay.tar.gz

    2. Разжал  его.

    3. В винде с помощью программы Folder Find Text нашёл все файлы с подстроками:  call0 , windowed - их не так много.

    4. Подправил везде во всех файлах:
      

    XCHAL_HAVE_WINDOWED - выставил в 0

XSHAL_ABI - выставил в XTHAL_ABI_CALL0

    5. Сохранил файлы и пожал их обратно tar.gz (при этом важно сжать все файлы не одной папкой, а в текущей папке).

    6. Полученный архив сконвертировал для ct-ng sh-скриптом: https://wiki.linux-xtensa.org/index.php?title=Toolchain_Overlay_File

    7. Положил архив оверлея в папку overlays  ct-ng.

    8. Собрал тулчейн.

    9. Проверил, что ABI CALL0 задефайнен: 

    echo | xtensa-hifi4-elf-gcc -dM -E - > o.txt

sudo nano o.txt

    10. должно быть: 

    #define __XSHAL_ABI 1

#define __XCHAL_HAVE_WINDOWED 0
#define __XTENSA_CALL0_ABI__ 1

#define __XTHAL_ABI_WINDOWED 0
#define __XTHAL_ABI_CALL0 1

    Эсли дефайны другие, тогда увы 🙂

     

    4 hours ago, sasamy said:

    мусор словился в libstdc++, на самомо деле вызово call4 там нет, это просто часть текста

    Мусор есть в секциях литералов, в секциях комментариев. И просто в данных.

  20. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    libc_nano порадовал.  При указанном флаге -u_printf_float - печатает float.  Всё как в arm-none-eabi !:dance4:

    А вот через specs не хочет нормально линковаться.  Кучу ботвы вылазит: про eh-фреймы, про литералы.  Я не люблю, когда кто-то лезет в распределение памяти всесте со мной...

  21. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    В общем собрал я тулчейн с этим ct-ng и конфигом для Win32 с ABI=call0. Для host=Win32 пришлось снять галочку "build local zlib", иначе не может слинковать zlib под host (под build билд проходит).

     

    В итоге программа валится в эксепшен, даже до первого printf() не доходит.

    Удалось заставить программу работать работать.  С такими ключами линковки: 

    %TOOLCHAIN%gcc -nostartfiles -nostdlib -nodefaultlibs -ffreestanding -Llibhal -T hifi4.lds ^
 ^
-Wl,-Map=main.map,--cref -Wl,--defsym,cache=1 -Wl,--gc-sections -Wl,--static -Wl,--strip-all ^
 ^
startup_s.o ^
 ^
...
 ^
main.o ^
 ^
-lc_nano -lnosys -lhal -o main.elf

    Какой порядок следования при линковке с помощью GCC (не LD) ?

     

    Кроме того, как  я и ранее говорил, использование libnosys.a или -spec=nosys.spec приводит к появлению назойливых предупреждений.

    Так что пилить и пилить. Никаких "испадкаробки" не получается.

    Треды, реентабельность, файловый ввод-вывод - выкосить в первую очередь. Ибо оно не нужно в Baremetal, а только создаёт проблемы.

    image.thumb.png.9b1124682d214c162dafcaebb9f56b98.png

     

    С указанием spec  nosys и nano предупреждений меньше:

    image.thumb.png.c380bb38be4ebccf8777a30228c0f6f2.png

     

    Про предупреждения и способ их устранения здесь:

    https://electronix.ru/forum/index.php?/topic/157083-allwinner-t113-s3-уделал-hifi4-dsp-смеяться-или-плакать/&do=findComment&comment=1880341

     

    P.S.  Есть и хороший момент:  GCC  v.13,  на тестах показал увеличение производительности на +6 % по сравнению с GCC v.10

     

  22. Опубликовано · Пожаловаться

    Скорее всего, в моём случае было важно удержать адрес, после поднятия WE.  Данные тут не причём.

    Так как если не удерживать адрес достаточное время, то дисплей может перепутать данные и проинтерпретировать их как команду.  Поэтому ему и срывало башню.

    3 minutes ago, dimka76 said:

    Спасибо.

    И вам спасибо! Теперь я более корректнее понял что происходило на самом деле.

    А на счёт шины данных, по-хорошему осциллографом или логическим анализатором посмотреть бы... :boredom:

     

  23. Опубликовано · Изменено пользователем repstosw · Пожаловаться

    4 minutes ago, dimka76 said:

    Из какого она документа.

    не помню.  Вот ещё одна:

    image.thumb.jpeg.ec9fd062bf12d5d6b0fad4a666bad42a.jpeg

     

    Типовые времянки NAND.

    https://amberclan.clan.su/publ/uroki_po_programmirovaniju_stm32fxxx/uroki_po_programmirovaniju_stm32/pamjat_nand_i_fsmc/7-1-0-98

    Quote

    HoldSetupTime - Время, которое продолжают идти адресные данные после установки WE в 1. (В расчётах данного параметра можно опираться на время установки СЕ)

     

  25. Опубликовано · Пожаловаться

    1 hour ago, sasamy said:

    непонятно зачем, я скинул архив с исходниками - достаточно распаковать в свой /home/$USER/src

    Пост был написан вами 5 часов назад, а последние ссылки добавлены 4 часа назад.

    1 hour ago, sasamy said:

    я бы лучше установил убунту 22.04 в виртуалке - на ней точно собирается, с повторяемостью сборок всегда проблемы бывают - самый быстрый путь тот который знаешь (собирать на том что проверено), у вас по картинке кажется 16 или 18. Пишут доустановить в системе для ctng надо

    У меня 15-я убунта.   Начиная с 18-й ПК безбожно тормозит и убунта назойливо ставит видеорежим, не поддерживаемый моим монитором (максимум 1366x768 x 60).

    Дело не в убунте.  А в том, что я указал кастомные пути к исходикам,  не распаковав исходники.

    Нужно было распаковать каждый архив и указать ещё папку для каждого пакета.

    Остальное по вашей инструкции.  Под линукс собралось. Сейчас потестирую сборку для винды.

    Действительно - появились libnosys, libc-nano и много чего ещё.

     

    Спасибо, ваша инструкция   и исходники помогли и ускорили билды!

    Сейчас пробую поставить ABI call0 и для винды.

    1 hour ago, sasamy said:

    попробуйте ещё доустановить у себя mingw - вообще он не нужен, но у меня установлен на убунте, может поэтому не возникает проблема

    Я его ещё установил, когда делал bootstrap для старого ct-ng .

×
×
  • Создать...