• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Не объявленные функции sdk

pvvx

pvvx

Активный участник сообщества
В liblwip.a встроена функция NETIO Benchmark-а - void netio_init(void) и много другого хлама :)
lwip/app/netio.c: /* See http://www.nwlab.net/art/netio/netio.html to get the netio tool */

Проверим, запустив netio_init()...

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 1080.69 KByte/s Tx, 4271 Byte/s Rx.
Packet size 2k bytes: 1229.67 KByte/s Tx, 7724 Byte/s Rx.
Packet size 4k bytes: 1204.59 KByte/s Tx, 16895 Byte/s Rx.
Packet size 8k bytes: 1145.36 KByte/s Tx, 15753 Byte/s Rx.
Packet size 16k bytes: 1205.84 KByte/s Tx, 14557 Byte/s Rx.
Packet size 32k bytes: 1205.53 KByte/s Tx, 13.99 KByte/s Rx.
Done.

После отработки теста имеем примерно это:

HeapSize: 28720
Active PCB states:
Port 18767->1624 ESTABLISHED
Listen PCB states:
Port 18767 LISTEN
TIME-WAIT PCB states:
Port 18767->1617 flg:0x30 TIME_WAIT

Wireshark заполнена сообщениями [TCP Window Full].

Ужас. NETIO не адаптирована Espressif к текущей конфигурации Lwip. Реально, на имеющемся Lwip, простейший самописанный HTTPD сервер дает за 500 KByte/s...
 
amatron

amatron

New member
Всем привет!
Есть какая-либо информация по этим функциям:
ets_wdt_disabe ()
ets_wdt_enable ()
ets_wdt_get_mode ()
ets_wdt_init ()
ets_wdt_restore ()
wdt_feed ()

Хочу разобраться с watchdog.
Помогите, пожалуйста!
 
pvvx

pvvx

Активный участник сообщества
amatron написал(а):
Всем привет!
Есть какая-либо информация по этим функциям:
ets_wdt_disabe ()
ets_wdt_enable ()
ets_wdt_get_mode ()
ets_wdt_init ()
ets_wdt_restore ()
wdt_feed ()

Хочу разобраться с watchdog.
Помогите, пожалуйста!
Нажмите для раскрытия...
Есть ещё непонятные:
wifi_get_sleep_type()
wifi_set_sleep_type()
Всё это повязано с потреблением и сном...

По вашим функциям из ld/eagle.rom.addr.v6.ld есть только это:
http://df.lth.se/~kongo/esp8266.bin/
И куча доков по процу http://esp8266.ru/forum/threads/rasshirenie-flesh-pamjati.36/page-3#post-477 по всему инету. Возможно там найдете WDT таймер...

Нету в ESP8266 WDT.
Он походу сделан на
ets_timer_setfn
ets_timer_arm
ets_timer_disarm
:)
 
Последнее редактирование:
ihor

ihor

New member
Начал более детально изучать примеры и наткнулся на такой вопрос.
в файле eagle.rom.addr.v6.ld есть команда ets_timer_arm,
но нет команды ets_timer_arm_new, которая определена в файле osapi.h как
#define os_timer_arm(a, b, c) ets_timer_arm_new(a, b, c, 1) но компилятор с линкером с ней работают.
Где здесь подвох??
 
jcmvbkbc

jcmvbkbc

New member
ihor написал(а):
Начал более детально изучать примеры и наткнулся на такой вопрос.
в файле eagle.rom.addr.v6.ld есть команда ets_timer_arm,
но нет команды ets_timer_arm_new, которая определена в файле osapi.h как
#define os_timer_arm(a, b, c) ets_timer_arm_new(a, b, c, 1) но компилятор с линкером с ней работают.
Где здесь подвох??
Нажмите для раскрытия...
ets_timer_arm_new определена в библиотеке libmain.a
 
pvvx

pvvx

