ollamaのモデルを変えてみた

昨日はとりあえずのcodeサポート用のモデルを入れてみたけど、結構重量級だったので同等性能でも負荷が軽いモデルに、同時に編集時のtab補完してくれる軽量モデルを設定してみた

% ollama list
NAME                 ID              SIZE      MODIFIED
qwen2.5-coder:14B    9ec8897f747e    9.0 GB    28 minutes ago
qwen2.5-coder:7b     dae161e27b0e    4.7 GB    44 minutes ago

Continueのconfig.jsonファイルの設定

tabAutocompleteModel:このブロックがタブ補完時のLLM指定

{
  "models":[
   {
      "title": "Main Coder (14B)",
      "provider": "ollama",
      "model": "qwen2.5-coder:14b"
     }
    ],
  "tabAutocompleteModel": {
    "title": "Tab Autocomplete",
    "provider": "ollama",
    "model": "qwen2.5-coder:7b"
  }
}

qwen2.5-coder:14b:メモリ使用量がmaxでも24GB程度で収まるようになったので、こちらにしよう

しかしLocal LLMは特にプログラム言語系の変化の早い領域ではRAG使うようにしないと実質的には使えないね、次はRAG使えるようにしよう

 

admin

ContinueでVScodeのA.I補完

VScodeでcopilotというは安定してるけど、無償だと限度があるから補完的にLocal LLMを使ってみる

<環境>

M4 MacBook Pro/32GB

<手順>

deepseek-coder-v2:latestがそこそこらしいからollamaに追加する

% ollama list
NAME                         ID              SIZE      MODIFIED
deepseek-coder-v2:latest     63fb193b3a9b    8.9 GB    5 hours ago

動かすとメモリは30GB程度消費するからyellow markレベルだけど動作はできる

・ブラウザからの使用

Docker経由が環境を汚染しないからそのやり方で、8080はDcoker内部のportで外部にはport 3000で公開される

% docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Dockerでの見え方

・VScodeからの使用

① 拡張機能 Continueをインストールする

② Continueのための設定ファイルを作る

% mkdir -p ~/.continue
code ~/.continue/config.json

VScodeのエディタが起動するので、以下を入力

{
  "models": [
    {
      "title": "DeepSeek Local",
      "provider": "ollama",
      "model": "deepseek-coder-v2:latest"
    }
  ],
  "defaultModel": "DeepSeek Local"
}

設定を保存してVScodeを再起動すると、codeの選択 -> 右クリックでContinueのchat/edit起動ができる、Continue自体のwindowsは左側に開く

感覚、まあまあ使えるかなと思う、Rustの組み込みとかはまだ学習レベルが低い感じはあるけどね

 

admin

 

ラズピコrustでmicro:bitと連携させてみた

ラズパイ財団プロダクト同士でなんか作ってみようと思って、micro:bitをフロントエンドとしてmic入力とLED出力を使った、音声のレベル表示(一応LED25個で25レベルの表示ができます)をやってみた

macro:bit (p1) –> ラズピコADC1(平均化処理)-> PWM出力およそ22KHzをrcでローパス -> micro:bit(p2)という流れ

<micro:bit側のコード>

from microbit import *

def show_bar(level):  # level: 0-25
    display.clear()
    height = level // 5  # 5段に分割
    width = level % 5    # 各段の幅
    
    # 下からバー積み上げ
    for y in range(5):
        if 4-y < height:
            for x in range(5):
                display.set_pixel(x, 4-y, 9)
        elif 4-y == height:
            for x in range(width):
                display.set_pixel(x, 4-y, 9)

