Web-свалка на RTL871x

[Neov]

@pvvx, UDK теперь тут прописан? VOID RtlUpSemaFromISR(IN _Sema *sema) где брать? osdep_api.c же исключен.

 

[pvvx]

@pvvx, UDK теперь тут прописан? VOID RtlUpSemaFromISR(IN _Sema *sema) где брать? osdep_api.c же исключен.

4.0b полностью ещё не адаптирован для всех примеров в SDK. Пока только для кода Web-свалки...

VOID RtlUpSemaFromISR(IN  _Sema *sema)
{
    rtw_up_sema_from_isr(sema);
}

#define RtlUpSemaFromISR rtw_up_sema_from_isr

 

[Alexey_new]

Интересно, зачем использовать RtlUpSemaFromISR и т.п. функции, если можно напрямую пользоваться
xSemaphoreGive? Или функции ОС почему-то нежелательно так использовать?

 

[sharikov]

Интересно, зачем использовать RtlUpSemaFromISR и т.п. функции, если можно напрямую пользоваться
xSemaphoreGive? Или функции ОС почему-то нежелательно так использовать?

В HAL используют RtlUpSema*** и т.п. Видимо чтобы HAL отвязать от OS.
А в пользовательском коде конечно удобнее xSemaphoreGive или другое из freertos.

 

[sharikov]

а вот версия где чуток переделана сама Dygraphs

Не работает isZoomedIgnoreProgrammaticZoom а он нужен.
Такое впечатление что вы взяли какую то древнюю версию Dygraphs.
Нужен патч на актуальную а еще лучше pull request разработчикам.


---
UPD.
isZoomedIgnoreProgrammaticZoom выпилили. И как его теперь заменить ?

 

[Alexey_new]

Раньше я тут жаловался, что компилятор не замечает детские ошибки в коде. Связано это с тем, что в опциях компилятора указано -w, которое отключает все предупреждения. Мне показалось это не правильным, я вернул предупреждения. Их оказалось так много, что некоторые, достаточно безобидные, на мой взгляд, я все же выключил.
CFLAGS += -Wno-pointer-sign -Wno-unused-function -Wno-char-subscripts -Wno-unused-parameter
CFLAGS += -Wno-sign-compare -Wno-unused-variable -Wno-old-style-declaration -Wno-unused-but-set-variable -Wno-empty-body
CFLAGS += -Wno-type-limits
В оставшихся стал разбираться. Сперва ошибки просто исправлял. Обнаружилось несколько ошибок в передаваемых параметрах, нашел ошибку в коде какой-то неиспользуемой функции. Потом стал отмечать что исправил. Некоторые ошибки я так и не понял как исправить.
Константы FEEP_ID_WIFI_CFG и FEEP_ID_WIFI_AP_CFG имеют разное определение в разных файлах, какое выбрать я не знаю.
Константа DEF_AP_SECURITY не правильная инициализация, надо 1
Структура wifi_st_cfg поля .flg и .security ошибка в инициализации
В функции wifi_run_ap вызов _wext_cmp_ssid с ошибочным параметром
Константа RTW_SECURITY_UNKNOWN установлена отрицательной (-1), а ее сравнивают с unsigned
В функции _wifi_scan_done_hdl вызов (*pscan_rec->gscan_result_handler)(pscan_rec) Параметр pscan_rec совсем не того типа какой надо, не нашел как исправить, убрал этот вызов вообще, т.к. не понял что он делает.
В функции api_wifi_scan вызов _wifi_scan_networks(scan_result_cb) Параметр scan_result_cb не того типа как надо. Сделал преобразование типов, но не уверен что так и надо.
Инициализация lwip_host_name больше размера lwip_host_name
Функция analogin_read вызов RtkADCReceiveBuf с ошибочным аргументом
Функция loadUserImges вызов load_segs с ошибочным параметром, но поскольку адрес совпадает, то все работает

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

 

[pvvx]

Раньше я тут жаловался, что компилятор не замечает детские ошибки в коде. Связано это с тем, что в опциях компилятора указано -w, которое отключает все предупреждения. Мне показалось это не правильным, я вернул предупреждения. Их оказалось так много, что некоторые, достаточно безобидные, на мой взгляд, я все же выключил.

Это сообщите в Realtek, конкретно в Ameba, которые слепили такой SDK с рекомендованными опциями трансляции и в GCC, т.к. аргументы компилятору даются последовательно [inline]-w -Wall -Werror ...[/inline] Я пока пытаюсь только распутать этот клубок, спутанный другими...

Константы FEEP_ID_WIFI_CFG и FEEP_ID_WIFI_AP_CFG имеют разное определение в разных файлах, какое выбрать я не знаю.

Любые, хидеры от разных примеров... ID - номер сохранения конфигурации, который вам понравиться и не встречается в других сохранениях...

Константа DEF_AP_SECURITY не правильная инициализация, надо 1

