I'm not really understanding all this antagonism towards the STM32F103
and its clones. Yes, it's an old chip and ST's current offerings are
more advanced. FWIW, I'm currently working on a heterogeneous design
which uses a STM32F767 master connected to many STM32L031 slaves. Much
more powerful/efficient chips, and much nicer to write code for.
If it's a moral objection to misappropriation of ST's IP, or the Chinese
dumping products below cost onto the international market, I agree in
principle. But ST is a huge, wealthy multinational corporation and can
defend its patents it so chooses. As to the macroeconomic issue, I have
zero ability to influence things on that scale.
The fact remains that the "Blue Pill" boards, clones or no, are widely
available for very little cost and are quite capable systems when viewed
on their own. The Chinese vendors are slowly making STM32F401/407/411
boards available, but they're more expensive, less standardized, and the
price/performance ratio isn't that different. ST's own Nucleo and
Discovery evaluation platforms are better yet (I'm using one to
prototype the F767 design) but once you get into their price range the
alternatives at the same cost -- a more capable logic analyzer using a
Cypress FX2 plus FTDI/CP20x USB-to-serial and similar SPI/I2C converters
-- start to be a better choice. I'm aware of the Greaseweazle fake
identification photos and tests. If anything, "buck50" exercises more of
the chip's peripherals so anything that's broken will show up. Dirt
cheap hardware plus free open-source software equals "caveat emptor". I
wrote "buck50" partly as an exercise in what could be done with limited
hardware. Because it uses my efficient and (I claim) easy to use
"regbits", "regbits_stm", and "papoon_usb" code instead of ST's bloated
HAL/LL/Cube libraries, the entire binary is approximately 20KB, so 64 vs
128KB of flash isn't an issue. (Having more than 20KB of RAM for sample
storage would be nice, but again pushes up into the more expensive
chips.) BTW, the most recent batch of "Blue Pills" I received *are* 128KB.
Back to sigrok PulseView: @Uwe Bonnes, any thoughts you could share
regarding sparse time-sampled data and memory consumption in PV? Should
I dive in and see if I can do anything to improve the situation? (Very
busy right now, but I can put it on my infinitely deep stack of future
projects.)
--
MARK
markrubn@...
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
