5 ms·

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 s

by 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
        I'm not sure I would believe the comment by the person who you are responding to.
        mindslight 11y ago
        > their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc This is a quite serious concrete accusation. It would put Microchip in the company of Tivo and Sveasoft - not simply ignoring the GPL, but actively attacking it through bad-faith contractual restrictions. But yes, I would definitely have to see the specific license for myself before forming any conclusions. HN is essentially just gossip, and GP could have very well interpreted a clause too broadly. But I'm not interested in sorting through what's new in the Microchip world just to preemptively answer this, especially because he could be referring to a single specific library that would be hard to find.
        jason_s 11y ago
        Microchip does have a standard license for maybe 99% of its firmware libraries, that includes this proviso, that just forbids you from using the software on microcontrollers made by other manufacturers: Microchip licenses to you the right to use, modify, copy and distribute Software only when embedded on a Microchip microcontroller or digital signal controller that is integrated into your product or third party product (pursuant to the sublicense terms in the accompanying license agreement). If there are any other restrictions, I'm not aware of them.
- 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

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
        I'm not sure I would believe the comment by the person who you are responding to.
        mindslight 11y ago
        > their libraries come with a license forbidding you from using them with a compiled-from-source version of gcc This is a quite serious concrete accusation. It would put Microchip in the company of Tivo and Sveasoft - not simply ignoring the GPL, but actively attacking it through bad-faith contractual restrictions. But yes, I would definitely have to see the specific license for myself before forming any conclusions. HN is essentially just gossip, and GP could have very well interpreted a clause too broadly. But I'm not interested in sorting through what's new in the Microchip world just to preemptively answer this, especially because he could be referring to a single specific library that would be hard to find.
        jason_s 11y ago
        Microchip does have a standard license for maybe 99% of its firmware libraries, that includes this proviso, that just forbids you from using the software on microcontrollers made by other manufacturers: Microchip licenses to you the right to use, modify, copy and distribute Software only when embedded on a Microchip microcontroller or digital signal controller that is integrated into your product or third party product (pursuant to the sublicense terms in the accompanying license agreement). If there are any other restrictions, I'm not aware of them.
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.