Активный участник сообщества
jcmvbkbc написал(а):
ets_timer_arm_new определена в библиотеке libmain.a
Нажмите для раскрытия...
И каковы же её аргументы? us задается в uint32 или ограничено 1000 ?
ihor написал(а):
Начал более детально изучать примеры и наткнулся на такой вопрос.
в файле eagle.rom.addr.v6.ld есть команда ets_timer_arm,
но нет команды ets_timer_arm_new, которая определена в файле osapi.h как
#define os_timer_arm(a, b, c) ets_timer_arm_new(a, b, c, 1) но компилятор с линкером с ней работают.
Где здесь подвох??
Нажмите для раскрытия...
ets_timer_arm использует 3 аргумента и работает с ms. В случае с указанием функции NULL получим такое:
2cdf: b9a042 movi a4, 185 // = 0xB9
2ce2: ff7e85 call0 ets_printf
2ce5: ffff06 j 2ce5
:)
---------------
Пытался собрать все описания функций из eagle.rom.addr.v6.ld , но сил и желания собирать во едино не хватило.
Дописывайте сами - на сегодня из них точно известны 90%, а часть никому не нужна, т.к. используется загрузчиком - зачем писать свой загрузчик, если он уже есть в BIOS-е?
 

Вложения

Последнее редактирование:
pvvx

pvvx

Активный участник сообщества
Функция uint32 readvdd33() дает напряжение питания readvdd33()/1132 = xВ, где 1132 - это среднее значение коэф. для внутреннего ADC (SAR) при вычислении питания к конкретному модулю. Пример: при питании 3.286В получаем значение ~3718(dec)
 
Последнее редактирование:
pvvx

pvvx

Активный участник сообщества
Alex написал(а):
Ну видимо только дизассемблером :)
Нажмите для раскрытия...
Текстовым редактором :) Загружаете и смотрите названия процедур и переменных - они в обычном текстовом виде...
Или раскручиваете NDAшника :) Но они все вредные и с ними не стоит возиться, а гнать в шею от седова. :)

Странслировав и получив eagle.app.v6.out, запускаете:
C:\Espressif\xtensa-lx106-elf\bin\xtensa-lx106-elf-objdump -S eagle.app.v6.out > eagle.app.v6.asm
и получаете листинг дизассемблера
 
Последнее редактирование:
pvvx

pvvx

Активный участник сообщества
Дизассемблировать лучше полную прошивку из получившегося eagle.app.v6.out.
Тогда будут видны все крос-адреса и можно "на живую" проверить, что за данные там находятся, для полного "реверс-инженирингa" (теперь это так называется :)):
SDK.gif
 
pvvx

pvvx

Активный участник сообщества
AlexeyGR - зачем вы где не попадя, не учитывая тему оставляете вопросы? Больше я на такое отвечать не буду :)
Размер принятого пакета задает процедура вызывающая promiscuous_cb(uint8 *buf, uint16 len).
Код: 
ppPeocessRxPktHdr:                    
                l32r            a5, a_promiscuous_cb
                addi            a1, a1, 0xF0
                s32i.n          a0, a1, 0
                s32i.n          a12, a1, 4
                l32i.n          a5, a5, 0
                mov.n           a12, a2
                beqz.n          a5, loc_40255D2E
                l8ui            a6, a2, 1 ; frame control bits 8..15
                l8ui            a0, a2, 4 ; mak1
                srli            a6, a6, 6 ; биты WEP, Order
                beqz.n          a6, loc_40255D1D // если ноль, то размер из buf[0x7C]
                srli            a7, a0, 7
                beqi            a7, 1, loc_40255D3F // если = 1, то размер 12
                extui           a8, a0, 0, 7
                bgei            a8, 8, loc_40255D3F // на размер 12
                l8ui            a9, a2, 7
                bbsi            a9, 6, loc_40255D3F // на размер 12

loc_40255D1D:                         
                l16ui           a3, a12, 0x7C ; размер из буфера по смещению +0x7С
                slli            a3, a3, 1 ;*2
                addi            a3, a3, 0x7E ; + 0x7E
                extui           a3, a3, 0, 0x10 ; and ((1<<10)-1) // 0x3FF

