I discovered the same thing with u8g2, and digging through the abstraction layers it felt like improving it was going to be impossible. Sending a single transaction with a framebuffer is so much simpler and faster.
SSD1322 looks great and might be something I look at for the future..
Interesting! That could be good way to boost the speeds here for sure, as I'm still pushing out a full framebuffer out with every update and am not usually updating the whole screen.
(author here) I've been pondering this, yeah. I'm currently sharing the I2C bus with a DAC and that's working alright, but the refresh rate issue is enough to make me consider SPI. I know the SPI peripheral supports DMA as well, and the I2C one doesn't (sort of? I know there's "async" transmit now but can't tell if that's really doing DMA)
The I2C peripheral is DMA - a write just queues an operation descriptor in a hardware FIFO, and interrupts fire whenever something exciting happens or the FIFO is drained. The synchronous implementation is just blocking on a condition set by the interrupt handler.
But this is exactly the kind of thing the SPI peripheral is meant for. This cannot be said for the I2C peripheral, with its measly fast mode support.
Depending on the chip and your usecase, you might also want to use I2S for your DAC.
I find this so confusing - I’m working on a fairly large project using ESP-IDF and find it an absolute joy to use. Far better than any other microcontroller framework.
That's the main problem with it - it's a framework.
I don't want a framework that takes over an entire project and mandates the use of a given build system, configuration system, source code structure, etc. This tends to break apart when you want to have more complex build steps; eg. matrix builds, subsequent build actions on artifacts, integration with codegen like string interning, multiple target platforms which are likely not an ESP32 (like a simulation target running on the host), integration with linters/checkers, integration with test frameworks, etc.
And the technology choices ESP-IDF made are also... controversial (CMake and Kconfig! Plus a whole bunch of Python glue to actually make it work together).
Just give me libraries that I can build/link against and let me bring my own build system - or pick a build system that is actually extensible and will scale to more complex scenarios.
> Abusive and spammy behavior. When abuse or manipulation of our service is
reported or detected, we may take action to limit the reach of a person's Tweets. Learn more about actions we take, including temporary and permanent account
suspensions, and limiting account functionality.
By all means, everyone, feel free to be pendatic about the language here, and deferring to their weasels words, in the direct light of the documentation that has been released, because you agree with the editorial direction. It has been SPECIFICALLY revealed that they frobbed the knobs when they didn’t like what was being posted, while admitting that their own policies weren’t being triggered, and they had no justification.
> It has been SPECIFICALLY revealed that they frobbed the knobs when they didn’t like what was being posted, while admitting that their own policies weren’t being triggered
Where was this revealed? I saw Bari Weiss claim it happened but the screenshot she posted as evidence specifically says the account violated their policies.
I guess you're reading this and saying that "indirect" violations are the same thing as direct, i.e., defined, violations? Is that what's happening? People downvoting me are being absolute pedants about the definition of "shadow banning," and then just give this part a pass and say it's fine?
I guess this is the world we live in now, in every respect. There's so much STUFF going on, and so much written about the stuff, that people can choose to focus on whichever half they want, and find plenty to support their position. But I still live in a world where the general IDEA is the main thing, and Twitter has been shown to do things outside of their stated policy. And, sure, as someone else pointed out, they're allowed to do whatever they want. But they didn't have to hedge and lie about it.
> Oh joy, another paper for the antivaxxers to misinterpret. Some red flags though.
> The tone of this paper, particularly the last sentence ("potentially harmful effects") seems suspect...almost as if they were intentionally riling up the anti-vax crowd.
> They appear to have misinterpreted the outcome of this study, claiming "higher risk of infection than unvaccinated individuals 9 months post-vaccination". The study makes no such claim that I can find. The tables in the supplement show the only subcohorts with a slightly higher incidence rate for vaccinated individuals at 9 months is age >80 (1.3 per 100,000 person days in vaxxed vs. 1.1 unvaxxed, supplemental table 5) and those requiring in-home care (1.6 vs. 1.5). Also notable is that the only vaccine that shows less effectiveness against infection is the non-MRNA vaccine (supplemental table 6) and that vaccinated individuals in all subcohorts were still substantially protected against hospitalization or death compared to unvaxxed.
> The primary source for the claim that mRNA-LNP is inflammatory is a paper authored by three of the four authors of this paper.
> Also notable is that at least one of the primary authors - the one credited with writing and editing - is a GBD-adjacent, anti-MRNA, HCQ truther (Don’t Look Up” Your Science—Herd Immunity or Herd Mentality? - "The virus fatality rate did not support lockdowns, blanket restrictive measures, and non-selective mass vaccinations. There was no solid scientific rationale to adopt the untested mRNA-LNP platform over other well-established vaccine formulations to fight COVID.").
> None of this means the science in the paper is wrong, but I'd be hesitant to take anything at face value.
Thank you for TenFourFox! As recently as last year I was still regression testing my code against TFF on a 12” PowerBook because it’s still my favourite hardware. If anyone ever used Bandcamp on a PPC Mac, they also have you to thank :)
This is cool.. I was trying to figure out how to get macOS next/prev controls to trigger events in Safari but haven't had any luck. This seems like a cool API for doing that sort of thing (though, sadly, no Safari support)
Yeah, it's pretty cool. I discovered it after noticing that Youtube playlist in Firefox started reacting on the player controls in KDE notification area.
SSD1322 looks great and might be something I look at for the future..