> We and our 721 advertising partners store and/or access information on your device and also process personal data, like unique identifiers, browsing activity, and other standard information sent by your device including your IP address.
And then there is no Decline or Settings button, but only "Learn More".
I do not consider myself particularly sensitive about such stuff, but this one was too bold!
I don't get it. You write a blog, likely for the joy of writing & showcasing your projects. Maybe as a vehicle to sell consulting services, books, or to spice up a resume. Hosting something with some text and pictures costs you pennies. People want to get in touch with you for some reason? Great. There's an email address at the bottom of the page.
Nowhere does this need bullshit analytics, ads, or worst of all selling visitor data to 721 adtech parties. Yet here we are...
I think there are different types of writers, not all have the same motivation.
The one you talk about does it for the joy of writing or showcasing their projects.
But there is another where writing is a part of it, but getting views and feeling heard is another part, where numbers going up on a dashboard gives them dopamine.
They need analytics as that's the way they verify that someone is actually paying attention. Without it, they would never know if someone is reading it or not, and that's a part of their motivation.
Yet another group just want to know which of their post is more popular than another, they maybe don't really care about the specific numbers but more the ratio between posts, so they can keep writing what people seem to be reading the most.
Regardless, none of that actually need intrusive client-side analytics and tracking, it all can be done server-side but seems we've collectively forgotten how to do this.
> Regardless, none of that actually need intrusive client-side analytics and tracking, it all can be done server-side but seems we've collectively forgotten how to do this.
Hear, hear. Heaven forbid someone in need of some dopamine greps their server logs, or increments some counter in a db...
The blog is hosted on wordpress.com. Author likely has little control over this, and all the adtech garbage 'comes along for the ride', and the author is indifferent to it, and/or considers it the price of blog hosting.
There is a "Disagree to all" button if you click "Learn More", but you only really find out about that after reading the entire popup. Quite hostile overall, yet I find the emphasis on the exact number of 721 advertising partners amusing.
Sorry, I'm not aware of this issue. I submitted the link but I'm not the author of the blog. I work in embedded systems and I've been using reading Erich's blog for years. Semihosting is one of those less well known topics I thought I'd share. Is there a problem with the blog? I'm in the US and use Brave browser. I didn't notice a privacy issue.
For folks not into embedded development, semihosting is sort of like remote debugging.
The application runs on the microcontroller, and the output is displayed in your IDE/terminal. Depending on the capabilities of the microcontroller and its development environment, value interpolation might not be fully operational, and step by step debugging can go from fully supported to barely able to support breakpoints.
Semihosting is afaik an ARM specific term. The advantage over UART & JTAG is performance I think, printing text is usually blocking & slow, while semihosting is using a ring-buffer I think?
The advantage is ease of use, semihosting is rather slow and has a big impact on system behaviour, as it uses a breakpoint and r0 to transfer a datapoint. It is definitely slower than SWO or RTT, which transfers data over SWD.
You can find a detailed description here https://interrupt.memfault.com/blog/arm-semihosting
That’s what I guessed from the article, especially when I read that it only works with breakpoints but in this case is there a reason to not call this "debug mode" ? Because it sounds confusing.
Or maybe there are other usages than just debugging ?
"Semihosting" is a very old term for this ABI (it dates back to at least the late 1990s in a bit of Arm documentation I found, and might well be earlier). It's mostly I think a name coined when looking at it from the point of view of "what is the C library this guest program linked with using to do stuff":
* hosted == we're running on a real OS, and printf etc become system calls to that OS
* freestanding == this is a bare metal program (perhaps it is itself an OS kernel) and much of the C library facilities are simply unavailable
* semihosted == an in-between position, similar to freestanding but with printf and some other facilities talking over a debug protocol to a connected development system, so you get more of the conveniences of a hosted C library during the development process
(the first two are C standard terminology.)
The use of the bkpt insn is also fairly new, being specific to M-profile (which is the device the blog post author happens to be using). The original 32-bit Arm version uses SVC (the system call instruction). Either way, use of the instruction is caught (by a debug ROM on the guest, or by a JTAG debugger, or by an emulator/software model) to perform the necessary operations, in a flow that is separate from use of bkpt as a true breakpoint).
More recently some other architectures have borrowed the "semihosting" term to refer to the equivalent ABI they provide.
It is basically a debugging feature: giving you printf support through the JTAG connection instead of needing a dedicated UART or something like that. You can also do some stuff like read/write files on the host as well, but again this is basically only useful for debugging.
After using Segger's RTT and SWO and stuff, nothing beats a plain old high speed UART pin for "basic" debugging. You can start up the UART, send your message and if there is inactivity after X milliseconds close the UART and the power consumption is back to microamps. It works with any micro and usb-serial chip so no lock-in with ARM or Segger related tools.
However for some tasks such as proper debugging, stepping, or inspecting interrupt vectors while printing messages fast, native tools are the way to go.
RTT can be used without SEGGER tools, I've used it with cargo embed and deferred formatting, so the logging has minimal impact on the overall system.
Properly using UART with DMA is very close to the RTT experience though
And then there is no Decline or Settings button, but only "Learn More". I do not consider myself particularly sensitive about such stuff, but this one was too bold!