loc_40255D29:                          
                mov.n           a2, a12 ;  адрес буфера
                callx0          a5      ; promiscuous_cb(uint8 *buf, uint16 len)

loc_40255D2E:                          
                mov.n           a2, a12
                l32r            a0, a_vPortFree
                callx0          a0
                l32i.n          a12, a1, 4
                l32i.n          a0, a1, 0
                addi            a1, a1, 0x10
                ret.n
; ---------------------------------------------------------------------------

loc_40255D3F:                         
                                      
                movi.n          a3, 12 ; размер 12
                j               loc_40255D29
Так что проверяйте - возможно пакет там полный, но Espressif указал другую длину.
 
pvvx

pvvx

Активный участник сообщества
Дык вот - не выдает больше 128 байт. Побоялись, что память забьет пакетами?
Во всяком случае эти 128 байт там выделяются каждый раз и после promiscuous_cb освобождают os_free() (vPortFree), а вызов ppPeocessRxPktHdr происходит как task.
 
pvvx

pvvx

Активный участник сообщества
AlexeyGR написал(а):
Да..., это окончательный "вердикт"? :)
Более того, пакет сверху "обрезан" на 20 байт.
Нажмите для раскрытия...
"Сверху" это как?
Заголовок пакета сидит в I/O области по адресу 0x3FF2003C.
Если сравнивать что приходит к promiscuous_cb(uint8 *buf, uint16 len), то имеем такую перестановку первых 4-х байт в начале:
Приходит в буфере: 0x00DF0037, 00:00:00:00:00:00, 01:00:50:00:30:01, 00:08:22:2D:35:24, 0xAEBC, C5:EB:09:90:BC:AE
в I/O области : 0x370000DF, 00:00:00:00:00:00, 00:00:50:00:30:01, 00:08:22:2D:35:24, 0xAEBC, C5:EB:09:90:BC:AE
И в буфер добавлен номер канала 01
При этом в I/O области сообщение отличается начиная с 44 байта (похоже там только заголовок).
 
pvvx

pvvx

Активный участник сообщества
AlexeyGR написал(а):
Вот как раз заголовок неполный...
Нажмите для раскрытия...
Дык формат давай, а не картинки. А то искать нечего.
По этой картинке всё совпадает:
802dot11_frame.gif
Весь заголовок присутствует полностью. В i/o порта WiFi все первые 44 байта. Дальше не знаю и к заголовку это не относится, т.к. там уже шифровка
А в вашей картинке обведенные данные похожи на приляпанный спец заголовок к WiFi фрейму, совершенно не относящийся к передаваемым/принимаемым данным.
 
Последнее редактирование:
A

AlexeyGR

New member
я сверял принятый frame:
Код: 
  |  DATA RX LEN[128]
  | 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
---------------------------------------------------
00| 09 10 0C 01 00 00 00 00 00 00 01 00 80 00 00 00
10| FF FF FF FF FF FF EE  C F6 CD E2 10 EE  C F6 CD
20| E2 10 A0  J BF F1  v 88 87 01 00 00  d 00 11 04
30| 00 0D  K  e  e  n  e  t  i  c  -  9  6  3  7 01
40| 08 82 84 8B 96 12  $  H  l 03 01 01  2 04 0C 18
50|  0  ` 07 06  R  U    01 0D 14  3 08    01 02 03
60| 04 05 06 07  3 08  ! 05 06 07 08 09 0A 0B 05 04
70| 00 01 00 0E DD  ' 00  P F2 04 10  J 01 00 0C 01
---------------------------------------------------
с перехваченным в NetMon:
http://rghost.ru/77p5p5PQ6
pvvx написал(а):
похожи на приляпанный спец заголовок к WiFi фрейму
Нажмите для раскрытия...
тогда это приляпывает NetMon, CommView...
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу