• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

BLE SoC PHY6202

pvvx

Активный участник сообщества
И это не особо удивляет, т.к. среда разработки кода - Keil. Она не предполагает интерактивного анализа кода. Только автор может понимать что и где у него там прописано с остальными связями в проекте. А код дописывался путем вставки новых функций по заказу и тяп-ляп, на отвяжитесь, без анализа и структурирования.
 

pvvx

Активный участник сообщества
Никто и не желает копаться в этой помойке. От этого чипы PHY идут в реальную помойку.
А копошение с WCH принуждается низкой ценой на чипы. И там есть какая-то документация на сам чип.
 

cool2000

Member
А без этого не получится получить ACK/NACK, или Старт/Стоп, или Clock Stretching.
А нужно?
C:
int i2c_master_send(uint port, ushort dev_addr, byte *data, uint size)
{
    AP_I2C_TypeDef *pi2c = AP_I2C0;
    if(port == 1)
    {
        pi2c = AP_I2C1;
    } 
    hal_i2c_addr_update(pi2c, dev_addr);
    ret = hal_i2c_send(pi2c, data, size);
    while(hal_i2c_wait_tx_completed(pi2c)) {}
    WaitUs(100);
  
    return 0;
}

int i2c_master_receive((uint port, ushort dev_addr, byte *data, uint size)
{
    AP_I2C_TypeDef *pi2c = AP_I2C0;
    if(port == 1)
    {
        pi2c = AP_I2C1;
    } 
  
    ret = hal_i2c_read(pi2c, dev_addr, 0, data, size);
  
    return 0;
}
pvvx написал(а):
Можно только догадываться о глубине FIFO регистра данных.
Не нужно.
Код:
#define I2C_FIFO_DEPTH          8
#define I2C_NUMBER_DATA_RX_FIFO(pi2cdev)   (pi2cdev->IC_RXFLR)
#define I2C_NUMBER_DATA_TX_FIFO(pi2cdev)   (pi2cdev->IC_TXFLR)
pvvx написал(а):
Правда все эти быты можно выудить путем тыркания и наблюдая в осцилл.
При наличии большого желания их можно посмотреть в i2c.h.
 

cool2000

Member
Никто и не желает копаться в этой помойке.
Так уже выяснили, что разрабатывали тяп-ляп в рамках отмывания денег по госконтракту. Железо слепили, софт уже полноценно не потянули, а на документацию вообще забили, судя по описанию.
среда разработки кода - Keil
Ещё и половину библиотеки Keil в ROM запихали.
В итоге, для передачи температуры и влажности в BLE, того, что есть в SDK хватает?
 

pvvx

Активный участник сообщества
Так уже выяснили, что разрабатывали тяп-ляп в рамках отмывания денег по госконтракту. Железо слепили, софт уже полноценно не потянули, а на документацию вообще забили, судя по описанию. Ещё и половину библиотеки Keil в ROM запихали.
В итоге, для передачи температуры и влажности в BLE, того, что есть в SDK хватает?
Там нет функций calback при передаче BLE рекламы - вы не можете узнать когда идет реклама, по какому поводу был "разбужен" SoC и т.д.
А ROM - это хорошо, т.к. там много нужных функций.

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

pvvx

Активный участник сообщества
Есть другой путь - в SDK есть пример RAW рекламы, тупо по таймеру. Он работает, но всё остальное, типа соединения и OTA не будет.
Т.к. есть типовая функция RX2TX или TX2RX. К этим сИкретным функциям задаются все интервалы, тип PHY и т.д. На них базируется вся система и стеки BLE/Zigbee/...
К ним китайцы и налепили своих веток обработки по китайской грамоте.
И есть функция таймера. Больше и не нужно.
Весь код будет к десятку килобайт :)
SDK в принципе не нужен.
 

pvvx

Активный участник сообщества
Измерения показывают, что время активности при RAW рекламе на данном чипе - менее 4 мс при передаче маяка с полными 31 байтами по 3-м каналам.

Т.е. просыпание SoC занимает чуть более 1 мс, затем 3 мс передача с паузами и переключениями каналов и в сон.
3 мс передача - это если длина передаваемых данных в пакете максимальна для BT4.2 (стандарта рекламы).
В других случаях будет меньше.
 

pvvx

Активный участник сообщества
Во время работы приемо-передатчика I2C работает.
I2C fifo-шная - закидали в неё задачу, через время получили и считали данные. CPU на время работы I2C не нужен.
 

pvvx

Активный участник сообщества
Функции RX2TX/TX2RX в SoC выполняются аппаратно, без CPU, обычно DMA или FIFO. CPU тупо не успеет и занимается только подготовкой и анализом что там прилетело.
В BLE рекламе после TX окно всего в 500 мкc на прием заголовка запроса активной рекламы или соединения.
У маяка приема нет. Он не имеет в заголовке бит "соединения" или запросов. Но должен выдержать паузу для переключения сторонних приемников на другой канал.
 

