• Система автоматизации с открытым исходным кодом на базе 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 приложен:
 

Вложения

Сверху Снизу