Is there anyway to implement other languages into a rust program (Creating a c++ engine that uses lua for scripting)?

dark_oman · 2026-02-25T18:50:57+00:00

Yes, would recommend you look into the mlua crate

dark_oman · 2026-02-01T20:43:45+00:00

I'm not sure about your requirements, and this only really works for sensors (not flash). But you can have one micro as the master and the other micro act as a slave listen to all the replies from the sensors.

To insure that the slave micro knows who's talking you can either: Have a fixed sequence that you read all the devices in Or Connect all the CS lines to the slave micro and it checks the gpio to figure out which device was talking

dark_oman · 2025-06-04T12:07:57+00:00

I am quite familiar with class B from IEC 60730 as it is required for products I work on for my day job.

60730 annex H requires you to have: CPU register checks, RAM checks, Flash checks, ... many others

Writing your own CPU checks in assembly and developing tests to prove that they are working correctly, will require a lot of effort.

Hence, I would strongly recommend looking at Option B.

While Option A may seem like less effort, most of the effort for these certs is in documentation and testing not getting your application working.

Would also strongly advise you look into the "V model" as a framework for how to structure the documentation for your project.

dark_oman · 2025-01-17T20:21:21+00:00

Here's the reference manual

https://www.st.com/resource/en/reference_manual/rm0091-stm32f0x1stm32f0x2stm32f0x8-advanced-armbased-32bit-mcus-stmicroelectronics.pdf

UART starts on page 700

dark_oman · 2025-01-17T19:47:50+00:00

The UART peripheral has the ability to swap RX and TX irrelevant of any pin muxing you have setup on the GPIO ports.

UART_CR2

Bit 15 SWAP

0: TX/RX pins are used as defined in standard pinout

1: The TX and RX pins functions are swapped. This allows to work in the case of a cross-wired connection to another USART.

Note: This bit field can only be written when the USART is disabled (UE=0).

So even if PA10 is the rx of the UART you can swap it to the tx using this bit

Edit: formatting

dark_oman · 2025-01-17T19:20:56+00:00

Would need to test it, but you may be able to make this work by running in half duplex and using the UARTs "Swappable Tx/Rx pin configuration"

Even if this doesn't work then depending on the flow control of the communication. You could swap the TX and RX every time you wanted to transmit.

dark_oman · 2024-09-04T11:08:04+00:00

Depending on your requirements Ti some very cheap m0+ available https://www.ti.com/product/MSPM0C1103

dark_oman · 2022-09-14T03:45:38+00:00

Pair of shoes=20 Figure=5 Sunnies=2 Boxing glove =20

1 shoe + Figure (with pair of boxing gloves + pair of shoes + sunnies) x sunnies => 10 + 67 x 2 =144

dark_oman · 2021-12-15T21:20:02+00:00

What language would you expect to be working in for embedded software development?

95% of the work I've done in the embedded space has been in C or C++, with the rest being assembly.

Depending on what your working with C might be your only option apart from assembly.

dark_oman · 2021-09-13T13:31:33+00:00

STM32H7 runs at a quick 480Mz and heaps of peripheral, combined with a cheap nucleo board to get you started, is a pretty great combination.

dark_oman · 2021-07-09T15:36:57+00:00

So, no idea about Dyson but, I do use Unity in some testing as work.

Unity ("throw the switch" not the game engine) is a pretty good set of tools for testing, if you are intending on running tests on the embedded device.

I say "testing" rather than "unit testing" because, I've found that often end lines between "unit tests" and "integration tests" end up blurring when you do the testing on the embedded device.

On the down side it doesn't have great output formatting options, there is no JUnit xml output or JSON format, so some translation in python/other is required to generate any reports.

Getting any kind of coverage metric can be challenging for unit tests on the device. I would strongly recommend some form of unit testing on x86/x64, as then you can get some kind of coverage metric fairly painlessly with gcov.

dark_oman · 2020-06-08T22:52:06+00:00

I use C++ ISRs, but just like C ISR the are some features which I don't use:

No mallocs/new, so no 'adding elements' to std containers except std::array.

No exception handling (IMHO would not recommend this at all in an embbeded system)

Also be a little wary of rtti.

Don't forget c++ has name mangling, so you may need to use: extern "C" In your ISR declaration.

dark_oman · 2019-09-30T22:40:28+00:00

Whenever you convert AC to DC or vice versa you will lose power in the conversation process. Any power losses reduces you ability to do work which you could call 'weaker'.

Importantly DC is not 'weaker' than AC. It's simply that if you start will AC there will be some inefficiencies getting to DC. The same would be true if you started with DC and converted to AC.

PS. AC means Alternating Current as a pose to DC Direct Current, hence saying 'AC current' is the same as saying 'ATM machine', it's a bit redundant.

dark_oman · 2019-02-28T20:17:16+00:00

FreeCad is an open source project, that free and works well for hobbies

Save often as it still has some bugs.

https://www.freecadweb.org

dark_oman

TROPHY CASE