Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oxide on My Wrist: Hubris on PineTime was the best worst idea

artemis.sh

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#41

Post by ComputerGuru »

steveklabnik wrote: post #40
ComputerGuru wrote: post #39

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 tas…

We don't use async in hubris, so there is no async/await. Hubris is 99.99999% synchronous. 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…

Hi Steve. Thanks for the confirmation - obviously a synchronous design doesn't automatically/necessarily preclude most high-level use cases that async can support - it just requires an alternative approach and some careful consideration. In fact, it could make it easier to do many things like power management.

Can you comment on this: others have asked here on HN before but didn't seem to get an answer - does power management/consumption factor in at all in the architectural design (even if it's "this makes it possible to add power management later") or is it strictly a non-goal? (I know your current particular application domains aren't constrained by battery capacity.)

It would be easy enough to hack the kernel to always WFI/WFE if all tasks are exited/completed, but I'm thinking about cases where task(s) are still running but the supervisor process is aware that they're all currently in a busy-waiting state. But that wouldn't be sufficient (on its own) if the OS requires certain peripherals to always remain powered up, uses a high-frequency tick interrupt that will constantly wake the device anyway, etc, etc.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#42

Post by wanderer_ »

gnicholas wrote: post #32

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...

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#43

Post by iudqnolq »

ComputerGuru wrote: post #39

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 tas…

For others, embassy.dev are the main people working on embedded async.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#45

Post by AceJohnny2 »

a9h74j wrote: post #37

> 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.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#46

Post by steveklabnik »

ComputerGuru wrote: post #41
steveklabnik wrote: post #40

Earlier quoted context omitted.

We don't use async in hubris, so there is no async/await. Hubris is 99.99999% synchronous. 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…

Hi Steve. Thanks for the confirmation - obviously a synchronous design doesn't automatically/necessarily preclude most high-level use cases that async can support - it just requires an alternative approach and some careful consideration. In fact, it could make it easier to do many things like power management. Can you comment on this: others have asked here on HN before but didn't seem to get an answer - does power m…

I don't know what our "official" take is, but given that a rack of servers is going to draw, you know, a lot of power, I do think that keeping it simple has been a bigger priority than trying to minimize draw here. It wouldn't have a macro effect on the product's power usage anyway.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#48

Post by nerdponx »

bluGill wrote: post #25
nerdponx wrote: post #22

Earlier quoted context omitted.

This isn't just about open source. Developers on internal projects should do this too, but don't.

Have you ever tried to write useful documentation? As a programmer you are far to close to the code. You assume things are obvious that are not, while going into great detail describing things that are obvious (or maybe not obvious, but only rarely interesting and so should be documented in a deeper link not the main documentation). Or worse because you have to document it you document the code lines (++i; // increme…

Of course I have. And of course I recognize that writing good docs is difficult.

I am not talking about the difficulty of writing high-quality explanatory prose. I'm talking about expanding what people consider standard practice, to include a bullet-point description of how the files in the project are laid out. You don't need to be a good writer in order to do this.

That said, just because something is hard doesn't mean it's not a skill that can be learned. Not everyone has the same attitude for writing (much like programming), but generally I believe that "most people can be taught most things to a basic level of competence", and I do not think documentation writing is exempt from that principle. There is no reason why the skill of writing halfway-decent documentation should not be taught in programming courses.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#49

Post by gnicholas »

wanderer_ wrote: post #42
gnicholas wrote: post #32

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…

Thanks, I am on iOS so this is helpful. All I really care about is notifications, step tracking, and music control. It would also be nice to look at my calendar and check the weather, but those are not critical.

Re: Oxide on My Wrist: Hubris on PineTime was the best worst idea

#50

Post by ComputerGuru »

steveklabnik wrote: post #46
ComputerGuru wrote: post #41

Earlier quoted context omitted.

Hi Steve. Thanks for the confirmation - obviously a synchronous design doesn't automatically/necessarily preclude most high-level use cases that async can support - it just requires an alternative approach and some careful consideration. In fact, it could make it easier to do many things like power management. Can you comment on this: others have asked here on HN before but didn't seem to get an answer - does power m…

I don't know what our "official" take is, but given that a rack of servers is going to draw, you know, a lot of power, I do think that keeping it simple has been a bigger priority than trying to minimize draw here. It wouldn't have a macro effect on the product's power usage anyway.

Thanks. That logic/reasoning is applicable to a lot of people/products and is totally understandable even if it’s a bit of a bummer. Cheers!
Post reply on HN