pvvx

Активный участник сообщества
Приемник работает так-же - заряжает RX2TX и CPU ждет отработки.
Но дети, поколения Arduino, считают по своему - ждут минимум 2 рекламных события (передачу по 3-м каналам) для подачи запроса на соединение. И считают таймауты.
Все пользователи из-за них должны ждать, пока произойдет прием второго рекламного события. А если возникнет помеха, то всё с начала или выход по ошибке таймаута.
А таймаут в Linux принят отсебятенный. Точнее его сломали, т.е. произвели вредительство, кенты из Intel в kernel ещё в 2014..2015 году... Обрезав до 2..4 сек
До этого он был по спецификации Bluetootch SIG - интервал рекламы до 10 сек. Т.е. для Windows и Linux это будет 20 секунд.
Обосновали это блокировкой драйвера. Дети Arduino умеют писать код только в линеечку, без событий и мультизадачности. Предел - while(millis < x).
По этому в Linux ныне блокировка дров на время выполнения одной операции :) :)
 

pvvx

Активный участник сообщества
В Android ядро перековырял Google и исправил эти безобразия. Но не все - всё исправить уже невозможно, т.к. леминги от Arduino прут бесконечно.
Android хватает прием одного пакета, как и предусматривалось в аппаратуре.
И т.к. Android проприетарен, то туда не пускают вредителей от Zigbee и только там доступно BT5.4 и всякие LE Long Range полностью вытесняющие Zigbee и альтернативы типа "Материи".
 

cool2000

Member
Уже не помню, где-то скачал st17h66-sdk. В нём есть помимо исходников BLE, два примера с интересными функциями внутри
aoa_test
C:
/*********************************************************************
    @fn      PhyPlusPhy_ProcessEvent

    @brief   Simple BLE Peripheral Application Task event processor.  This function
            is called to process all events for the task.  Events
            include timers, messages and any other user defined events.

    @param   task_id  - The OSAL assigned task ID.
    @param   events - events to process.  This is a bit map and can
                     contain more than one event.

    @return  events not processed
*/
uint16 PhyPlusPhy_ProcessEvent(uint8 task_id, uint16 events)
{
    VOID task_id;

    if (events & PPP_PERIODIC_EVT)
    {
        if(s_phy.Status==PHYPLUS_RFPHY_TX_ONLY
                || s_phy.Status==PHYPLUS_RFPHY_TRX_ONLY)
        {
            phy_rf_tx();
        }
        else if(s_phy.Status==PHYPLUS_RFPHY_RX_ONLY)
        {
            phy_hw_stop();
            phy_rf_rx();
        }

        osal_start_timerEx(PhyPlusPhy_TaskID,PPP_PERIODIC_EVT,s_phy.Intv);
        return(events ^ PPP_PERIODIC_EVT);
    }

    if(events & PPP_RX_DATA_PROCESS_EVT)
    {
        phy_rx_data_process();
        return(events ^ PPP_RX_DATA_PROCESS_EVT);
    }

    return 0;
}
smart_rf
C:
/*********************************************************************
    @fn      PhyPlusPhy_ProcessEvent

    @brief   Application Task event processor.  This function
            is called to process all events for the task.  Events
            include timers, messages and any other user defined events.

    @param   task_id  - The OSAL assigned task ID.
    @param   events - events to process.  This is a bit map and can
                     contain more than one event.

    @return  events not processed
*/
uint16 PhyPlusPhy_ProcessEvent(uint8 task_id, uint16 events)
{
    VOID task_id;

    if (events & PPP_PERIODIC_TX_EVT)
    {
        if(s_phy.Status==PHYPLUS_RFPHY_IDLE)
        {
            s_phy.Status = PHYPLUS_RFPHY_TX_ONLY;
            s_phy.rfChn = BLE_ADV_CHN37;
            s_pktCfg.wtSeed = WHITEN_SEED_CH37;
            phy_rf_tx();
            osal_start_timerEx(PhyPlusPhy_TaskID,PPP_PERIODIC_TX_EVT,s_phy.txIntv);
        }
        else
        {
            LOG("SKIP TX_EVT Current Stats %d\n",s_phy.Status);
            osal_start_timerEx(PhyPlusPhy_TaskID,PPP_PERIODIC_TX_EVT,20);
        }

        return(events ^ PPP_PERIODIC_TX_EVT);
    }

    if (events & PPP_PERIODIC_RX_EVT)
    {
        if(s_phy.Status==PHYPLUS_RFPHY_IDLE)
        {
            s_phy.Status = PHYPLUS_RFPHY_RX_ONLY;
            s_phy.rfChn = BLE_ADV_CHN37;
            s_phy.rxScanT0 = read_current_fine_time();
            s_pktCfg.wtSeed = WHITEN_SEED_CH37;
            phy_rf_rx();
            osal_start_timerEx(PhyPlusPhy_TaskID,PPP_PERIODIC_RX_EVT,s_phy.rxIntv);
        }
        else
        {
            LOG("SKIP RX_EVT Current Stats %d\n",s_phy.Status);
            osal_start_timerEx(PhyPlusPhy_TaskID,PPP_PERIODIC_RX_EVT,20);
        }

        return(events ^ PPP_PERIODIC_RX_EVT);
    }

    if(events & PPP_RX_DATA_PROCESS_EVT)
    {
        phy_rx_data_process();
        return(events ^ PPP_RX_DATA_PROCESS_EVT);
    }

    if(events & PPP_TX_DONE_EVT)
    {
        process_tx_done_evt();
        return(events ^ PPP_TX_DONE_EVT);
    }

    if(events & PPP_RX_DONE_EVT)
    {
        process_rx_done_evt();
        return(events ^ PPP_RX_DONE_EVT);
    }

    if(events & PPP_TRX_DONE_EVT)
    {
        //TODO
        return(events ^ PPP_TRX_DONE_EVT);
    }

    return 0;
}
Это не то, что нужно?
 

