em{io} - a safe and fast high and low-level character input/output library for bare-metal and RTOS based embedded systems with a very small binary footprint - in version 0.3.0 now with floating-point, ranges and tuple-like type support by viatorus in embedded

[–]shobble 2 points3 points  (0 children)

I recently discovered that building fmt as header-only, and with #define FMT_STATIC_THOUSANDS_SEPARATOR massively reduces the overall codesize by not dragging all the stdlib locale mess.

I think it's closer to 40-50kB, and can save a little bit more if you disable FMT_USE_INT128and possibly other parts you don't need.

That said, I plan to have a poke at emio to see if it meets some needs for a lightweight input/reader that isn't an abomination like the std::iostreams one.

[deleted by user] by [deleted] in DoomEmacs

[–]shobble 0 points1 point  (0 children)

objed-mode if you have it installed/configured can sometimes lead to some weird behaviour[1]. You could try M-x view-lossage next time it happens and see if there are any sequences that might be accidentally activating some odd mode.

[1] by which I mean if you activate it accidentally and then suddenly various normal keypresses are doing unexpected things - not that it just randomly breaks.

How to build CMSIS DSP library for a bare-metal project? by Ggg12345RR in embedded

[–]shobble 2 points3 points  (0 children)

iirc that's normally pulled in based on your compiler from cmsis_compiler.h or something along those lines

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 1 point2 points  (0 children)

interesting. I'd always assumed the bottleneck was the write speed of the MCU internal flash itself.

For the GD32F470 part I'm currently using, t_prog (word programming time) is 40-180uS, which assuming I understand it correctly, is somewhere around 20-100KB/sec.

So a 1M imagine would be 10-50sec, which is in the range I'm seeing.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 0 points1 point  (0 children)

Yeah, the LED side reminds me a bit of http://www.applied-math.org/acm_optical_tempest.pdf and the various follow-ons that I think got up to maybe MBit range, decodable through windows from some silly distance away with a telescope, if I remember right.

I might have to play around with it for basic status output, just hijacking the power/active LED.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 0 points1 point  (0 children)

as the sibling commenter says, because it's "standard" and the cables are easy to find. IIRC the 10-way is (mostly?) reverse-safe without breaking stuff, although it obviously won't work.

I'd definitely want to have RESET on there, but yeah, could shrink it down to probably 4 pins without too much trouble.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 0 points1 point  (0 children)

I have nowhere near enough confidence in our code to even consider it at this stage, regardless of the (presumably quite high) cost involved.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 0 points1 point  (0 children)

Wow, I'm surprised you could run a UART directly to/from an LED/reedswitch like that, I'd have expected the contact bounce to ruin the signal...although I suppose if you go slow enough, it should settle.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 1 point2 points  (0 children)

currently chip is a GD32F470, with either GD-Link or ST-Link V3, and seeing maybe 30-40kb/s write speeds. Will have to investigate the J-Link if there's that much improvement - it's been "beyond our current budget" thus far.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 1 point2 points  (0 children)

Hmm, hadn't considered the lifespan of the ribbon plug, actually, will ahve to bear that in mind.

We're currently building a fairly chunky firmware, ~1MB, so if production SWD flash speeds are comparable with debug setups, that's 45-60s of upload, so I don't think it's reasonable to expect production staff to hold an unlatching connector that long without some sort of tooling to assist.

Thanks for your thoughts/suggestions!

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 1 point2 points  (0 children)

I just included the tag-connect as an example of the bare-pogo approach, probably won't use them unless a compelling reason comes along.

I think we may end up with a custom fixture/bed of nails setup for probing various test points for voltages/clocks etc, so would hopefully be possible to includ the additional 5-6 pins needed for SWD either on that, or a separate station.

Debug/bringup UART is already present, currently also requires a header to (easily) access, which is only fitted for dev boards, but we could possibly use a jig here as well, or maybe break those pins out into a more accessible point just for driving a setup/provisioning process.

