5 ms·

The author (me) frankly hates C and C++. Haven't touched it for use on a PC since 2009. However I use it every day for my job working on dsPIC motor control, be

by jason_s 11y ago

The author (me) frankly hates C and C++. Haven't touched it for use on a PC since 2009. However I use it every day for my job working on dsPIC motor control, because I have no better options. When I am trying to teach someone about algorithms, I turn to Python because it is more readable, quicker for me to write, it's platform-independent, and I can incorporate it into an IPython (now Jupyter) Notebook and postprocess that into my blog articles with a minimum of hiccups.

3pt14159 11y ago
Have you checked out Nim? I've been using it in production for a couple small programs and I've had no issue. I've also been able to bind it to higher level languages using the FFI: http://nim.community/answers/create_a_shared_library/ http://nim.community/answers/create_a_shared_library/ Although I haven't figured out the garbage collection bit for the shared object bit. It is a lovely language and it's reaching 1.0 sometime this year.
- jason_s 11y ago
  I've heard of it. Rust is probably the most promising to me. Unfortunately just because a language exists, doesn't mean it is usable on a particular embedded system architecture. The processor core and system libraries need support.
  - mindslight 11y ago
    Rust works fine with Cortex-M3/M4 (a bit larger than dsPIC, and their documentation isn't as nice as Microchip's). Library support isn't great though - try zinc.rs or roll your own. An STM32F4 Discovery board is $15. Just in case you didn't have enough to play with...
    - jason_s 11y ago
      well, I work for Microchip, so I won't be writing code for other manufacturers' processors, at least not for my day job :-)
      - mindslight 11y ago
        Well then go lobby for creating dsPIC support in LLVM! Selling 10M chips at a time is great and all, but designs start with a single engineer. The 16F84 was the hobbyist darling until gcc-avr ate its lunch.
        jason_s 11y ago
        >Well then go lobby for creating dsPIC support in LLVM! Um. Been there, done that. Well, you see, [: discussion of internal politics deleted :]
        makomk 11y ago
        PIC is not an open-source-friendly company. They literally wrapped a license manager around gcc and used it as their C compiler on several platforms, and their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc. If they did switch to LLVM, it'd probably be so they could closed-source their compilers completely.
        mindslight 11y ago
        Sheesh. I worked with their 8-bit chips in an era when using a C compiler was essentially just a nicer syntax for ASM (and you really didn't want to deal with code written by someone who thought differently). In that environment, their easily available good documentation is about as close as you can get to Free. Software complexity was of course on the rise and I figured it was only a matter of time until they "got it" with regards to a Free C compiler etc. It's sad to hear that they've dug their heels in even further and are now one of the few examples of bad-faith attacking the GPL through contracts. Especially because recently reading their ENC28J60 documentation was a nice break after wading through STM/ARM's stuff. If I'm ever again in a position where I'm choosing chips for a production design, I'll be verifying what you said for myself (diligence) and then steering clear to less risky alternatives.
        jason_s 11y ago
    - mokus 11y ago
      Shameless self-plug coming here, but it's pretty directly relevant: I've recently started tinkering with rust on a handful of STM32 "discovery" boards. I'm currently focusing on building a low-level environment to use as a foundation for higher-level HAL projects like zinc. The code is still pretty rough around the edges and evolving fast, but I'm open to collaboration and willing to help deal with breakage due to the current pace of change, as time permits, if anyone just wants to build something on it. https://github.com/mokus0/stm32.rs https://github.com/mokus0/stm32.rs
      - mindslight 11y ago
        I was/am doing something similar (haven't touched it in a bit though). I avoided putting anything in linker scripts that didn't have to be there (IIRC, memory blocks and VTOR (for assembly startup routine that can handle flash or RAM)). Peripheral addresses stayed in Rust so that the optimizer could see them (eg writing to RA and then RB, the high u16 stays the same). BTW F103C8 "dev boards" are available from China for $5.
        mokus 11y ago
        zinc's "ioregs" macro system takes care of that sort of optimization quite nicely these days, actually. For each peripheral register, one of the things it generates is an "update" structure that the optimizer can eliminate, which allows you to chain updates to multiple fields in a single write. For example, in my stm32f4-discovery "blinky" example it does the bsrr writes to flip 2 LEDs in a single write (I've inspected the generated asm to verify this). EDIT: nevermind, I realize I misunderstood; you're referring to the optimizer being able to see that both reg addresses have the same high 16 bits. I thought you were referring to the actual interactions with the register contents. Yea, that makes sense. EDIT 2: for what it's worth, i did a quick test just now and found that moving the addresses into the source actually made the generated code significantly worse. I'm just tinkering around on a lunch break and I need to get back to real work, so I can't investigate too deeply, but the 2 biggest factors I see are that (1) it simply doesn't perform the optimization you describe, and (2) it makes things even worse because rather than addressing relative to the peripheral base address it loads a complete new constant address for every operation.
  - 3pt14159 11y ago
    Well Nim is essentially just C, although there is some weirdness before it hit 1.0 (like big ints everywhere). Try it out and run the tests. If they pass, then you are probably in good hands.

by jason_s 11y ago

3pt14159 11y ago

Have you checked out Nim? I've been using it in production for a couple small programs and I've had no issue. I've also been able to bind it to higher level languages using the FFI: http://nim.community/answers/create_a_shared_library/ http://nim.community/answers/create_a_shared_library/ Although I haven't figured out the garbage collection bit for the shared object bit. It is a lovely language and it's reaching 1.0 sometime this year.

jason_s 11y ago
I've heard of it. Rust is probably the most promising to me. Unfortunately just because a language exists, doesn't mean it is usable on a particular embedded system architecture. The processor core and system libraries need support.
- mindslight 11y ago
  Rust works fine with Cortex-M3/M4 (a bit larger than dsPIC, and their documentation isn't as nice as Microchip's). Library support isn't great though - try zinc.rs or roll your own. An STM32F4 Discovery board is $15. Just in case you didn't have enough to play with...
  - jason_s 11y ago
    well, I work for Microchip, so I won't be writing code for other manufacturers' processors, at least not for my day job :-)
    - mindslight 11y ago
      Well then go lobby for creating dsPIC support in LLVM! Selling 10M chips at a time is great and all, but designs start with a single engineer. The 16F84 was the hobbyist darling until gcc-avr ate its lunch.
      - jason_s 11y ago
        >Well then go lobby for creating dsPIC support in LLVM! Um. Been there, done that. Well, you see, [: discussion of internal politics deleted :]
      - makomk 11y ago
        PIC is not an open-source-friendly company. They literally wrapped a license manager around gcc and used it as their C compiler on several platforms, and their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc. If they did switch to LLVM, it'd probably be so they could closed-source their compilers completely.
        mindslight 11y ago
        Sheesh. I worked with their 8-bit chips in an era when using a C compiler was essentially just a nicer syntax for ASM (and you really didn't want to deal with code written by someone who thought differently). In that environment, their easily available good documentation is about as close as you can get to Free. Software complexity was of course on the rise and I figured it was only a matter of time until they "got it" with regards to a Free C compiler etc. It's sad to hear that they've dug their heels in even further and are now one of the few examples of bad-faith attacking the GPL through contracts. Especially because recently reading their ENC28J60 documentation was a nice break after wading through STM/ARM's stuff. If I'm ever again in a position where I'm choosing chips for a production design, I'll be verifying what you said for myself (diligence) and then steering clear to less risky alternatives.
        jason_s 11y ago
  - mokus 11y ago
    Shameless self-plug coming here, but it's pretty directly relevant: I've recently started tinkering with rust on a handful of STM32 "discovery" boards. I'm currently focusing on building a low-level environment to use as a foundation for higher-level HAL projects like zinc. The code is still pretty rough around the edges and evolving fast, but I'm open to collaboration and willing to help deal with breakage due to the current pace of change, as time permits, if anyone just wants to build something on it. https://github.com/mokus0/stm32.rs https://github.com/mokus0/stm32.rs
    - mindslight 11y ago
      I was/am doing something similar (haven't touched it in a bit though). I avoided putting anything in linker scripts that didn't have to be there (IIRC, memory blocks and VTOR (for assembly startup routine that can handle flash or RAM)). Peripheral addresses stayed in Rust so that the optimizer could see them (eg writing to RA and then RB, the high u16 stays the same). BTW F103C8 "dev boards" are available from China for $5.
      - mokus 11y ago
        zinc's "ioregs" macro system takes care of that sort of optimization quite nicely these days, actually. For each peripheral register, one of the things it generates is an "update" structure that the optimizer can eliminate, which allows you to chain updates to multiple fields in a single write. For example, in my stm32f4-discovery "blinky" example it does the bsrr writes to flip 2 LEDs in a single write (I've inspected the generated asm to verify this). EDIT: nevermind, I realize I misunderstood; you're referring to the optimizer being able to see that both reg addresses have the same high 16 bits. I thought you were referring to the actual interactions with the register contents. Yea, that makes sense. EDIT 2: for what it's worth, i did a quick test just now and found that moving the addresses into the source actually made the generated code significantly worse. I'm just tinkering around on a lunch break and I need to get back to real work, so I can't investigate too deeply, but the 2 biggest factors I see are that (1) it simply doesn't perform the optimization you describe, and (2) it makes things even worse because rather than addressing relative to the peripheral base address it loads a complete new constant address for every operation.
- 3pt14159 11y ago
  Well Nim is essentially just C, although there is some weirdness before it hit 1.0 (like big ints everywhere). Try it out and run the tests. If they pass, then you are probably in good hands.