Embedded: svd2nim for read/write of ARM Cortex micros

> Are you compiling with -d:danger --opt:size? I tried them and did not see much difference, though I have not tried all Items from the analysis. My `nim.cfg` has `checks:off` which I find more calming than `d:danger`. I will leave `opt:size` in my nim.cfg. The case I want to fix first is Item

Embedded: svd2nim for read/write of ARM Cortex micros

I am not using those options. I will give them a try after this. I just created a repo, [nucleo_blink](https://github.com/dwhall/nucleo_blink), that might help you recreate my work. It's a VSCode project that will recommend the PlatformIO extension. Then there's also a `platformio.ini` file that

Embedded: svd2nim for read/write of ARM Cortex micros

Hi! Could you let me know how you produced the assembly output (for a specific proc?). I'll play around with different (nim) codegen options and see how that ends up compiled by gcc. Are you compiling with -d:danger --opt:size?

procs: forward declaration

Nim does have a mechanism to achieve this cross module forward declaration and it is as always generics or template. A generic based implementation is as follows: type ImplIt = distinct void proc doThing(t: typedesc[ImplIt]) = mixin doOtherThing doOtherThing()

Embedded: svd2nim for read/write of ARM Cortex micros

I just added Item 5 to [the analysis](https://github.com/dwhall/nimbed/wiki/svd2nim-analysis) which shows that `modifyIt()` with more than one operation in its body results in bloated code and needs work.

How doeas NIM differ from Mojo programming language?

There are couple of good points for Mojo 1. it's tiny, they say it's like syntactic sugar for MLIR (MLIR is LLVM v2). That means that the lang development progress going to be very fast, as the runtime is already there. 2. Made by Crhis Lattner, he's already done Swift for LLVM, so Mojo is n

Atlas shrugged...

We don't deviate from Nimble unnecessarily. > Or is it just recommended to use a custom task name for customized/advanced > builds? Yes.

How doeas NIM differ from Mojo programming language?

One of the main ideas behind mojos syntax is: Mojo aims to be compatible with Python, enabling an easier transition from Python to mojo. Similar to C++ to C, it is a superset of Python. In other words, you can copy and paste your existing Python code into a mojo file and it should run. If you w

Atlas shrugged...

Will atlas support custom build commands? Currently nimble does not allow you to override the build task. Or is it just recommended to use a custom task name for customized/advanced builds?

neovim lsp setup: no autocompletion and suggestion

What your are looking for is the tab completion, try any nvim plugin to connect the lsp with it an example of using nim is here:

Embedded: svd2nim for read/write of ARM Cortex micros

Special thanks to these projects, `nim-platformio` and `svd2nim`, I've been able to get an LED to blink on a ST Nucleo F446RE board ([details](https://github.com/dwhall/nimbed/wiki)). I've had a brief chat with @auxym regarding `svd2nim` since he's the most recent developer for `svd2nim`. But I

neovim lsp setup: no autocompletion and suggestion

Thank you for your response! I've done it right now as you said: I have 3 Nim Commands to start (NimDocOf, NimReferences and NimTypeOf). If i start them - every command works! But what must i do, if i wanna see after 3 characters typing, which posibilities i have to choose from? For example i

neovim lsp setup: no autocompletion and suggestion

Not sure how LSP works in Neovim, but in normal Vim you have to set up your own keybindings for the LSP stuff. Have you tried positioning your cursor somewhere and run one of the LSP commands manually?

neovim lsp setup: no autocompletion and suggestion

Hello, i am sorry but i have another question regarding the neovim nim setup... I am playing around to configure nimlsp on neovim for 2 weeks now - and now i try to find someone here, who has an up and running neovim nimlsp lua-config... Is there anybody out there? For a better understanding i

procs: forward declaration

well with treeform's example it actually does that, but that's only because once `mylibFunction` is inlined the proc call with appear. If you add anything more complex inbetween (like a echo in my case) it doesn't work anymore, because C compilers don't seem to reason at such grand scheme about

procs: forward declaration

LTO should handle it as long as your callback is not `.closure`.

procs: forward declaration

if you like paying for the indirect branch I guess...