[muravei 7]

17 часов назад, backa сказал:

например пути к файла - папки отделяют нижним подчеркиманием

Да, это есть, я уже про это забыл , делаю автоматически. 🙂

Тут target_link_libraries - с нижним подчеркиванием ( из сдк)

Остальные   с прямым  "/" .  С папкой или без - по логике.

У меня была проблема с подключение одной библиотеки, все компилировалось, но случался  HardFault . Я его обошел : Скопировав все исходные си в 

add_executable  . Думаю, что проблема была в cmake_minimum_required - слишком новая.

16 часов назад, backa сказал:

когда пробует писать в stack_ptr[0] = (uintptr_t) entry

Это настройка стека ? Я так глубоко не копал. 

У меня одно ядро подготавливало данные в буфере , давало команду второму послать их по SPI, общался через  fifo. 

С прерыванием от пинов  пока не получилось , второе не прерывается.

[backa 1]

5 hours ago, muravei said:

Это настройка стека ? Я так глубоко не копал.

это стандартная либа SDK - я обычно "глубоко копаюсь"  в SDK только если они не работают-глючат (опыт использования SDK от TI TivaC приучил меня к этому - там настолько все "вылизано" , что писать занавоно свое на регистрах - результат будет тотже). Я просто прошелся по шагам по стандартным функциям инициализации "второго" ядра , чтобы понять чтоже такое "накомпилировал" Keil, что его код сваливаеться в рабочих исходниках (я этот "проект" на коленке слепил 2 года назад из стандартного примера из Pico-PIO-USB для моего ZX-Spectrum  на FPGA ) в Hard Fault.

Только Keil вытворяет такое при компиляции - посему пришлось отказаться от тщетных попыток практического применения его в работе с PicoW.

А тем временем , чтобы подпитать неугосающий интерес к этой веселой штучке "RP2040" я вчера купил парочку модулей Pico 2 W на RP2350 - к сожалению это ревизия забагованная ревизия кристалла "A2" с печальноизвестной проблемой "RP2350-E9"

Она решается внешними резисторами 8К2 на все GPIO к земле. Datasheet впечатляет обьемом ))) Это уже ближе к взрослым микроконтроллерам от ST с их манулами по 3-5тыс страниц на крисстал.

В итоге, сравнив работу в Keil & MS VS рабочей программы,  я пришел к выводу , что причина Hard Fault кроется в неверной компиляции программы с поддержкой 2х ядер в среде Keil (как следствие недостаточных настроек для компиляции или в принципе отстуствия "полной" поддержки этого микроконтроллера на уровне многоядерности - история об этом умалчивает и документации по настройкам НЕТ ). И MS VS  и IAR прекрасно "шагают" в отладке и просто работают в обычном режиме без Hard Fault.

[jcxz 342]

5 часов назад, backa сказал:

Только Keil вытворяет такое при компиляции - посему пришлось отказаться от тщетных попыток практического применения его в работе с PicoW.

...

В итоге, сравнив работу в Keil & MS VS рабочей программы,  я пришел к выводу , что причина Hard Fault кроется в неверной компиляции программы с поддержкой 2х ядер в среде Keil (как следствие недостаточных настроек для компиляции или в принципе отстуствия "полной" поддержки этого микроконтроллера на уровне многоядерности - история об этом умалчивает и документации по настройкам НЕТ ). И MS VS  и IAR прекрасно "шагают" в отладке и просто работают в обычном режиме без Hard Fault.

Может стоит сюда выложить - что такое "вытворяет" Keil? и при компиляции какого именно кода? Чтобы все знали и не попались на удочку.

5 часов назад, backa сказал:

в принципе отстуствия "полной" поддержки этого микроконтроллера на уровне многоядерности

Компилятору не нужно поддерживать никакую "многоядерность". Он даже знать о ней не обязан. Да и микроконтроллер ему тоже нет надобности поддерживать. Ему нужно поддерживать только ядро микроконтроллера (т.е. - его ЦПУ). Компилятору этого достаточно.

А вот написателю кода знать и поддерживать многоядерность - обязательно. Иначе HF (или того похуже) - неизбежны.  

[backa 1]

