Answer the question
In order to leave comments, you need to log in
Who knows the literature on professional programming of microcontrollers?
I have been working with microcontrollers for a long time. I started with arduino, then on bare avr and stm32. In stm32f103, he already dealt with almost all peripherals, except that he did not touch usb and flash. Solving large problems very often I do not know how best to approach problems. After that, I do everything on crutches and, if necessary, expanding the functionality, I have to redo everything. There is always a desire to make the code (libraries or modules) universal, so that later it can be easily transferred to another project or platform, but, again, there are not always ideas how to do this. Maybe someone knows the literature on application design approaches for MK or something like that. It’s just hard to believe that everything is always sawed from scratch and head-on (because, as for me, modern MKs have enough resources to twist the universal code in most tasks).
UPD
I can describe the current problem. There is a task to organize communication through RS485 (half-duplex). There is one master in the network that makes requests to the slaves. After the request, the slave with the corresponding ID parses the request, generates a response and responds to its master. In terms of setting up the periphery, I did everything and debugged it. Designed as Libu. But there is one caveat. Request handler and response generator. For each device, this should be something different. How to arrange it beautifully? What would not break the code of an existing one? I would just like to see an example of solving such a problem from the mikruh programming FOLDER. I may be wrong, but it seems to me that this is an application architecture problem. In addition to such problems, sometimes I encounter such a problem that I don’t know what is better to use:
Answer the question
In order to leave comments, you need to log in
Known update. Breaks the question into two problems not related to uC. In general, uC programming is just normal programming with additional restrictions on memory, heap, stack, and performance. Well, yes, kakbe something special due to the fact that you need to know at least a little microelectronics. But really, nothing special. Of course, it doesn't hurt to know what your code turns into.
Books on architecture - any. At least damn design patterns: D
About interrupts vs poll - it's up to you to figure out the requirements - you have soft rt or hard rt. Maybe, according to your requirements, it will not be possible to make magnifiers at all and you need to work linearly with a reset at the end. And of course, look at FreeRTOS - at least how many chips it supports :D
It's
hard to read abstract books - read the u-boot/netbsd/linux code - see how it's done. In relation to your problem with the 485 bus, there is a lot of probing and detection of any periphery. The closest analogue will naturally be USB. The simplest stacks for USB are in nature to look at. You can copy the stack API so that it looks like.
My God: 17 hours have passed, 16 people. subscribed to the question, and no answer.
My heart is bursting with compassion.
Take .
On the main topic of the question: I myself suffer, but I suffer only because I "can't" program. The fact that you need to think over the architecture from the very beginning is in some cases highly recommended. We are developing several devices - we have to write shared libraries. We have to write sufficiently flexible libraries - otherwise we have to rewrite!
As practice has shown, very often there are pointers to functions, machine state, operating systems (freertos, chibios, etc.), etc. An excellent approach (IMHO) would be writing low-level (HAL from stm32) and high-level functions (modbus, canopen, etc.). See how they do these things.
Regarding the implementation of communication over pc485: if the protocol is different from modbus, but similar, look at the freemodbus library.
Now we are quietly trying to implement tests. There is an excellent book in English (I have not seen translations): we.easyelectronics.ru/Nemo/tdd-dlya-embedded.html - there is also a link to this book.
Than it is good to write "under tests"? The fact that you have to write each function thinking, but no matter how you write it. In short, we see the advantages in this!
Good luck!
Good afternoon!
Do you write master and slave code? Then organize an exchange between them using the Modbus protocol - specially created for such systems and widely used in SCADA. It assumes a register organization of the data in the sensor.
I can also recommend an easy introductory course to RTOS schedulers:
https://www.coursera.org/learn/real-time-systems
I recommend this book: Firmware Guide, J. Ganssl. I read several chapters, in my opinion, sensible.
dmkpress.com/catalog/computer/programming/978-5-97...
Request handler and response generator. For each device, this should be something different. How to arrange it beautifully? What would not break the code of an existing one?
but it seems to me that this is a problem of building the architecture of the application.
Judging by the update, the issue is really in the development of architecture and has little to do with microcontrollers.
In your case, it is customary to divide the code responsible for communication into layers (
In my opinion, the obvious solution follows the open / closed principle and
is implemented in a bunch of protocols and frameworks):
Abstraction layer from hardware / Layer for transferring "bytes" (including device IDs,
i.e. packing an array of bytes into packets with an ID, possibly a length and checksum field) / A layer that can somehow report the arrival of new data (for example, callbacks).
In case of serious memory problems (such as only 256 bytes of RAM),
I would write a code generator, i.e. the abstraction itself (layers) would exist only in
code, and the generator would analyze the description of the protocol and handlers and
mix all the layers into one mess.
In addition to such problems, sometimes I encounter such a problem that I don’t know what is better to use: hang everything on interrupts or a cyclic handler and prescribe sequential processing with my hands (the task was solved in real time not on RTOS (hands have not reached it yet))
Why not just calculate by choosing one of the criteria - speed, implementation time, memory consumption. And of course, use finite state machine generators.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question