while True:
    mic_level = microphone.sound_level()
    pin1.write_analog(mic_level * 4)
    
    control_level = pin2.read_analog()
    # 0-25に変換
    bar_level = min(control_level // 40, 25) 
    show_bar(bar_level)
    sleep(10)

<ラズピコ側>

Cargo.toml

embedded-halの1.0系は0.2と互換なし、embeded-halはobject指向言語で言うところのinterfaceでrp-235x-halは実装、つまりプロセッサが変わっても共通だろうinterfaceをembedded-halはtraitの集合として持っている


[package]
edition = "2024"
name = "rust_starter"
version = "0.1.0"
license = "MIT or Apache-2.0"


[dependencies]
cortex-m = "0.7.7"
cortex-m-rt = "0.7.5"
rp235x-hal = "0.3"
embedded-hal = "0.2"
#embedded-hal = "1.0.0" does not support rp235x-hal yet
defmt = "1.0.1"
defmt-rtt = "1.0.1"
panic-probe = { version = "1.0", features = ["print-defmt"] }

[build-dependencies]
regex = "1.11.0"

[target.'cfg( target_arch = "arm" )'.dependencies]
panic-probe = { version = "1", features = ["print-defmt"] }

[target."thumbv8m.main-none-eabihf".dependencies]
rp235x-hal = { version = "0.3", features = ["rt", "critical-section-impl"] }

<Rustコード>

Lチカコードを修正

#![no_std]
#![no_main]

use defmt_rtt as _;
use hal::pac;

use embedded_hal::adc::OneShot;
use embedded_hal::blocking::delay::DelayUs;
use embedded_hal::PwmPin;

#[cfg(target_arch = "riscv32")]
use panic_halt as _;
#[cfg(target_arch = "arm")]
use panic_probe as _;

// Alias for our HAL crate
use hal::entry;

#[cfg(rp2350)]
use rp235x_hal as hal;

#[cfg(rp2040)]
use rp2040_hal as hal;

// use bsp::entry;
// use bsp::hal;
// use rp_pico as bsp;

/// The linker will place this boot block at the start of our program image. We
/// need this to help the ROM bootloader get our code up and running.
/// Note: This boot block is not necessary when using a rp-hal based BSP
/// as the BSPs already perform this step.
#[unsafe(link_section = ".boot2")]
#[used]
#[cfg(rp2040)]
pub static BOOT2: [u8; 256] = rp2040_boot2::BOOT_LOADER_W25Q080;

/// Tell the Boot ROM about our application
#[unsafe(link_section = ".start_block")]
#[used]
#[cfg(rp2350)]
pub static IMAGE_DEF: hal::block::ImageDef = hal::block::ImageDef::secure_exe();

/// External high-speed crystal on the Raspberry Pi Pico 2 board is 12 MHz.
/// Adjust if your board has a different frequency
const XTAL_FREQ_HZ: u32 = 12_000_000u32;
const DELAY: u32 = 1000; // μs delay
const SAMPLES: u32 = 250;

/// Entry point to our bare-metal application.
///
/// The `#[hal::entry]` macro ensures the Cortex-M start-up code calls this function
/// as soon as all global variables and the spinlock are initialised.
///
/// The function configures the rp2040 and rp235x peripherals, then toggles a GPIO pin in
/// an infinite loop. If there is an LED connected to that pin, it will blink.
#[entry]
fn main() -> ! {
    // 1. Peripherals取得
    let mut pac = pac::Peripherals::take().unwrap();

    // 2. クロック・ウォッチドッグ初期化
    let mut watchdog = hal::Watchdog::new(pac.WATCHDOG);
    let clocks = hal::clocks::init_clocks_and_plls(
        XTAL_FREQ_HZ,
        pac.XOSC,
        pac.CLOCKS,
        pac.PLL_SYS,
        pac.PLL_USB,
        &mut pac.RESETS,
        &mut watchdog,
    )
    .ok()
    .unwrap();

    // 3. GPIO初期化
    let sio = hal::Sio::new(pac.SIO);
    let pins = hal::gpio::Pins::new(
        pac.IO_BANK0,
        pac.PADS_BANK0,
        sio.gpio_bank0,
        &mut pac.RESETS,
    );

    let mut delay = hal::Timer::new_timer0(pac.TIMER0, &mut pac.RESETS, &clocks);

    // 4. ADC設定
    let mut adc = hal::Adc::new(pac.ADC, &mut pac.RESETS);
    let mut adc_pin = hal::adc::AdcPin::new(pins.gpio26).unwrap();

    // 5. PWM設定
    let pwm_slices = hal::pwm::Slices::new(pac.PWM, &mut pac.RESETS);
    let mut pwm = pwm_slices.pwm0;
    pwm.set_ph_correct();
    pwm.set_top(4095);
    pwm.enable();

    // GP0 = PWM Slice 0 Channel A(alomost 20KHz duty 99% @3.3v full scale)

    let mut pwm_channel = pwm.channel_a;
    let _pwm_pin = pins.gpio0.into_function::<hal::gpio::FunctionPwm>(); // GP0 as a PWM output

    loop {
        let mut sum: u32 = 0;

        // measure "samples" time and make average
        for _ in 0..SAMPLES {
            let v: u16 = adc.read(&mut adc_pin).unwrap();
            sum += v as u32;
        }

        let avg = (sum / SAMPLES) as u16;
        pwm_channel.set_duty(avg);
        delay.delay_us(DELAY);
    }
}

/// Program metadata for `picotool info`
#[unsafe(link_section = ".bi_entries")]
#[used]
pub static PICOTOOL_ENTRIES: [hal::binary_info::EntryAddr; 5] = [
    hal::binary_info::rp_cargo_bin_name!(),
    hal::binary_info::rp_cargo_version!(),
    hal::binary_info::rp_program_description!(c"Blinky Example"),
    hal::binary_info::rp_cargo_homepage_url!(),
    hal::binary_info::rp_program_build_attribute!(),
];

// End of file

動いてるところの動画は以下に、

まだ周辺回路サポートのcrateは途上ではあるけれども、組み込みでも普通に使えるようになってきたのは大きな進歩

 

admin

ラズピコでRust

ラズベリー財団がVScodeのpcio拡張機能でRust(実はZephyrも)サポートするようになったので動かしてみた

<構成と環境>

・ラズピコ2(無線なし)

・M4 MacBook Pro 32GB

・純正デバッグプローブ

 

<手順>

すでにインストール済みのpico拡張機ののメニューにはRustプロジェクト作成のメニューが出ています

ここでNew Rust Projectを選択するとLチカのサンプル、実は初代ラズピコやラズピコのRISCコア対応にもなってます、が開かれます

ラズピコ2にデバッガー接続、ピン立っていないので追加で半田付けして接続

接続確認は、

% probe-rs list
The following debug probes were found:
[0]: Debug Probe _CMSIS_DAP_ -- 2e8a:000c:E663AC91D3826F39 (CMSIS-DAP)

のように見えればつながっています

 

この状態でほぼすぐにデバッグができました、Runはファイルモードでしか機能しませんがデバッグは上位互換なので問題なし、デバッグだと.uf2のファイルも必要なくて、バイナリそのままがラズピコに書き込まれます

これ、デバッガーでブレークポイント設定して止めたとこ

 

めちゃくちゃ簡単に環境構築できるから、まだ無線関連のcrateは不備だけど、もうRustでできることはRust以外の選択は、ラズピコではないと思う

 

admin

STM32開発環境はVScodeにしない方が正解

STM32のVScode拡張機能でサポート出来るらしいのでやってみたけど、既存のraspberry picoのc開発環境を破壊してしまう

具体的にはVScodeの全体設定ファイルであるsetting.json、

~/Library/”Application Support”/code/User/settings.json

をSTM32の拡張機能がある状態ではstm32の環境に汚染(上書き)させてしまう、profileを分離というのもあるんだろうけど、そんな面倒なことやるなら、STM32の環境ではbuildはCubeIDE(クラシックだけど確実)で実行してソースコードのupdateはたとえばcursorとか使い分けるのが正解だよね

実はraspberry pico tool(VScode拡張機能)もc言語のbuild環境構築を楽にするためのツールなんだけどね

もはやラズピコもRustを公式でサポート(Wi-Fi, BLEはcrateが未完)始めてんだから、今後はc言語使わなければいけないケースは徐々に減っていくよ間違いなく

それと、これから参入の若手はRustとcどっち選ぶと言われたら、間違ってもcは選ばないはずだしね

ということでc言語は他に選択できない時だけ使うようにしましょう

 

admin

 

スペアナの見栄えを改善

ベースレベルがかなりバタつくので、平均化処理を入れてみた

やっていることは、過去の平均値の重み付け0.9、最新の計算値の重み付け0.1で加算していくだけ、ベースレベルが暴れなくなるので視覚上の効果は結構大きい改善、スペアナ的になるという意味でね

	/* 5. 平均化と実効値計算(振幅スペクトル : db) */
	for (uint32_t i = 0; i < FFT_LEN / 2; i++) {
		float32_t real = fft_out[2 * i];
		float32_t imag = fft_out[2 * i + 1];
		cur[i] = (real * real + imag * imag) * HANN_GAIN_CORRECTION + 1e-12f;
		// averaging
		if (first) {
			fft_ave[i] = cur[i];
		} else {
			fft_ave[i] = fft_ave[i] * 0.9f + cur[i] * 0.1f;
		}
		fft_rms[i] = (int16_t) (10.0f * log10f(fft_ave[i]));
	}
	first = false;	// to set first flag to false

<写真>

<条件>

以前の記事と変わらずですが、

・入力は5KHzのduty50%のPWM

・ADCサンプリング周波数 200KHzで一次IIRフィルタ(cut off 20KHz)処理後に1/5 decimation

・Hann windows処理

・FFT実行後に平均化処理後に対数スケール変換

前の記事の補足でも書いたけど、一次IIRフィルタにすることで15KHzの第三高調波はほぼ理論通りのおよそ10db(正確には9db)に収まってる、ただし20KHzに近づくとノイズレベルが落ちているのはフィルターの影響です

 

admin

 

spi LCDにFFT結果を表示させる

前回からの続きですが、spi LCD (320*240 : st7789)に結果を表示させます

一点ハマりどころは、ドライバーの標準サポートが240*240までのこと

https://github.com/AlexKaut/ST7789-STM32-DMA

実は単純に数字の書き換えだけではうまくいかなくて、結局数箇所変更

物理インターフェースはspi2使うように.hファイル変更(これは以前に実施済み)

/* choose a Hardware SPI port to use. */
#define ST7789_SPI_PORT hspi2		// to accommodate with actual usage
extern SPI_HandleTypeDef ST7789_SPI_PORT;

画面サイズの定義は、これも.hファイル変更

#ifdef USING_240X320
    #if ST7789_ROTATION == 0 || ST7789_ROTATION == 2
        #define ST7789_WIDTH  240
        #define ST7789_HEIGHT 320
    #else
        #define ST7789_WIDTH  320
        #define ST7789_HEIGHT 240
    #endif

    #define X_SHIFT 0
    #define Y_SHIFT 0
#endif

に変更


初期化の処理に最後に、これは.cファイル変更

void ST7789_Init(void)

 	ST7789_SetRotation(ST7789_ROTATION);	// to change for using 320*240 Panel
 	
 を追加、

この変更で、320*240でかつローテーション表示(横方表示)ができるようになりました、結果表示はこんな感じですが、

<動画はこちら>

マイムービー – 大- 540p

 

<気付き>

① ノイズレベルがかなり変動、それはFFT処理の中身からしてそう言うものらしいので見せるための処理、例えば平均化とかが必要、USBオシロのFFT機能で見るとフラットに見える、ただしS/Nが基本波で60db程度取れているのはほぼ同等

② 基本波と第三高調波の差が見かけ20db程度ある、入力は5KHzのDuty 50%のPWMなので理屈ではおよそ9dbぐらいの際になるはず、ノイズレベルのカーブからするとADCの入力にこんな周波数特性があるのかもしれない

–> 今の二次のIIRフィルタは15KHzで10db程度減衰することが問題なのでカットオフ20KHzの一次IIRフィルタに変更でまともそうになった、ノイズレベルも均一化してるしね

LCDへの表示処理は見かけ1秒近くかかっているので、FFT処理は比較すると瞬時

実測でFFT計算関連書処理時間はおよそ3.2ms、512samples*40Kspsだとおよそ13msなので十分にFFT処理は高速、実際のFFT計算は0.5msぐらいで完了するだろうから前後の処理が大半を占めています

<rtosの処理>

・ADCサンプル/FFT実行タスク

表示タスクにはFETした結果が準備できたら通知(xTaskNotifyGive)、LCD表示タスク側の処理が終わったら送られる通知を待つ(ulTaskNotifyTake)

void StartTask02(void *argument) {
	/* USER CODE BEGIN StartTask02 */
	// ADC DMA start & Hann window coefficient calculation
	Init_HannWindow();	// to prepare Hann window coefficient
	Init_Iir_FFT_Instance();	// to initialize IIR filter and FFT instance

	HAL_ADC_Start_DMA(&hadc1, (uint32_t*) adc_dma_buff, DMA_COUNTS);
	HAL_TIM_Base_Start(&htim3);

	/* Infinite loop */
	for (;;) {
		Adc_Process();
		xTaskNotifyGive(lcd_TaskHandle);	// start LCD display task
		ulTaskNotifyTake(pdTRUE, portMAX_DELAY);// wait for LCD display completion
		osDelay(1);
	}
	/* USER CODE END StartTask02 */
}

・LCD表示タスク

void StartTask03(void *argument) {
	/* USER CODE BEGIN StartTask03 */
	ST7789_Init();
	ST7789_SetRotation(1);   // 90度回転
	ST7789_Fill_Color(BLACK);
	draw_fft_frame();
	/* Infinite loop */
	for (;;) {
		ulTaskNotifyTake(pdTRUE, portMAX_DELAY);	// wait for FFT data ready
		Lcd_Process();
		xTaskNotifyGive(adc_TaskHandle);	// restart FFT task
		osDelay(1);
	}
	/* USER CODE END StartTask03 */
}

もう少し中身を吟味して次のアクション決めよう

 

admin

freeRTOSのスタックサイズ(@STM32)

freeRTOSではデフォルトのスタックサイズ128wordsはFFTなどやらせると少なすぎます

どうなるかというとスタック食い潰して暴走するのが普通

<環境>

・STM32F401re

・CubeIDE 1.19.0(@M4 MacBook Pro Tahoe)

・タスク構成:default task/ADC結果をFFTするタスク(fft_task)/LCD表示制御用のタスク(lcd_task)

 

<スタックサイズ設定>

128wordsでは全く不足と思ったので1024wordsにしたらちゃんと動くようになった、以下はfreertosタスクの設定値、CubeMXで設定すると反映もされますがコードで入力もできる

<スタックサイズの取得>

おそらく一番スタックを消費するであろうfft_taskの最後部分に以下のコードを埋め込み

デバッガー起動してosDelay(1)をbreakpointにして取得した値は以下のとおり

単位はbytesだからword換算だとおよそ230wordsということなで、8割近くは消費しています、この変数はコード実行中の最小値を記録しているらしい

 

<FFTの実行結果>

まだLCDには表示できないので、デバッガーで取得した値をグラフ化してみた図

FFT実行部分のコード(ADC DMAのISRから起動されて、その後に計算実行

uint32_t flags = osThreadFlagsWait(0x01 | 0x02, osFlagsWaitAny,	// 0x01:half, 0x02:full
			osWaitForever);

	/* 1. int16 → float */
	uint32_t base = (flags & 0x01) ? 0 : ADC_RAW_LEN;// buffer start point set

	for (uint32_t i = 0; i < ADC_RAW_LEN; i++) {
		adc_q15_buf[i] = ((int16_t) adc_dma_buff[base + i] - 2048) << 4;
	}

	arm_q15_to_float(adc_q15_buf, adc_float_buf, ADC_RAW_LEN);

	/* 2. IIR + 1/5 デシメーション */
	uint32_t idx = 0;
	for (uint32_t i = 0; i < ADC_RAW_LEN; i += DECIMATE_FACTOR)
	{
		float32_t tmp;
		arm_biquad_cascade_df2T_f32(&iir_inst, &adc_float_buf[i], &tmp, 1);
		decimated_buf[idx++] = tmp;
	}

	/* 3. 窓関数適用*/
	arm_mult_f32(decimated_buf, hann_window, windowed_input, FFT_LEN);

	/* 4. FFT実行 */
	arm_rfft_fast_f32(&fft_inst, windowed_input, fft_out, 0);

	/* 5. 実効値計算(振幅スペクトル : db) */
	for (uint32_t i = 0; i < FFT_LEN / 2; i++) {
		float32_t real = fft_out[2 * i];
		float32_t imag = fft_out[2 * i + 1];
		fft_rms[i] = 10.0f
				* log10f(
						(real * real + imag * imag) * HANN_GAIN_CORRECTION
								+ 1e-12f);

 }

 

admin

 

STM32でCMSIS-DSP使うための設定

STM32でCMSIS-DSP使うの簡単かと思ったけど結構手間取ったので記録、FFT処理とかはCMSIS-DSP使うのが一番お手軽と思ったけどね、ラズピコでも使ったけどラズピコの方が構築は簡単、依存関係がないから

<環境>

・STM32CubeIDE 1.19

・STM32F401re(Nucleoボード)

・M4 MacBook Tahoe

 

<手順> — 以下の構成でDSP/Sourceは通常の使い方なら入れてはいけない、最後に理由追加、CMSIS-DSPのカスタマイズするなら別だけど

やる事を突き詰めれば必要なCore/DSPのincludeディレクトリを持ってきてパスに追加するということ

1. 新規プロジェクト作成

File → New → STM32 Project

MCU/Board Selector でターゲット MCU を選択

例:STM32F401RE

プロジェクト名を入力

Finish

2. 必要な CMSIS-Core / DSP を準備
2.1 CubeF4 パッケージの場所確認
~/STM32Cube/Repository/STM32Cube_FW_F4_Vx.xx.x/

存在を確認するディレクトリ:

Drivers/CMSIS/Core/Include
Drivers/CMSIS/Device/ST/STM32F4xx/Include
Drivers/CMSIS/DSP/Include

2.2 個別のプロジェクトにコピーする
元ディレクトリとコピー先
Drivers/CMSIS/Core/Include <Project>/Drivers/CMSIS/Core/Include
Drivers/CMSIS/Device/ST/STM32F4xx/Include <Project>/Drivers/CMSIS/Device/ST/STM32F4xx/Include
Drivers/CMSIS/DSP/Include <Project>/Drivers/CMSIS/DSP/Include

STM32CubeIDE では
CMSIS-DSP の主要関数は静的ライブラリ(.a)として提供されている

👉 arm_math.h(宣言)+ .a(実装)で利用が成立している、arm_math.cという巨大ファイルが以前のCubeIDEのバージョンではあったらしいけど今はない、標準以外が必要になるならもってきて追加する

・元ディレクトリ構造

3. 不要なファイルの除外
3.1 除外対象— 存在しない機能を使ったコードなので、とりあえずbuild対象から除外しないと全体buildできない
Drivers/CMSIS/DSP/Examples/
Drivers/CMSIS/Core/Template/
Drivers/CMSIS/DSP/ComputeLibrary/

SupportFunctions 内の 不要な .c

3.2 除外方法

フォルダ or 複数ファイル選択

右クリック → Resource Config → Exclude from Build

Debug / Release 両方 にチェック

4. インクルードパス設定
<Project>/Drivers/CMSIS/Core/Include
<Project>/Drivers/CMSIS/Device/ST/STM32F4xx/Include
<Project>/Drivers/CMSIS/DSP/Include

Properties → C/C++ General → Paths and Symbols

Language = GNU C

Debug / Release 共通

5. ビルド

Clean → Build

#include “arm_math.h” が解決される

arm_mult_f32() / arm_rfft_fast_f32() などの基本機能は 追加なしで使用可能

👉 実体は libarm_cortexM4lf_math.a に存在するから

6. 最終ディレクトリ構成
<Project>
Drivers/
CMSIS/
Core/Include/
Device/ST/STM32F4xx/Include/
DSP/Include/
DSP/Source/SupportFunctions/(いずれ必要な場合のみ)
Src/
Inc/

・CubeIDEのディレクトリ
斜線入りはそのディレクトリを右クリックでResouce ConfigulationsでExclude from Buildでbuild対象外にしているディレクトリ

P.S. 2026/1/17

実はCMSIS/DSP/Sourceは標準的な処理ならば不要、というか入れとくとSourceファイルがエラーの嵐になる、libarm_contexM4lf_math.a(Middlewares/ST/CMSIS/DSP/Lib/GCC配下)だけでほぼ事足りるから

 

admin

freeRTOSの周辺デバイスの初期化

昨日の記事で、

freeRTOSのユーザーコードを隔離する

debuggerもしくはrunでプログラム実行させると、LCD(st7789)画面が真っ黒な画面になることがままある、デバッガーで見る限りst7789のライブラリに制御は飛んで実行はされてるけど画面出ないというのは、初期化に失敗することがあるということだろう

理由は明確ではないけど、以下のmain.c中のuser code begin2の中から呼び出すとうまくいかないことがあって、気になるのはそのあとでfreeRTOS起動しているから関係あるとすればそれかな(ADC関連もいずれここから移動する、rtos化してない時の残渣コード)

元々がfreeRTOS化した時の処理分担のクリアさから言えば、main.cにはできるだけペリフェラル向けのロジックは記述しない(Nucleoの初期化だけは実装)で、個別ペリフェラル向けの処理はそれぞれのrtos処理モジュールに持っていくのが自然だと思うよね

で以下のようにLCD表示処理のタスクのfor loopの前でST7789_Init()を呼び出すと問題は出ていない、基本思想通り個別のペリフェラルの初期化処理及びその後の実行はすべてrtos側で受け持たせるのが自然だしバグの入る余地も少ないと思う

 

admin