Ultimately, the embedded space (including all sorts of low-level, retro, "bare-metal", remote etc. programming) has common needs and it would be convenient to see more widespread cooperation among these projects, improving reliability and avoiding wasteful duplication of work. More resources at https://github.com/rust-embedded/awesome-embedded-rust
People often have good reason to not adopt existing systems. Oxide started with TockOS and have written and talked about why they didn't end up using it.
Under the hood, cargo-embed, knurling's probe-run, and Humility are all built atop probe-rs (https://probe.rs/) to provide debugging - I think in this case it's actually a great example of cooperation between projects! Probe-rs has received PRs from both Knurling and Oxide devs; it provides the common interface to use various types of debug hardware and talk to various types of microcontroller cores, essentially replacing OpenOCD.
The github repo of hubris [0] is very nice, as they immediately tell you where what is, e.g.
drv/ contains drivers, a mix of simple driver lib crates and fully-fledged server bin crates. Current convention is that drv/SYSTEM-DEVICE is the driver for DEVICE on SYSTEM (where SYSTEM is usually an SoC name), whereas drv/SYSTEM-DEVICE-server is the server bin crate.
Why does nobody do this in their readmes normally? They just let you look into their code and tell you "now figure it all out yourself".
I've never understood why github shows the first line of the most recent commit for files / folders next to their name instead of the first line of any README.md file inside the folder.
Even on projects that I'm actively working on, the most recent commit of a folder gives me no useful information, whereas if I could edit the README.md I could atleast add a description of each folder so that new users could understand the directory structure better.
> Why does nobody do this in their readmes normally? They just let you look into their code and tell you "now figure it all out yourself".
I think it's worth praising this repo without knocking others. Open source authors have no obligation to their users; if they don't have the time to, or just don't care to, so organise their READMEs, then they need not. In fact, if it's sufficiently important, for much open-source software anyone else can do it, and submit a patch.
Can anyone clue me in on the status of async/await in hubris? I have some HAL code that both really needs and uses async (or callbacks) to work and currently just use my own homebrew WFE/WFI wakers (with a fixed, known a priori number of tasks) but it would be nice to switch to something more elegant and less brittle.
(Context: async/await-based per-task loop to facilitate background LoRa send/receive while other tasks can continue to operate (DMA, SPI, etc) independently, with the overall loop shutting the primary Cortex core down when processing is completed/while waiting for events/updates.)
The last I checked, hubris was strictly synchronous and I didn't get the sense that the interaction between tasks was architectured in such a way that would facilitate low-power designs for battery-powered devices.
(Basically, this probably hasn't changed since you looked at it, but for anyone else who hasn't seen it yet...)
> shutting the primary Cortex core down
We don't have mainline support for multicore systems, and there's a big ? in there, design-wise. So yes, you are right to recognize that that is the current state of things.
I love projects like this. I've considered getting a smartwatch. Something like this makes the idea more appealing. Whats the most hackable watch? Is there a pinephone of smartwatches?
It's not the most hackable, but there are some dedicated folks hacking at the Amazfit watches. I have the original Bip, which has a ridiculous battery life (30+ days easily) and GPS. The GPS will run your battery down with extensive use, but if I'm running a few times a week it'll still go 2 weeks.
It isn't that powerful, and I wish it had a second physical button. I haven't explored the mods very much because it does what I need it to do, but the scene has the feel of the early Xbox hacking scene, to me at least.
> Compare these two videos of writing a solid block of color to the screen, first through the SPI task, and second with direct SPI hardware access:
I wonder if the performance difference could, in some applications, create a preference for processors with enough SPI ports to dedicate one per peripheral (no chip select required). Not only no shared bus (as in I2C), but no shared SPI-task.
Larger chips (like SoC/Application Processors) certainly have multiple such buses for bandwidth & separation-of-concerns (ie security-related stuff like bootrom vs touchscreen controller) reasons, but I think we're far, far away from accepting the cost of extra pins just to accomodate software concerns.
Can anyone provide a comparison of PineTime and Pebble? My Time Steel is aging and I'm trying to figure out if the PineTime would be a workable replacement.
The pinetime can basically do anything you want it to, as long as you're willing to make it so. I'm wearing it on my wrist right now, but I have an iPhone and the support for it is not great. In terms of build quality, it's quite good, and the battery lasts for about a week. It's slimmer than an apple watch, which is a major plus for me. But if you have an iphone, step tracking and limited music control is all you'll get in terms of accessory use. You can always contribute, however, and there is a very active community working on the firmware in the github repo (https://github.com/InfiniTimeOrg/InfiniTime).
The thing that the PineTime does really well, however, is beat the price tag of basically every other smartwatch out there ($30). I'm not sure how chip-shortage prices might be affecting this though...
[+] [-] zozbot234|4 years ago|reply
Ultimately, the embedded space (including all sorts of low-level, retro, "bare-metal", remote etc. programming) has common needs and it would be convenient to see more widespread cooperation among these projects, improving reliability and avoiding wasteful duplication of work. More resources at https://github.com/rust-embedded/awesome-embedded-rust
[+] [-] panick21_|4 years ago|reply
This twitter space goes into a lot of detail: https://www.youtube.com/watch?v=cypmufnPfLw
But at the end of the day, no_std will allow a bigger ecosystem and sharing between many of these projects.
[+] [-] randomskk|4 years ago|reply
[+] [-] protoman3000|4 years ago|reply
[0] https://github.com/faithanalog/hubris/tree/pinetime
[+] [-] hemogloben|4 years ago|reply
Even on projects that I'm actively working on, the most recent commit of a folder gives me no useful information, whereas if I could edit the README.md I could atleast add a description of each folder so that new users could understand the directory structure better.
[+] [-] steveklabnik|4 years ago|reply
We have a custom build system on top of Cargo, and so things are a bit weird for a normal Rust project, and so it's extra important.
[+] [-] Jerrrry|4 years ago|reply
[deleted]
[+] [-] JadeNB|4 years ago|reply
I think it's worth praising this repo without knocking others. Open source authors have no obligation to their users; if they don't have the time to, or just don't care to, so organise their READMEs, then they need not. In fact, if it's sufficiently important, for much open-source software anyone else can do it, and submit a patch.
[+] [-] mkesper|4 years ago|reply
[+] [-] ComputerGuru|4 years ago|reply
(Context: async/await-based per-task loop to facilitate background LoRa send/receive while other tasks can continue to operate (DMA, SPI, etc) independently, with the overall loop shutting the primary Cortex core down when processing is completed/while waiting for events/updates.)
The last I checked, hubris was strictly synchronous and I didn't get the sense that the interaction between tasks was architectured in such a way that would facilitate low-power designs for battery-powered devices.
[+] [-] steveklabnik|4 years ago|reply
For more: https://hubris.oxide.computer/reference/#_why_synchronous
(Basically, this probably hasn't changed since you looked at it, but for anyone else who hasn't seen it yet...)
> shutting the primary Cortex core down
We don't have mainline support for multicore systems, and there's a big ? in there, design-wise. So yes, you are right to recognize that that is the current state of things.
[+] [-] iudqnolq|4 years ago|reply
[+] [-] f0e4c2f7|4 years ago|reply
[+] [-] bitdivision|4 years ago|reply
https://www.pine64.org/pinetime/
[+] [-] nickspacek|4 years ago|reply
It isn't that powerful, and I wish it had a second physical button. I haven't explored the mods very much because it does what I need it to do, but the scene has the feel of the early Xbox hacking scene, to me at least.
There's this watch which appears to be heavily inspired from the Amazfit Bip: https://www.kickstarter.com/projects/gfw/banglejs-2-the-open...
[+] [-] nsb1|4 years ago|reply
[+] [-] ushakov|4 years ago|reply
[+] [-] a9h74j|4 years ago|reply
I wonder if the performance difference could, in some applications, create a preference for processors with enough SPI ports to dedicate one per peripheral (no chip select required). Not only no shared bus (as in I2C), but no shared SPI-task.
[+] [-] AceJohnny2|4 years ago|reply
[+] [-] smbv|4 years ago|reply
[+] [-] qualudeheart|4 years ago|reply
[+] [-] RantyDave|4 years ago|reply
[+] [-] gnicholas|4 years ago|reply
[+] [-] wanderer_|4 years ago|reply
The thing that the PineTime does really well, however, is beat the price tag of basically every other smartwatch out there ($30). I'm not sure how chip-shortage prices might be affecting this though...
[+] [-] visy|4 years ago|reply
[+] [-] dcow|4 years ago|reply
[+] [-] wlkjlkeleg|4 years ago|reply
[deleted]