Это вам так "хотчестя", а wifi_api.c не дописан и реальный передаваемый тип там [inline]rtw_security_t[/inline].
Структура wifi_st_cfg поля .flg и .security ошибка в инициализации
В функции wifi_run_ap вызов _wext_cmp_ssid с ошибочным параметром
Константа RTW_SECURITY_UNKNOWN установлена отрицательной (-1), а ее сравнивают с unsigned[/QUOTE]Та и фиг с ней - там сравнение [inline]==[/inline], а другие только 9 шт положительные...

В функции _wifi_scan_done_hdl вызов (*pscan_rec->gscan_result_handler)(pscan_rec) Параметр pscan_rec совсем не того типа какой надо, не нашел как исправить, убрал этот вызов вообще, т.к. не понял что он делает.
В функции api_wifi_scan вызов _wifi_scan_networks(scan_result_cb) Параметр scan_result_cb не того типа как надо. Сделал преобразование типов, но не уверен что так и надо.

Всё там Ok. Делалось по "реверсу" (дизасм и т.д.).

Инициализация lwip_host_name больше размера lwip_host_name

#define LWIP_NETIF_HOSTNAME_SIZE 16
#define DEF_HOSTNAME "rtl871x"
8 символов из 16
8 < 16.

Функция analogin_read вызов RtkADCReceiveBuf с ошибочным аргументом

Нормальные там аргументы.

Функция loadUserImges вызов load_segs с ошибочным параметром, но поскольку адрес совпадает, то все работает

Правильный там параметр

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

Ну надо кому-то чистить, одному это не под силу - перелапатить весь SDK + "реверс", добавки и его исправления для сотен примеров (старых и новых) на все случаи жизни...
Со временем, когда оно будет, исправиться. Git пока не имеет даже описания что это за безобразие, т.к. первостепенная задача там слить все прошлые SDK к новой, версии 4.0 и состыковать с имеющимися исходниками и "реверсом" закрытых частей + уже пачку исправлений, в основном для HAL и внутренних потрахов чипа... К примеру для USB, SDIO, SPI, GPIO, ... контроллеров (RTL8195A)...

 

[pvvx]

@Alexey_new - почистил - сделал первый проход...
По вашей просьбе всё ужесточено [inline]-Werror[/inline] Пишите на здоровье
CFLAGS += -Wall -Werror
CFLAGS += -Wno-old-style-declaration -Wno-pointer-sign -Wno-strict-aliasing
CFLAGS += -Wno-variadic-macros -Wno-empty-body
Если будут претензии по поводу Warning-ов - поставлю -Wpedantic
Будете писать вставки на asm

 

[Alexey_new]

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

    union {
        unsigned int     ui[2];
        unsigned short     us[4];
    } adata;
    PSAL_ADC_HND p = &((&(obj->SalADCMngtAdpt))->pSalHndPriv->SalADCHndPriv);
    RtkADCReceiveBuf(p, (u32  *) &adata.ui);
    return (float)(adata.us[p->DevNum]) / (float)(0xCE80);

При использовании &adata.ui в качестве (u32 *) получается следующее: компилятор выделяет ячейку, в которую записывает адрес .ui (совпадающий с адресом adata в данном случае) и адрес этой ячейки передает RtkADCReceiveBuf, которая использует его самым обычным образом:

    *pBuf       = (u32)ADCDatBuf[0];
    *(pBuf+1)   = (u32)ADCDatBuf[1];

В итоге мы получаем, что данные пишутся не туда (пишутся во вспомогательную ячейку), и портится одна непонятная ячейка после вспомогательной. Т.е. не то, что хотелось бы.
Эта ошибка не проявляется, т.к. я не видел в коде использования analogin_read, только в примерах.
Прямое преобразование типов считается достаточно опасной операцией, которой лучше избегать.

 

[sharikov]

Позвольте с Вами все же не согласиться. Простое преобразование типов уберет ошибку компиляции, но оставит ошибку по сути.

Нету там ошибки. Функции RtkADCReceiveBuf(p, (u32 *) &adata.ui); будет передан начальный адрес массива ui без каких либо "вспомогательных ячеек". Внутри RtkADCReceiveBuf строка *pBuf = приведет к записи по адресу ui+0 а *(pBuf+1) = к записи в ui+4. +4 потому что у указателя pBuf тип u32.

 

[pvvx]

Прямое преобразование типов считается достаточно опасной операцией, которой лучше избегать.

