A set of common codes suitable for small projects[Copy link]
BabyOS
Born for small projects, a weak operating system that needs to be fed collectively like a child. Why is it called a weak operating system? Because compared with the existing embedded operating systems, this one seems relatively weak. Let's call it an operating system here, and its essence is a code concentration camp.
Applicable projects
BOS: Does the current project require the use of an operating system such as FreeRTOS?
U: Yes!
BOS: Sorry, I may not be the right person for you.
U: Just kidding, no operating system is needed
BOS: Then you can try me!
Let’s talk about the reason for writing such a thing, and you will roughly know the functions of this BOS.
................
One day, a monkey said that there are only two requirements for projects now, power consumption and development time. 99.874% of products are battery-powered, so power consumption is the key consideration. Secondly, the functions of the products are not complicated, and there are many repeated parts between projects. Is there a set of codes that can reduce repeated work and speed up the development of product demos?
..............
Power consumption . In order to reduce power consumption, the operating principle for peripherals is to wake up the peripherals and put them to sleep after the operation is completed. This form of operation is very similar to the operation of files. The steps of file operation are opening, editing and closing. It is decided to treat the operation of peripherals as the operation of files. After each peripheral is opened, a descriptor is returned. The operation of the peripheral in the subsequent code is based on this descriptor. The descriptor is recycled after the peripheral is closed. Then in the driver of the peripheral, the opening and closing operations can perform the wake-up and sleep of the device. Another advantage of using descriptors to operate peripherals is that when the peripheral is replaced, only the driver interface needs to be replaced, and the code of the business part does not need to be changed.
Rapid development : In the development of small projects, there are many functional modules with high usage rates, such as UTC, error management, battery power, storage data, host computer communication, firmware upgrade, etc. These functions are made into independent modules, independent of hardware. With a configuration file, each time the functional module used in the current project is selected according to the functional requirements. In simple terms, it is like building blocks.
BOS 0.0.1 version driver only adds the simulated serial port and Winbond flash. The existing functional modules are shown in the following table.
Serial number
Functional modules
illustrate
1
Power detection
Support setting thresholds to determine battery status, normal or low battery
2
Verification calculation
Support CRC32, cumulative sum, XOR and checksum
3
Error Management
Supports two levels of error management
4
Incident Management
Support events to trigger an action
5
MODBUS Protocol
Support MODBUS protocol RTU transmission package assembly and analysis
6
Private Protocol
Protocol format: [header|id|len|cmd|data|crc]
7
Firmware Upgrade
Support firmware upgrade (receiving and storing new firmware based on private protocol)
8
Data Access
Support three data storage modes (timing storage, single storage, continuous storage)
9
Send Management
Manage the order of sending data to prevent new data requests from being sent before the data is sent.
10
UTC
Supports UTC conversion, the UTC start time is 2000-1-1 0:0:0
Battery detection requires providing an ADC conversion interface, setting a threshold, and determining the current battery status
Verification calculation provides several verification methods, which can be used when necessary
Error management provides two levels of error management. Low-level errors only report an exception once, and high-level errors require manual clearing of the exception information in the management unit, otherwise the exception will be reported after the interval expires. When the system is abnormal, submit the exception to the management unit and specify the minimum interval for the same error to prevent the same exception from being submitted multiple times in a short period of time.
Event management supports registering a function to trigger execution when needed
MODBUS supports RTU protocol packet sending and data analysis
Private protocol Support private protocol, format: Header (1 byte) | ID (4 bytes) | Len (1 byte) | Cmd (1 byte) | Data | CRC (1 byte)
Firmware upgrade: Support receiving and storing new firmware based on private protocol
Data access supports three types of data access: scheduled storage (for example, storing once an hour or once a day), one-time storage (storing data with verification, such as storing configuration data), and continuous storage (continuously storing data of a fixed size on the flash, supporting the acquisition of the number of stored data, such as storing abnormal logs and obtaining the number of stored logs)
Sending management supports the sending of management data, ensuring that new sending requests can be successful only after data sending is completed
UTC supports conversion between UTC and year, month, day, hour, minute and second. The UTC start time is 2000-1-1 0:0:0
Some functional modules need to use specific peripherals, and you need to specify the specific device when creating a functional module instance. For example, for data access, you need to specify the corresponding flash device when creating a functional module.
If the function of a product is to collect data once an hour for storage and reporting, and support the host computer to obtain historical data, there are many such simple terminal devices in the field of Internet of Things. To complete this function, you only need to add 2, 6, 8, 9, and 10. If you need to monitor the abnormal state of the device, add 3, if you need to upgrade the firmware, add 7, and if you need to be powered by battery, add 1.
How to use
1. Add files
Add all files in the bos/core/src directory to the project
Select the required bos/driver/src and add it to the project
bos/hal/ Add to project, modify according to specific platform
2. Select functional modules
Configure b_config.h and select functional modules according to your needs.
3. List the equipment you need to use
Find b_device_list.h and add the peripherals to be used. For example, if the current project only needs to use flash and simulated serial port, then add the following code:
bInit(); // Initialization, the initialization of the peripherals will be called here
//The following example uses the device
int fd;
fd = bOpen(SUART, BCORE_FLAG_RW); //SUART is the device added in b_device_list.h
if(fd >= 0)
{
bWrite(fd, (uint8_t *)"hello world\r\n", strlen("hello world\r\n")); //Send string
bClose(fd);
}
If a device is opened and in use, it cannot be opened again.
5. Use functional modules
int sdb_no;
sdb_no = bSDB_Regist(0, 1, W25QXX); //Create a Class B data storage instance, specify the device W25QXX, and obtain the function module instance ID sdb_no
//sdb_no is greater than or equal to 0 if it is valid
int bSDB_Write(int no, uint8_t *pbuf);
int bSDB_Read(int no, uint8_t *pbuf);
//Read and write functions pass in instance ID sdb_no
feed
The reason why it is called a weak operating system that needs to be fed is that drivers and functional modules need to be added little by little. The more added, the faster the subsequent development will be.
BabyOS is an active project and is constantly updated. I will not reply to this post for the latest updates. If you are interested, you can go directly to the source code address to check the latest developments!
Netizens still need to add drivers and functional modules. Only when these are enriched can its advantages be reflected and the development of small projects be accelerated.
This post was last edited by huo_hu on 2019-12-24 11:09
I'm not really interested. It's not that simple. Take ADC for example. If we don't consider data transmission, sampling bit number, sampling channel number, sampling frequency, sampling time synchronization, and the number of ADCs working at the same time... then the problem is very simple. However, there is basically no demand that does not involve these.
When these conditions are combined, and different platforms are considered, there are thousands of possibilities. How can we do it?
Let's take your ADC as an example. ADC does need to consider the sampling bit, channel, frequency, sampling time, etc. Note that what you said are all driver parts. The functional modules involved in my code do not depend on specific hardware. For example, the sampling of battery power, the ADC sampling function is to do
Details
Published on 2019-12-24 11:21
huo_hu posted on 2019-12-24 11:07 Not very interested, it's not that simple, take ADC for example, if we don't consider data transmission, sampling bit number, sampling channel number, sampling frequency, sampling time synchronization...
Let's take your ADC as an example. ADC does need to consider the sampling bit number, channel, frequency, sampling time, etc. You mentioned. Please note that these are all driver parts. The functional modules involved in my code do not rely on specific hardware. For example, the sampling of battery power, the ADC sampling function is a weak function, and the ADC implementation is implemented by the user according to his own hardware. So what you mentioned is not a problem at all.
From the perspective of the driver, first, is the ADC built into the MCU or an external chip? If it is built into the ADC, then you need to implement it according to your own platform when using it. Second, if it is an external chip, then can the driver of this chip be written into a universal code?
Regardless of the functional module or the driver, what you mentioned is not a problem
In fact, there is no so-called universal software and hardware, it is just equipment that meets certain protocol standards, and without protocols it is empty.
Details
Published on 2019-12-24 14:26
liklon posted on 2019-12-24 11:21 Let's take your ADC as an example. ADC does need to consider the sampling bits, channels, frequency, sampling time, etc. You mentioned. Pay attention to what you said...
In fact, there is no so-called universal software and hardware, it is just equipment that meets certain protocol standards, and without protocols it is empty.
I am very happy to discuss this with you. For the general purpose of MCU, I think this way. In terms of functional modules, a set of codes that do not depend on hardware, such as FIFO, UTC conversion, storage mechanism, etc., will be used in the project, and these functional modules can indeed be written to be independent of hardware. So this is
Details
Published on 2019-12-24 15:05
huo_hu published on 2019-12-24 14:26 In fact, there is no so-called universal hardware and software. It is just equipment that meets certain protocol standards. Without protocols, it is empty.
I am very happy to discuss this with you. This is what I think about the universality of MCU. In terms of functional modules, a set of codes that do not depend on hardware, such as FIFO, UTC conversion, storage mechanism, etc., will be used in the project, and we can indeed write these functional modules to be independent of hardware. Then this is the universal functional module for MCU. In terms of drivers, there is a set of standard interfaces to operate peripherals, which is also universal for MCU. For example, in this code, I contacted to write the interface for operating peripherals as file operations. This is very convenient for us to use, and we do not need to change the business code when changing hardware. In general, universality does not mean that a set of codes can meet any project, but a set of standard things that can facilitate development or reduce development time, and can be used as soon as it is taken.
This post was last edited by liklon on 2020-1-3 09:25
2019_12_04~2020_01_02 Update Notes
Instructions
FIFO
int bFIFO_Regist(uint8_t *pbuf, uint16_t size); //注册FIFO实例
int bFIFO_Length(int no, uint16_t *plen); //获取有效数据长度
int bFIFO_Flush(int no); //FIFO读写复位
int bFIFO_Write(int no, uint8_t *pbuf, uint16_t size); //写入数据
int bFIFO_Read(int no, uint8_t *pbuf, uint16_t size); //读取数据
AT
typedef struct
{
uint8_t *pResp; //响应数据
uint16_t len; //响应数据长度
uint32_t timeout; //给定超时时间，调用bAT_Write之前给定超时时间
}bAT_ExpectedResp_t;
int bAT_Regist(pAT_TX ptx); //注册AT使用实例，ptx是发送数据的接口
int bAT_Write(int no, bAT_ExpectedResp_t *pe_resp, const char *pcmd, ...);
//发送AT指令， 实例ID 结构体，如所述 不定长参数
int bAT_Read(int no, uint8_t *pbuf, uint16_t size);
//例如AT指令通过串口进行收发，串口接收到模块响应数据后将数据通过这个函数提交给AT单元
//使用详情可见bos/drivers/src/b_f8l10d.c
Nr_micro_shell
int bShellStart(void); //shell 初始化
int bShellParse(uint8_t *pbuf, uint16_t len);
//例如用串口进行交互，串口收到数据后将数据通过此函数丢给shell进行解析
BabyOS was last updated before the Chinese New Year. Recently, a new item was added. Please help me see if there is any room for optimization and fix it before the Chinese New Year.
is based on SPI Flash access, without a file system. It occupies 4 minimum erase units (4 * 4K) of SPI Flash and occupies N * 12 Bytes of MCU memory (N represents the maximum number of key-value pairs that can be stored, configured by b_config.h).
The 4 minimum erase units are divided into two groups A and B. Each group has two blocks to store data index and data respectively.
A1 stores data index
A2 stores data
B1 stores data index
B2 stores data
Every time a K/V key-value pair is modified or added, the information header and data are written to A1 A2 in sequence. When one of A1 or A2 is full, the valid data index and data extraction are transferred to B1 B2, and the main storage is transferred to group B. When group B is full, it is transferred to group A in the same way.
Every time a new addition or modification is made, the Flash will not be erased, ensuring the service life.
When a minimum erase unit is full, the valid part is extracted and transferred to another area. No large buffer is defined in the memory for processing. This is mainly because the MCU memory is a scarce resource and cannot be occupied at will.
It would be great if it could be adapted to a variety of microcontrollers. I hope it will be adapted later. I also hope to release one or two video tutorials on how to use it. Great!
Two new features are added to facilitate file transfer to MCU
Xmodem128
//Xmodem128 receiving part
int bXmodem128Init(pcb_t fcb, psend fs); // Initialization, register callback and specify the function to send bytes
int bXmodem128Parse(uint8_t *pbuf, uint8_t len);
//Data parsing, call this function after receiving data. You need to call this function after receiving a section of data, you cannot put it in byte by byte.
int bXmodem128Start(void); //Start receiving
int bXmodem128Stop(void); //Interrupt receiving
void bXmodem128Timeout(void); //Judge timeout, called by bExec()
typedef void (*pcb_t)(uint8_t number, uint8_t *pbuf);
//Callback function, number is the serial number, pbuf is the data pointer. The data length is 128 bytes each time
Ymodem
int bYmodemInit(pymcb_t fcb, pymsend fs); // Initialization, register callback and specify the function to send bytes
int bYmodemParse(uint8_t *pbuf, uint16_t len);
//Data parsing, call this function after receiving data. You need to call this function after receiving a section of data, you cannot put it in byte by byte.
int bYmodemStart(void); //Start receiving
int bYmodemStop(void); //Interrupt receiving
void bYmodemTimeout(void); //Judge timeout, called by bExec()
typedef void (*pymcb_t)(uint8_t t, uint8_t number, uint8_t *pbuf, uint16_t len);
//Callback function, t is the data type (file name/data), number is the sequence number, pbuf is the data pointer, len is the data length
There are examples in the code, using Xmodem128 and Ymodem to receive files, store them in spiflash, and read them out through the serial port after the transmission is completed. Experimental results:
提升卡
变色卡
千斤顶
From 2
京公网安备 11010802033920号