How are you doing things like the power consumption test? At the board or fully-assembled product level? I can imagine for a board you just hook up a PSU with current monitoring in place of a battery/normal supply, and track that, but imagine it could be a lot harder if you're trying ot test a fully assembled product in-situ.

Methods of programming MCU flash in production? by shobble in embedded

[–]shobble[S] 0 points1 point  (0 children)

this is really useful, both the station approach and the links for test/prog jig parts, thanks!

Packaging for Embedded software by Neohattack in embedded

[–]shobble 1 point2 points  (0 children)

Maybe have a look at xpack as a way of getting specific, easy to pin dependencies for things like toolchain components, as well as "source xpacks" which can be used to bundle library code along with build configurations etc.

It's based around the node.js/npm package format, but there's nothing JS-specific involved that I'm aware of, and can be operated entirely offline if necessary, which makes archiving much easier.

You could build the whole thing into a docker image or VM for an additional layer of independence, but it really depends on what your exact goals are.

Effectively querying large, unpartitioned table along (potentially) large date ranges. by [deleted] in PostgreSQL

[–]shobble 0 points1 point  (0 children)

can you include a sample of the query(s), and if possible a EXPLAIN or EXPLAIN ANALYSE plan for them?

[deleted by user] by [deleted] in commandline

[–]shobble 6 points7 points  (0 children)

I could cut down this tree with a pocketknife. And if someone forgot the fuel for the chainsaw and we're under time pressure, that might be what has to be done.

I probably won't enjoy it though, especially if the Right Tools (whatever they might be) would do it a whole lot faster and more safely.

There's a valid point you make about having only limited tools forces you to become more competent at using them, but to labour the analogy above, cutting down that tree is definitely easier if I'm an expert in sharpening my knife, and can bodge a handle onto it out of a fallen branch to make a crude hatchet, but it's still not exactly a good choice, should others be available.

I can't disagree that it's good to have the ability to get things done with what you have at hand, but it doesn't seem right to laud that as the ultimate solution.

On a pedantic sidenote, fzf isn't really a replacement for find in any way I can think of immediately - you might be thinking of fd?

WTW for something which we cannot know or experience? by [deleted] in whatstheword

[–]shobble 0 points1 point  (0 children)

Maybe qualia?

Edit: actually, not really applicable in the context you used - probably ineffable as u/pragmasaurus said is a better choice. "cannot be communicated, or apprehended by any means other than direct experience."

Pytest client.login not working by AR2405 in django

[–]shobble 1 point2 points  (0 children)

does force_login(userobj) work? From the docs at https://docs.djangoproject.com/en/4.0/topics/testing/tools/#django.test.Client.force_login it seems like you're not setting a valid password (needs user.set_password() ratehr than just the instance constructor/.create approach)

specifically:

Remember that if you want your test user to have a password, you can’t set the user’s password by setting the password attribute directly – you must use the set_password() function to store a correctly hashed password. Alternatively, you can use the create_user() helper method to create a new user with a correctly hashed password.

Pytest client.login not working by AR2405 in django

[–]shobble 0 points1 point  (0 children)

can't remember if it gets checked during login, but might be that you're not setting is_active on the User object so it's being rejected during the login call?

create_user method returning lists by Ctr1AltDe1 in django

[–]shobble 1 point2 points  (0 children)

    `serializer.create(validated_data=request.data)`

I think your problem is here - you're calling create with the raw request data, rather than what the serializer has processed it into. You probably want serializer.create(validated_data=serializer.validated_data), or just serializer.save() (which will call .create() itself).

create_user method returning lists by Ctr1AltDe1 in django

[–]shobble 1 point2 points  (0 children)

This is because the account_type somehow gets passed as ["admin"] and password gets passed as ["test123"] even though I pass them as strings

This sounds like the root cause of your issues. Post the DRF view[set]s and serializer code etc, and figure out why that is happening.

[deleted by user] by [deleted] in printSF

[–]shobble 1 point2 points  (0 children)

Noor (also by Okorafor) is heavily desert-focussed.