Если вы смотрели SDK, то оно составлено из разных библиотек, к которым собственные typedef-ы (типы) и там мешанина (u32, uint32, uint32_t, DWORD, ... и т.д.). Вот возьмитесь и перепишите всю SDK - мы подождем...
По поводу analogin_read - вы уверены, что там (u32) вообще? Где вы видели описание данного буфера вообще?
Откройте закрытую часть HAL (сделайте "реверс" либы SDK) тогда и определитесь, что туда переписываются пару регистров FIFO ADC, а значения в них (побитно) зависят от конфигурации (установок ADC).
Хотелось бы получить от вас полное описание ADC что там и когда, тогда я исправлю в своем варианте сохранения недоработанной версии на git.
Исходный код web-свалки не является примером структурного программирования и не нацелен на обучение СИ или C++. Об этом в названии вставлено предупреждение - "свалка" и в основном служит для тестирования уже переведенных в СИ код закрытых и тестовых кусков SDK, и тестов возможностей модуля. Когда Вы очистите SDK от нерабочего и тестового хлама (а его там много, т.к. даже не все HAL/драйвера даны Ameba и большинство просто какие-то произвольные куски, да ещё надо учесть что это огрызок без NDA), напишите полное описание на чип (на русском языке ), тогда можно будет уже производить какую-то чистку и приведение кода к какому-то порядку (мне чуждому ), т.к. это не моя миссия и не стыкуется к моему хобби - могу за ваш счет нанять кого... ).
И если вы поняли мысль и смысл, то хотя-бы помогите сделать начальные шаги по переводу закрытых кусков кода в исходники и их отладке. Потом уже займемся вашими тараканами…
Пример вам уже дал - для устранения сотен варнингов в базовом SDK требуется всего пол-часа и не является "задачей", а вот раскопать, проверить, исправить и переписать с сокращением объема кода - в сотни раз больше.

 

[Elik]

Есть плата RTLDUINO, как на нее прошить вебсвалку, только взял в руки, есть пошаговая инструкция? Может включить в первый пост?

 

[pvvx]

Есть плата RTLDUINO, как на нее прошить вебсвалку, только взял в руки, есть пошаговая инструкция? Может включить в первый пост?

Возможно, но несколько позже.
Данная Web-свалка пока не доросла до этого Она пока в зародыше и не умеет делать многое оптимально и без ошибок.
Основные причины - там винегрет из разных SDK и включенные туда примеры не состыкованы... Пробита тропинка только для работы основного кода web...
Т.е. не для раздела "Для начинающих" - если им дать возможность собрать и прошить по одной кнопке, то будет масса не нужных на данном этапе вопросов (подобных, разбираемым выше на этой странице - почему варнинги не такие, почему не собирается пример, почему в том углу пишет что-то и т.д.).

 

[АндрейМ]

Данная Web-свалка пока не доросла до этого

Смотрю твой драйвер для i2c, прокомментируй несколько моментов:

#define i2c_reg(r) *((volatile uint32 *)(pi2c->base_regs + r))

и в коде

(volatile)i2c_reg(REG_DW_I2C_IC_CLR_TX_ABRT);

дает ошибку

project/src/driver/i2c_drv.c: In function '_i2c_break':
project/src/driver/i2c_drv.c:133:2: error: type defaults to 'int' in type name [-Werror=implicit-int]
(volatile)i2c_reg(REG_DW_I2C_IC_CLR_INTR);

какой смысл в двух volatile?

 

[pvvx]

какой смысл в двух volatile?

А видимо второй был позже добавлен уже в define, когда что-то дописывалось.
Ведь в оф.версии SDK стоит опция отключения warnings -w, а далее модификации типа -Wxxxx, что скрывает что они отключены и всё писано "вслепую", а данный драйвер вообще писался условно на коленке, исключительно для проверки работоспособности алго без оф. HAL из SDK

 

[АндрейМ]

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

Хорошо, что не баг компилятора.

Насколько работоспособный драйвер i2c в свалке? Как считаешь, его переписывать или достаточно будет причесать?

 

[pvvx]

Хорошо, что не баг компилятора.

Насколько работоспособный драйвер i2c в свалке? Как считаешь, его переписывать или достаточно будет причесать?

А я уже уже успел причесать, как писал вам ответ
У него есть свои ограничения и он меньше оф. версии HAL для I2C по ресурсам раз в сто...
Во первых есть минимум три варианта работы - полинг, прерывания, DMA.
А для INA219 код реализован вообще через работу fifo у аппаратного контроллера I2C.
Есть отдельная тема про I2C на RTL. I2C на RTL...

 

[АндрейМ]

А я уже уже успел причесать, как писал вам ответ

На гитхабе нет обновлений, значит не причесал - о появились ))

Я слабо представляю аппаратные модели I2C, думаю, что для обычного использования достаточно будет поллинга с буферизацией.
DMA и прерывания вещь сугубо специфичная, которая обязана быть жестко завязана на железо.
Обычное использование - медленный BMP180, экранчики с hd44780 и подобная аппаратка.
DMA - растровые экраны и иже с ними.
Прерывания - что-то типа ADC с очень коротким периодом готовности.

 

[АндрейМ]

Есть отдельная тема про I2C на RTL.

Поехал туда

 

[pvvx]

Я слабо представляю аппаратные модели I2C, думаю, что для обычного использования достаточно будет поллинга с буферизацией.

Вот там, в теме и описан случай, как раз ни полинга, а аппаратная буферизация запросов и ответов в FIFO...