1 hour ago, jcxz said:

А вот написателю кода знать и поддерживать многоядерность - обязательно. Иначе HF (или того похуже) - неизбежны.

К сожалению я не могу себя приписать к большим знатокам этого микронтроллера и уж тем более опытным кодописателем для многоядерных систем (не было нужды раньше в этом). Когда-то давно немного модицировав пример для данного микронтролера я получил рабочий девайс USB контроллера для моих поделок в ZX-Spectrum-строении на FPGA .... на том и успокоился , перейдя на uPython для него же. Вот сейчас хотелки для "толстого" FPGA возросли и тут уже питон не тянет в силу своей сути. Надо возвращаться в родную обитель - к Си))) Тем более за 2 года там много чего подшлифовали с SDK 1.5.1.

Вот хотел, добавив работу с I2C и SPI переферией , вникнуть в принципы многопроцессорности . Пока не очень получаеться(((... с многопроцессорностью и Cmake-технологиями (как уже сказал выше - ввиду отсутсвия вменяемой документации на это).

[backa 1]

6 hours ago, jcxz said:

Может стоит сюда выложить - что такое "вытворяет" Keil? и при компиляции какого именно кода? Чтобы все знали и не попались на удочку.

а там и выкладывать нечего - любой пример из папки multicore  из примеров к SDK. Если у кого-то получиться запустить хоть один - буду ОЧЕНЬ признателен.

[muravei 7]

6 часов назад, backa сказал:

Если у кого-то получиться запустить хоть один

hello_multicore, multicore_fifo_irqs, multicore_runner_queue эти у меня работали ( все , которые пробовал)

Но там стек - по умолчанию. 

18 часов назад, backa сказал:

в SDK только если они не работают-глючат

Так вы попробуйте по умолчанию, может вы неправильно бутерброд едите  параметры задаете.

[backa 1]

1 hour ago, muravei said:

7 hours ago, backa said:

 

hello_multicore, multicore_fifo_irqs, multicore_runner_queue эти у меня работали ( все , которые пробовал)

Но там стек - по умолчанию. 

я имел ввиду запустить их в KEIL. Я нисколько не сомневаюсь в их работоспособности. Я же сам использовал один из примеров для своего проекта .

[jcxz 342]

17 минут назад, backa сказал:

я имел ввиду запустить их в KEIL. Я нисколько не сомневаюсь в их работоспособности. Я же сам использовал один из примеров для своего проекта .

Если один и тот же код, будучи скомпилён одним компилятором - работает, а скомпилённый другим - не работает, то тут одно из двух:

1. Кривой код.
2. Кривой компилятор.

Исходя из опыта: второе - многократно менее вероятно, чем первое.

 

Потому и был вопрос про пример "вытворений" Keil.

[backa 1]

31 minutes ago, jcxz said:

Если один и тот же код, будучи скомпилён одним компилятором - работает, а скомпилённый другим - не работает, то тут одно из двух:

1. Кривой код.

я внес самые минимальные изменения в функции , не связанные с мультиядерностью. В VS все компилируеться и работает. В Keil компилируеться и работает до момента инициализации второго ядра ( я привел место где все крашится). Я еще раз скажу что пробовал другой пример применения многоядерностии ( дабы отвязаться от причины #1)  и там тотже результат. НF сразу на запуске второго ядра . Компилятор у KEIL  четко о рабатывает свою работу а вот с адресацией памяти чтото не так.

[muravei 7]

19 минут назад, backa сказал:

вот с адресацией памяти чтото не так.

Вот я это и хотел предложить сравнить.

Может с этим:

Memory Configuration

Name                 Origin                 Length             Attributes
FLASH                0x10000000         0x00200000         xr
RAM                  0x20000000         0x00040000         xrw
SCRATCH_X        0x20040000         0x00001000         xrw
SCRATCH_Y        0x20041000         0x00001000         xrw
*default*            0x00000000         0xffffffff

Или с работающим примером.

Цитата

В VS все компилируеться и работает. В Keil компилируеться

 

[backa 1]

 

2 hours ago, muravei said:

Вот я это и хотел предложить сравнить.

через часик ( на работе немного занят ) обязательно сравню и отпишусь ( может и проект ппостой ) выложу , если найду в куче папок алятестовых проектов "проб-и-ошибок" ))))

