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

[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]

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

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

 

[pvvx]

Всем привет!
Есть какая-либо информация по этим функциям:
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]

Начал более детально изучать примеры и наткнулся на такой вопрос.
в файле 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]

Начал более детально изучать примеры и наткнулся на такой вопрос.
в файле 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]

ets_timer_arm_new определена в библиотеке libmain.a

И каковы же её аргументы? us задается в uint32 или ограничено 1000 ?

Начал более детально изучать примеры и наткнулся на такой вопрос.
в файле 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-е?

 

[ihor]

ets_timer_arm_new определена в библиотеке libmain.a

Кто подскажет чем можно просмотреть содержимое библиотек с расширением а

 

[pvvx]

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

 

[Alex]

Кто подскажет чем можно просмотреть содержимое библиотек с расширением а

Ну видимо только дизассемблером

 

[pvvx]

Ну видимо только дизассемблером

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

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

 

[jcmvbkbc]

Кто подскажет чем можно просмотреть содержимое библиотек с расширением а

objdump. Можно распаковать на объектники командой ar.

 

[pvvx]

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

 

[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 указал другую длину.

 

[AlexeyGR]

Больше я на такое отвечать не буду

Где успел Вас "поймать", больше не буду.

 

[pvvx]

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

 

[AlexeyGR]

Дык вот - не выдает больше 128 байт.

Да..., это окончательный "вердикт"?
Более того, пакет сверху "обрезан" на 20 байт.

 

[pvvx]

Да..., это окончательный "вердикт"?
Более того, пакет сверху "обрезан" на 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 байта (похоже там только заголовок).

 

[AlexeyGR]

(похоже там только заголовок)

Вот как раз заголовок неполный...

 

[pvvx]

Вот как раз заголовок неполный...

Дык формат давай, а не картинки. А то искать нечего.
По этой картинке всё совпадает:

Весь заголовок присутствует полностью. В i/o порта WiFi все первые 44 байта. Дальше не знаю и к заголовку это не относится, т.к. там уже шифровка
А в вашей картинке обведенные данные похожи на приляпанный спец заголовок к WiFi фрейму, совершенно не относящийся к передаваемым/принимаемым данным.

 

[AlexeyGR]

я сверял принятый 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

похожи на приляпанный спец заголовок к WiFi фрейму

тогда это приляпывает NetMon, CommView...