Hello,

I installed Ubuntu a few months ago on my work laptop and I’ve been running and loving it since.

However, I am used to VsCode, so this is what I am using in Ubuntu as well.

So I am curious, what kind of coding so you do? And what is your workflow.

I am an embedded firware developper and mainly use C. I am cross compiling my code in VsCode for a FPGA from Xilinx (dual core arm + PL)

Never dove into make files and cmake more than what I needed in the past, but I had an opportunity to learn CMake and build a project from it.

So my workflow is :

  1. Code in VsCode
  2. Build in CMake
  3. Transfer the app through scp on the target with a custom script (target is running petalinux, which is yocto + Xilinx recipes)
  4. Use gdb server to debug the code.

It’s a pretty simple workflow, but I’d like to know what you guys are running so that I can maybe upgrade my workflow.

  • nickwitha_k (he/him)@lemmy.sdf.org
    5·
    1 year ago

    I vehemently dislike coding directly on my workstation and do all of my development in remote VMs via SSH, when possible. My work MBP is a glorified SSH terminal with a web browser. I got my start in the industry with remote SysAdmin stuff so, it feels pretty natural.

    For an IDE, I use Neovim, currently with a plugin distribution - Neovim because I got used to the vim syntax as a SysAdmin and the distribution because I can’t justify sinking more time into tuning my env for a bit but am intending to scrap it all around the holidays or so.

    Most of my work is in Go or Python. At home, it’s a mix of CircuitPython, C, and I’m picking up some Rust (mainly embedded for C and Rust). Will be starting to learn Verilog this weekend.

    For Go and Python, I tend to lean towards a TDD approach, even if it gets a bit derided by coding streamers.

    My workflow tends to be:

    1. Prototype desired functionality to get at least individual parts working.
    2. Start from scratch and rough out any classes/structs and test suite boilerplate.
    3. Start the red->green->refactor loop, giving extra granularity to parts of code that I am less confident in.
    4. Once all intended functionality is implemented, run manual tests (I generally develop tools).
    5. Fix bugs that unit tests failed to prevent or I failed to anticipate.
    6. Repeat 4 and 5 until acceptable.
    7. Prepare commit.
    8. Push commit and receive failure because I haven’t fully configured my formatters to clean trailing whitespace and VT100-compatible line lengths.
    9. Push commit again and send for code review.

    Currently, my build automation is kinda in CMake. Really, the Makefile is just calling a build in a docker container.

    For C, Rust, and Verilog, I’m not yet familiar enough to have yet established workflows.

    ETA: I think I just got the same FPGA as you! Xilinx Zync-7020 (Digilent Arty Z7-20).

    • Croquette@sh.itjust.worksOP
      2·
      1 year ago

      Almost the same FPGA, we use the Mars ZX2 from Enclustra which uses the zynq7010.

      The TDD approach is a hard sell to companies because it’s hard to quantify what time is saved in the end and the MBAs of this world have a hard time with that.

      • nickwitha_k (he/him)@lemmy.sdf.org
        2·
        1 year ago

        I think that some companies and devs also have a bad taste in their mouth due to overzealous adopters and policies, along with using mocks that are not necessarily going to maintain parity with their production counterparts. Some things are a bit silly to test and mocks like that are going to introduce future technical debt.