[backa 1]

2 hours ago, muravei said:

Вот я это и хотел предложить сравнить.

Spoiler

#include <stdio.h>
#include <stdint.h>
#include <stdbool.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"
#include "hardware/irq.h"
#include "hardware/adc.h"
#include "cmsis_compiler.h"
#include "hardware/uart.h"
 
#include "RTE_Components.h"
#include <assert.h>
 
// Core 1 interrupt Handler
void core1_interrupt_handler()  
{
 
    // Receive Raw Value, Convert and Print Temperature Value
    while (multicore_fifo_rvalid())
    {
        uint16_t raw = multicore_fifo_pop_blocking();
        const float conversion_factor = 3.3f / (1 << 12);
        float result = raw * conversion_factor;
        float temp = 27 - (result - 0.706)/0.001721;
        printf("Temp = %f C\n", temp);         
    }
 
    multicore_fifo_clear_irq(); // Clear interrupt
}
 
// Core 1 Main Code
void core1_entry()  
{
    // Configure Core 1 Interrupt
    multicore_fifo_clear_irq();
    irq_set_exclusive_handler(SIO_IRQ_PROC1, core1_interrupt_handler);
 
    irq_set_enabled(SIO_IRQ_PROC1, true);
 
    // Infinte While Loop to wait for interrupt
    while (1){
        tight_loop_contents();
    }
}
 
// Core 0 Main Code
int main(void)
{
    stdio_init_all();
    multicore_reset_core1();

   
    multicore_launch_core1(core1_entry); // Start core 1 - Do this before any interrupt configuration
 
    // Configure the ADC
    adc_init();
    adc_set_temp_sensor_enabled(true); // Enable on board temp sensor
    adc_select_input(4);
 
    // Primary Core 0 Loop
    while (1)  
    {
        uint16_t raw = adc_read();
        multicore_fifo_push_blocking(raw);
        sleep_ms(1000);
    }
}

 

Исходник взят тут

Basic_Multicore_Pico_Project.zip

[Serhiy_UA 1]

Для оценки производительности Raspberry Pi Pico и подбора IDE использовал тест на длительность периода переключения состояния вывода. Последовательно опробовал следующее:

1.     MicroPithon с редактором Me. Период переключения около 10 мкс, что совсем не подходит.

2.     Arduino с языком Arduino C. Период переключения на функциях около 1.5 мкс, тоже долговато.

3.     VS Code c C-SDK на Win10. Помучался неделю, результат нулевой, так и не установил.

4.     Вернулся к Arduino, но уже с языком C++. Период переключения на регистрах получил около 30 нс, то есть около 33 МГц. Это мне подходит, даже очень.

Остановился пока на 4-ом варианте. Программа с тестом на 30 нс в приложении. Там же программа работы с двумя процессорами при мигании независимо двумя светодиодами. Буду пока развивать это направление.

test_Arduino.zip

[mantech 124]

6 минут назад, Serhiy_UA сказал:

2.     Arduino с языком Arduino C. Период переключения около 1.5 мкс, тоже долговато.

4.     Вернулся к Arduino, но уже с языком C++. Период переключения получил около 30 нс, это мне подходит, даже очень.

Чет не понял про С и С++, там С что-ли в режиме интерпретации работает?

[backa 1]

13 minutes ago, Serhiy_UA said:

1.     MicroPithon с редактором Me. Период переключения около 10 мкс, что совсем не подходит.

вставлю свои мысли по этому пункту. Питон конечно изначально не имеет отношения к "быстроте" работы))) Но если скрестить ужа с ежом то можно выйти на 1мкс( это по памяти на вскидку - давновато делал проект подключения 8битноной паралельной шины к  дисплею,  используя для критических по времени кусков програмы технологию PIO).Достаточно шустро дергала программа всеми 8мю выводами. Иначе бы на дисплеи 800*480 был бы слайд шоу. Исходники брал на гитхабе и немного переделал под свои хотелки.

 

посмотрел проект - 2.6MHz при стандартной скорости тактовой.