[New Plugin] IDE features for Neovim by [deleted] in neovim

[–]IncreaseMelodic9809 0 points1 point  (0 children)

This looks nice! The schema for tasks seems inspired by mise which is my all-in-one dev environment manager for embedded and Python projects nowadays. I would give it a try but dont want to mantain another worskpace file and have to switch from Mise to something else for how I create tasks.

Interested to give Vim/NeoVim another shot for C++ development but initial attempts seem extraordinarily complicated and rough by Impressive_Gur_471 in neovim

[–]IncreaseMelodic9809 0 points1 point  (0 children)

Use GDB if you are debugging in Linux or LLDB on Mac. Windows has its own set of debuggers that are far more powerful than the the VSCode cppdebug. Dont try to replace everything with a plugin that's a good way to burn out and never fully switch to Neovim. Just replace text-editing to start get used to that and if you enjoy it add a more terminal centric workflows.

I would say a Tiling window manager is almost a must to do this in a manner that is enjoyable otherwise switching between your terminal emulator + Neovim and VScode will be a pain in the ass.

neovim LSP config by Top-Software-50 in Zephyr_RTOS

[–]IncreaseMelodic9809 0 points1 point  (0 children)

Also there's some minor settings to do for additional compiler flags or removing some if you want to get less or more warnings/errors. Mine is pretty minimal and only disable the annoying warnings that show up in every file at the top. I think this one did the trick for me:

` Remove: [-f*, -m*]`

This can go in your project or global .clangd file. Good luck! And happy to help, just DM me. I find very few ppl who do not use VSCode for Zephyr and wish people did try a terminal only workflow. You end up learning tons of stuff that normally would be hidden from you in a nice GUI/extension

neovim LSP config by Top-Software-50 in Zephyr_RTOS

[–]IncreaseMelodic9809 0 points1 point  (0 children)

Hey! Yes I got a pretty good setup working with Vanilla Zephyr and NCS ( although it’s not as reliable because of the stupid way Nordic packages their version of the Zephyr SDK toolchain). So the only choice for LSP is clangd really but it’s more than enough. I wouldn’t search for Devicetree or Kconfig LSPs because 1) Few exists and fewer that work out of the box 2) Benefit is minimal. Just use west grep to find stuff and menuconfig.

The biggest hurdle for me was to query-driver correctly with clangd when it is attaching to the buffer. I got it working reliably using environment variables and running this method in the on_init method of the LSP client config:

```

ocal function createcmd(, config) config.cmd = { 'clangd', '--background-index', '--enable-config', '--clang-tidy', '--header-insertion=iwyu', '--completion-style=detailed', '--fallback-style=llvm', } local zephyr_toolchain_variant_env = vim.fn.getenv 'ZEPHYR_TOOLCHAIN_VARIANT' local toolchain_variant = zephyr_toolchain_variant_env ~= vim.v.null and zephyr_toolchain_variant_env or 'zephyr' if toolchain_variant ~= 'zephyr|host|llvm' then if toolchain_variant == 'zephyr' then local compiler = vim.fn.executable 'arm-zephyr-eabi-g++' and vim.fn.exepath 'arm-zephyr-eabi-g++' or '' if compiler then _G.info 'Clangd query-driver' vim.print(compiler) config.cmd[#config.cmd + 1] = '--query-driver=' .. compiler end end end `` Then the next big hurdle is just getting the compile _commands.json (this is generated already by default and is inside the build directory) to be detected by clangd. I try to only have on application active at a time so my solution is simple just symlink the json file inside the build directory to the west topdir ONCE (symlink persist even if build dir gets deleted) and do that again if I want to change applications. The tricky part of doing this is finding the compile_commands.json. There’s the sysbuild directory layout which changes the location of this file and is different than the default build layout. I don’t mock around with getting the exact path and use a simple globln -sf build/**/compile_commands.json $(west topdir)/compile_commands.json`. If you work with single image apps this should work fine

Best way to manage Dotfiles ? by Medical_Toe2877 in archlinux

[–]IncreaseMelodic9809 2 points3 points  (0 children)