pvvx

Активный участник сообщества
И т.к. в Linux накопилось куча г... в самом ядре, то перейти к поддержке BT5.0 (стандарт 2016 года) уже невозможно. Никакой Bluez это не исправит - его кучи AРI давно необходимо переписывать с нуля. Иначе никак. Затыканием патчами или новыми дополнениями в функциях API это уже не исправить - беда в алгоритмах.
И так со всем, что есть в kernel с 2016 года. Ни одной полной реализации ни одного нового стандарта по аппаратуре. Вплоть до CPU и SSD.
 

pvvx

Активный участник сообщества
Это не то, что нужно?
Дык говорил уже - RAW реклама есть в типовом SDK от PHY.
PHY62XX_SDK_3.1.1\example\PhyPlusPhy\smart_rf
Переключение передачи по 3-м каналам
C:
static void process_tx_done_evt(void)
{
    /**
        37->38->39 adv channel
    */
    if(s_phy.rfChn==BLE_ADV_CHN37)
    {
        s_phy.rfChn = BLE_ADV_CHN38;
        s_pktCfg.wtSeed = WHITEN_SEED_CH38;
        phy_rf_tx();
    }
    else if(s_phy.rfChn==BLE_ADV_CHN38)
    {
        s_phy.rfChn = BLE_ADV_CHN39;
        s_pktCfg.wtSeed = WHITEN_SEED_CH39;
        phy_rf_tx();
    }
    else if(s_phy.rfChn==BLE_ADV_CHN39)
    {
        s_phy.Status = PHYPLUS_RFPHY_IDLE;
    }
}
И т.д.
Там всё просто, но кривописано. Перепишите проще.

Сам пример не годится - в нем беда со sleep - что-то не так и большой ток во "сне"
 

pvvx

Активный участник сообщества
Без Power Profiler вы ничего не сделаете из этого примера нормального, как и из других.
 

cool2000

Member

pvvx

Активный участник сообщества
Какой из примеров был взят за основу?
Немного модифицированный на прошлом SDK.
Не зря ранее долго бились за потребление...

Но в нем возможности перехвата события BLE рекламы :p
И там куча лишнего - повторяю - у автора нет Power Profiler и всё сделано по стороннему указанию.
 

pvvx

Активный участник сообщества
Я недавно заказал новый nRF Power Profiler II - приколоться ещё раз, но уже по полной. Старый отдал "нуждающемуся" как только опробовал и понял что это прикол, а не измеритель.
Но для отладки он годится. С ним видно что творится, но не надо обращать внимание на выбросы на его графиках и на замеры среднего потребления, при авто-переключении шунтов...
Дешевле и сразу готовых всё равно в продаже нет.
Альтернативой может являться осел с 20 битами разрешения. Диапазона более 0..100кГц не требуется, т.к. везде в питании кондеры...
 

pvvx

Активный участник сообщества
Пока не хватает понимания.
Ну вписал чтение датчика и тяп-ляп в рекламу BTHome. Тяп-ляп - нету в SDK возможности перехвата события передачи рекламы, а так же смены данных в рекламе. Только хитростями...
1703257750825.png
Итог: ~14.2 мкА при опросе датчика и передаче каждые 2.5 секунды, а там уж что адаптер словит...
hex приложен:
 

Вложения

Сверху Снизу