Fabulous, I could not be able to find such a great stuff. Explained well...

Fabulous demo/lecture, i kinda ran into this episode and did not even know this was a series. I'll be sure to start from the beginning though as I found it very much instructive & informative! Thanks & cheers!👋🙌

Excellent tutos! Thanks for share.

fun fact for anyone using Windows and the stm32f401 boards featured in this video. If you kept the integrated st-link debugger attached to the board, it seems to provide a virtual COM port for the UART interface that you can connect to. This means you can connect to the UART without any extra UART-to-USB adapters over a program like PuTTY and things seem to just work (at least they did for me!). I'm not sure if some analogous "it just works" serial interface is available for linux.

@LowByteProductions

Жыл бұрын

You're absolutely right. The UART virtual com port is handled by the ST-Link directly (using the on-board stm32 chip). This is the reason the solder bridges are needed when you break off the st link.

@harinayan7879

22 күн бұрын

Does this mean I have to make no additional changes to the code and simply attach the micro USB to enable communication?

@harinayan7879

22 күн бұрын

It works on Linux as well! I tried it with a smt32F411 Nucleo and it's integrated ST-Link.

For a simple peripheral like usart, it could have been fun to get even more bare metal, and deal directly with registers and explore the reference manual on the topic. Anyway, just discovered your channel and can't stop watchin'!

@LowByteProductions

Жыл бұрын

Totally - I might do something like that at some stage!

@kayakMike1000

9 ай бұрын

​@@LowByteProductionsit would be even cooler if the driver loaded these registers from a compiled device tree!

Genius

excellent tutors! could you share your vscode experience for another video?

in the uart_usr, shouldn't the if statement check for !overrun ?

after debugging a few hours, i figure out my board only works on usart1 (pa9, pa10)

May i ask what theme you use for VSCode?

@LowByteProductions

Жыл бұрын

Dracula

@Host On the name of 'drivers', I was watching a learning series of on SQL and the use with APIs. They said that the APIs can basically be viewd as 'drivers'. So my question is 'Can this sort of inside 'driver' be like an internal API or is there is significant difference??' Thank you :)

@LowByteProductions

Жыл бұрын

I'm no expert in database systems, but I'll try to speak to what I understand the term to mean in both contexts. Usually a (device) driver refers to a very low-level piece of code, which typically talks directly to some hardware I/O interface, and exposes a higher level interface to be used in a more practical way. Often, that interface is generic, in that any specific details of the hardware are abstracted away. In the embedded world, a driver is most often like what I've presented here. In an OS, a driver is a program that runs in the kernel, also often connecting to hardware, and exposes a generic interface for use in userspace programs (normally the interface is exposed as a "file", which has an implementation for a bunch of common operations like open, read, write, close, etc). In both, the job of the driver is to translate generic commands (e.g. uart_read(), uart_write()) into hardware specific operations on the device. In a database, a driver is able to convert generic SQL to the inner workings of the DB engine (I believe it handles even more than that - connections etc). So in that sense, it's doing precisely the same as a low level hardware driver, except instead of abstracting a hardware interface, it's abstracting a software interface. A device driver is, at least in my humble opinion, also an API. I hope that answers your question in some capacity!

@cleightthejw2202

Жыл бұрын

​@@LowByteProductions Hello to you and Thank you for the replay/answer. Yes you did answer my question. I do find these things very interesting though I don't know a lot about it (at least yet) I definitely do like the 'low level' stuff where thing are actually running the show. Which is the kind of thing your vids are about.

Wonderful content! Please explain the purpose of using the const keyword for the variables overrun_occured and received_data in the isr

@LowByteProductions

3 ай бұрын

It tells the compiler we have no intention of changing this variable, and that it is free to optimise the code however it would like

@nitpal9958

3 ай бұрын

@@LowByteProductions I see what you mean. Thank you!

Putty and screen show no output My code compiles and runs the LED blinks as expected. But when i use putty, it says that unable to connect to the /dev/ttyUSB0 and then closes. when i use screen without sudo, it says screen is terminating. When i use screen with cudo, it simply opens the terminal and i get no response from the device. The USB adapter is connected and is being detected by the "dmesg | grep tty* ". The same problem persists even on windows, where the terminal is open on putty, but when i type something, no data gets displayed. I am using a f4 discovery board and have made all the necessary changes in the code, makefile and the linkerscript. did anyone else face the same issue? edit: found a work around for now: After some testing i figured out that the issue is with my USB to UART converter. I am using a CH340 module as shown in the video and it is being recognized by both Linux and Windows as ttyUSB0 or COM3, but when i try to access it using either putty or screen, i get no data. However, i have a F411 nucleo board lying around and it's integrated st-link works directly without any external module. I am able to send and receive data as expected. I tried the CH340 with both F411 Nucleo and F407 discovery, and in both cases, it deoesn't work. Later, I will use an oscilloscope to look into the TX and RX lines of the Discovery board and the CH340 module and try to findout if the module is broken. I think it might be a driver issue but i am not yet sure. But for now, the Integrated St-link of the F411 Nucleo works wothout any external module needed on Linux. If someone finds a solution to the problem, then please let me know.

i love you

If you can please add also some can bus programming. Thanks

@LowByteProductions

6 ай бұрын

I'd love to - I actually work with CAN every day in my job - but I don't really have any devices to talk to. I have a SPI based transceiver module, so if you have any ideas, let me know!

@Yaban-racing

6 ай бұрын

Not really but this is not going to help in my personal case as I use automotive grade freescale mcu 5v that have can capabilities already built in. Your videos helped me a lot monitor wise to understand lots of parts that was unclear for me even on different brand. With the mcu I'm using the only framework I have is a serial bootloader developed by freescale (Motorola) guys in assembly. It was built so that you can call the function to handle Sci with the bootloader functions. I write actually a firmware downloader that use this bootloader to flash my code. When this is done I will start to code main application. The goal is interface with tunerstudio for live tuning and can communicate through can with a megasquirt. I don't know if you know megasquirt. Use a can transiver module that communicate with a mcu using a library is not really what I'm looking for but for sure it can be interesting for a coding lesson and certainly for software side how to handle incoming data and how to recognise and handle them. You look familiar with St mcu do you have any advice on a st mcu 5v automotive grade with direct can fonction ? Your advice are welcome as look like it's easier to find documentation and library for St mcu that freescale. Regards

@LowByteProductions

6 ай бұрын

Ah ok got it. I work with the STM32L4 family at work, which has a CAN peripheral. The module is basically a combination of the microchip MCP2515 plus a line driver chip. You can think of the MCP2515 as an external peripheral - it has all of the configuration registers for fifos, filters, etc which you need to setup properly, only instead of doing that over the CPUs memory mapped interface, you do it over a simple SPI bus protocol. So it's not a world away from how you'd interact with a chip that had native CAN functionality.

No unit tests?