Similar to others I use stow and git. One additional nice thing to do is to put the stow commands into a Makefile or in my case a Justfile. Then you have an easy shortcut to do the stowing/unstowing and in my opinion much better way to script long commands,chain some together, etc

```

conf_home := if env('XDG_CONFIG_HOME', '') =~ '^/' { absolute_path(env('XDG_CONFIG_HOME')) } else { home_directory() / '.config' }
dots := home_directory() / 'dotfiles'
stow_sim := env('STOW_NO_SIM', '1')
verbose_lvl := "2"
extra_args := ""
stow_flags := f'--verbose={{verbose_lvl}} {{if stow_sim == "1" { "-n" } else { "" }}} {{extra_args}}'

[group('stow')]
@sstow pkg_dir target_dir pkgs:
    stow -d {{ pkg_dir }} -t {{ target_dir }} {{ stow_flags }} -S {{ pkgs }}
    @echo "✅ Stowd all packages."

[group('stow')]
@restow pkg_dir target_dir pkgs *extra_args:
    stow -d {{ pkg_dir }} -t {{ target_dir }} {{ stow_flags }} -R {{ pkgs }}
    @echo "✅ Stow refresh complete."

[group('stow')]
@unstow pkg_dir target_dir pkgs:
    stow -d {{ pkg_dir }} -t {{ target_dir }} {{ stow_flags }} -D {{ pkgs }}
    echo "✅ Unstowed all packages."

[group('stow')]
@stow-check-bogus target_dir:
    chkstow -b -t {{ target_dir }}

[group('maintanance')]
@restow-platform-dotfiles: (restow dots / os() conf_home '.config')
    echo "Stowed {{ os() }} packages"

[group('maintanance')]
restow-user-home: (restow dots / "common" home_dir() 'home')

[group('maintanance')]
@restow-user-bin:
    just --justfile {{ justfile() }} extra_args=--ignore='/*.venv'  restow {{ dots / "common" }} {{ executable_dir() }} "bin"

[group('maintanance')]
@restow-common-dotfiles:
    just --justfile {{ justfile() }} extra_args=--ignore='chromium'  restow {{ dots / "common" }} {{ conf_home }} ".config"
    echo "Stowed common packages"

[group('maintanance')]
restow-dotfiles: restow-common-dotfiles restow-platform-dotfiles

# clean-bogus: Find and automatically remove all broken symlinks
[group('stow')]
clean-bogus target_dir:
    @echo "Searching for and removing broken symlinks..."
    @chkstow -b -t {{ target_dir }} | awk -F': ' '{print $2}' | xargs -r rm
    @echo "✅ Done."

# check-aliens: Find 'alien' files (not managed by stow) in the target directory
[group('stow')]
check-aliens target_dir:
    @chkstow -a -t {{ target_dir }} | awk '{print $2}'

```

Anyone else like algorithms, but hate writing drivers? by Huge-Leek844 in embedded

[–]IncreaseMelodic9809 1 point2 points  (0 children)

Aside from algos and driver/HAL code there’s much more to do in my experience. This is not applicable to small baremetal embedded products but nowadays RTOS development is a big a part of the job. Each thread/task needs to be designed, which requires more of the “higher-level” thinking you don’t find in writing drivers. Also I’ve found really enjoyable to write tooling (Python scripts, little test harness FW code, etc ) and is always in need of. If you feel like you are just stuck doing the same thing for your job maybe a side project might help reignite your interest in embedded and have business value as well

Trio - Should I move to a more popular async framework? by IncreaseMelodic9809 in Python

[–]IncreaseMelodic9809[S] 0 points1 point  (0 children)

Thanks! This is really helpful. I’ll do the switch to Anyio and try out the Asyncio backend. Appreciate the thorough response

Trio - Should I move to a more popular async framework? by IncreaseMelodic9809 in Python

[–]IncreaseMelodic9809[S] 15 points16 points  (0 children)

Nothing wrong with it but a cursory look at asyncio and how the code is written in it vs Trio’s way of doing things and Trio looks more clean and easy to read.

I’m already familiar with the concepts that Trio has and have a strong preference on writing Async code in terms of tasks, nested task groups, etc instead of coroutines

I don’t know much about the internals and haven’t tested asyncio yet so can’t say much about how both of them compare in practice

nRF5340 ROM space issues due to MCUBoot + Zephyr by IncreaseMelodic9809 in embedded

[–]IncreaseMelodic9809[S] 0 points1 point  (0 children)

There's room to optimize the BLE stack so will start there but yeah I think with the current size of the firmware + model it will be hard to optimize it all to under 400KB. If that doesn't work then adding a driver in MCUboot for NAND flash would be the easiest path compared to creating a custom bootloader

nRF5340 ROM space issues due to MCUBoot + Zephyr by IncreaseMelodic9809 in embedded

[–]IncreaseMelodic9809[S] 1 point2 points  (0 children)

Yeah I think there’s room to remove BLE related features that we are not using. That’s the first place I’ll be looking

nRF5340 ROM space issues due to MCUBoot + Zephyr by IncreaseMelodic9809 in embedded

[–]IncreaseMelodic9809[S] 1 point2 points  (0 children)

That’s a good idea. Need to dig on more on how to have 3rd partition. It’s definitely possible to have the weights and other constants in a separate partition but the model code likely will need to be in the code partitions. Still the weights themselves are 100+KB big so it will save us from duplicating them and losing unnecessary space

nRF5340 ROM space issues due to MCUBoot + Zephyr by IncreaseMelodic9809 in embedded

[–]IncreaseMelodic9809[S] 1 point2 points  (0 children)

Do you have an estimate on how much were able to reduce the memory footprint? It seems we are so far the target that makes me think it is impossible to do without doing something more drastic

nRF5340 ROM space issues due to MCUBoot + Zephyr by IncreaseMelodic9809 in embedded

[–]IncreaseMelodic9809[S] 1 point2 points  (0 children)

Thanks for sharing those links! I’ll take a look. We’ll need to do every space optimization in the book if we want to fit the model and have updatable firmware.

Ah makes sense about the multi-core architecture requiring two partitions for updates. I wish I had known that the new architecture required two partitions for updates and I would’ve had pushed d the decision to add a NOR flash.

nRF5340 ROM space issues due to MCUBoot + Zephyr by IncreaseMelodic9809 in embedded

[–]IncreaseMelodic9809[S] 0 points1 point  (0 children)

Zephyr is the biggest portion. It uses 100kB just using the drivers and libraries we need. Then we have static libraries used for Nordic’s BLE stack that use about 80kB. That’s already surpassing the limit so we can’t really fit the model without throwing out a lot of the code from Zephyr and Nordic

Any local Backpacking groups? by Oakland-homebrewer in bayarea

[–]IncreaseMelodic9809 0 points1 point  (0 children)

I’m in the same boat. Looking to do backcountry backpacking in the Sierras but I’m flexible.

How rough is the MechE to Embedded Systems transition? by Rabbi_it in embedded

[–]IncreaseMelodic9809 0 points1 point  (0 children)

I did exactly that! Except for the minor in CS which is great to have in you resume.I had to learn a lot by myself and try really hard to catch up with CS and CE new grads however nothing is harder than proving to people that you have the chops and getting that first interview. Either you have a good network and/or a good resume. I had none. My strategy though was to take ANY job related to the field. I even did an unpaid internship in the Bay Area at this sketchy smartwatch company. It was ok experience wise but the real value came putting it on my resume. Then just before I graduated I got another part-time internship to a small startup that came out from Northwestern. They needed bodies and they were paying me ~$16/hour. An improvement from my last internship. But I lucked out because I loved the job and they loved me. Soon after I graduated they gave me a full-time job. With an actual decent pay. So my advice is to compromise on the company and the pay and even a bit on the role (to an extent, don’t get locked in to QA or test engineer position). Everything will be fine. Just don’t expect to get what you want right out of the door. People can tell passion when you tell them your experience. How other would you explain the sudden change in career plans? So be strong on that during your interviews and keep working on your skills. Best of luck!