liteos / liteos Goto Github PK

some bugs in kernel api example,such as : msg queue and task test, some params need fix to suite more MCU.

Hi all,

The source file in api_example are now using GBK encoding.

Maybe we should convert this to UTF-8 first,
thanks.

From the source code of los_bsp_flash.c, it seems to me it offers the wrapper layer of fatfs, not flash itself.
I am wondering to have the way to access the raw flash data via any pre-defined interface just like los_bsp_{module_name}.

Please advise it, thanks.

您好，我看您stm32f411re文檔，下載STM32CubeF4這邊寫成STM32CubeL4了。
STM32CubeF4 1.16連結

NXP is an important IC/Sensor manufacturer , We should support the LPC series mcu.

建议代码注释采用doxygen 注释风格，这样将来你的LiteOS成熟了，发布的时候，说明文档一并就完成了~

we shoud verify liteOS on stm32f429 by keil

We should coordinate markdown file for LiteOS migration on stm32f429

Need to be optimized: interrupt handle has been taken over by LiteOS, but the hardware driver might register and cause exception.
A common way of using Huawei LiteOS would be run through the original demo code without operating system, and then integrate it with LiteOS.
Since Huawei LiteOS has already taken over the interrupt handler and registration mechanism, under this situation, a proper register mechanism or to give a proper error hint might be a better choice.

Now we have two rep , one is on github and the other is on isource, they are independent now.How to make them synchronized? For example, in some markdown files , there are some pictures , we can access it on github, but we can't access it on isource.

OS_INCLUDE_HWI and OS_INCLUDE_HWI mentioned in Readme.md both have changed, which are defined accordingly as LOSCFG_PLATFORM_HWI and LOSCFG_PLATFORM_HWI_LIMIT now. Please update um in line with source code.

In the Huawei LiteOS 2017 Hackthon, Beijing Station, one of the programmers found there were two interfaces declared in header files los_queue.h, but "undefined error" was reported during the linking process.

After a debugging, I found there's no definition, which need to be fixed.

hi i use los_api_interrupt.c but,I got failed in
uwRet=LOS_HwiCreate(6,0,0,EXTI0_IRQHandler,NULL);
i dont know why?
My EVB use STM32F407
code

I found in HuaweiLiteOSKernelEnv.chm have provide a Huawei_LiteOS开发包,
which including Linux compile environment.

will this develop package be open source or public?

thanks.

LiteOS need a file system,because using the file system to manage huge amounts of data will be more convenient.We can expand a suitable file system,such as FAT(File Allocation Table) file system, is designed for small embedded system .

we should create some doc for the workshop. and give some illustration

一直在使用FreeRTOS,看到华为也出了LiteOS表示很好.

但是有一个问题,移植虽然简单,就一个SysTick就搞定了.但是,可裁剪性我感觉一般,比如我就不需要锁定任务,创建后如果优先级高,马上就可以调度,优先级相同可以等着目前任务完成再调度.

还有RAM管理,希望能做非连续内存分配,因为部分内存我是用于低功耗保持的,他在片内中间的一段RAM.地址映射为SRAM0 - LPSRAM - SRAM1.

最好出英文文档,走出国门!

to make the source codes looks grace.

In develop branch, STM32L476 platform folder, los_bsp_adapter.c STM32L476xx defined deault in keil stm32L476 pack, so, this make some compile err for this project. we should change it to LOS_STM32L476xx

We will add drivers for NB-IoT chips. some IoT chips may drive by AT command, some may not. we will give a unified IoT drive frame, and provide some chip's low-level drivers, for example Quectel_BC95_NB-IoT's driver.

we should verify kernel api on stm32f429

动态内存释放失败

参考动态内存释放的例子，编写如下测试程序，内存初始化、内存申请都成功，但是内存释放却失败了。没看出哪里有问题，代码如下:
(usart2_printf是一个串口打印字符串的函数，硬件基于STM32f103RBT6平台)

VOID los_memory_test() {
    char *p_num = NULL;
    UINT32 uwRet;
    uwRet = LOS_MemInit(m_aucSysMem0, 1024);
    if (LOS_OK  == uwRet) {
        usart2_printf("mempool init ok!\r\n");
    }
    else {
        usart2_printf("mempool init failed!\r\n");
        return;
    }
    /*申请内存*/
    p_num = (char*)LOS_MemAlloc(m_aucSysMem0, 8);
    if (NULL == p_num) {
        usart2_printf("mem alloc failed!\r\n");
        return;
    }
    usart2_printf("mem alloc ok\\r\n");
    /*内存赋值*/
    p_num = "hello";
    usart2_printf("*p_num = %s\r\n", p_num);
    /*释放内存*/
    uwRet = LOS_MemFree(m_aucSysMem0, (char*)p_num);
    if (LOS_OK == uwRet) {
        usart2_printf("mem free ok!\r\n");
    }
    else {
        usart2_printf("mem free failed:%d\r\n",uwRet);
    }
    return;
}

执行到释放内存时，uwRet = 1
执行结果:

[00:14:28.061] mempool init ok!
[00:14:28.073] mem alloc ok\r
[00:14:28.092] *p_num = hello
[00:14:28.110] mem free failed:1

Need to be optimized:
delay_ms() or delay_us() of the 3rd party drivers will trigger interruption during the hardware initialization.

A common way of using Huawei LiteOS would be run through the original demo code without operating system, and then integrate it with LiteOS.
Since Huawei LiteOS has already take over the system tick interruption, so the delay_ms() interface of 3rd party drivers will trigger exception and the whole initialization will fail. I think there should be a way to allow the programmers to use delay method during the initialization.

example code in Guide book "中断机制，编程实例"

#include "los_hwi.h"
#include "los_typedef.h"
#define HWI_NUM_INT50 50
void uart_irqhandle(int irq,void *dev)
{
    printf("\n int the func uart_irqhandle \n");
}
void hwi_test()
{
    int a = 1;
    UINTPTR uvIntSave;
    uvIntSave = LOS_IntLock();
    LOS_HwiCreate(HWI_NUM_INT50, 0,0,uart_irqhandle,NULL);//创建中断
    hal_interrupt_unmask(HWI_NUM_INT50);
    LOS_IntRestore(uvIntSave);
    hal_interrupt_mask(HWI_NUM_INT50);
}

• 示例有问题
  问题1：把找不到的hal_interrupt_mask注释掉。实测：
  问题2：直接这么写的话，当触发串口中断，会一直printf内容出来。需要在printf前清中断标志位。
• 如果需要手动清中断，则与手册的中断管理内容不符合
  在 "中断机制，概述"中，“Huawei LiteOS的中断机制支持中断共享，Huawei LiteOS的中断机制支持中断底半部，底半部基于workqueue”
  workqueue即任务队列，中断后是直接遍历queue处理，没必要每个queue都去手动清标志位吧。这方面是否可以做的更完善？

I have just reviewed usr/main.c and found that there were a few meaningless blank space in the end of line and tab space in the beginning of line. I suggest you guys could use vim plug-in unit for detecting this code style issue.

As Huawei is an influent IT company, I think it's better to make the source codes to look beautiful.

In los_bsp_adapter.c, LosAdapIrpEnable() should be LosAdapIrqEnable().
There is LosAdapIrqDisable() and LosAdapIrqEnable().

Migration guide files nead to optimize,some of them should be more detail，such as stm32l476.

please add Arduino support, I am Linux user.

In master branch, there is a break point at los_task.c LOS_TaskYield() function , we should disable it.

ST is an important IC/Sensor manufacturer,we should support the ST series mcu,this work makes sense for our ecosystem.

I found that most of the kernel source files using following grammar:

#ifdef __cplusplus
#if __cplusplus
extern "C" {
....
}
#endif
#endif

like here: https://github.com/LITEOS/LiteOS_Kernel/blob/master/kernel/base/mem/los_memory.c#L43

I think the inner #if __cplusplus is not needed here, the outer #ifdef __cplusplus can handle things properly. Actually, there exists quite a few old compilers that define __cplusplus to 0 or just empty, which would cause the wrapped source code not be compiled at all.

Do we have other considerations of using two overlapped #ifdef __cplusplus #if __cplusplus here?

We need integrate Porting Contest projects to LiteOS Kernel,Is conducive to our ecological environment.

I think we should add some guide links about LiteOS project, for example
Getting Started:
1:How to contribute
2:Boards supported
3:How to write LiteOS commit log
4:Extend functions
fs
network
NBIoT

I cannot find any states about JavaScript VM (Huawei MapleJS) of Runtime Engine in docs. However, I saw this concept in previous propaganda poster and the last LiteOS Hackathon. Because it can ease the burden from the JavaScript programmers to IoT world. So I ask for help about it. Does it unfinished? Or this function had been removed from the architecture of LiteOS?

Now we just have a master branch, When we develop some new features or correct some bugs , we can just make a pull request to master branch, maybe it's dangerous. So do we need create a branch?

I tested the stm32f429 iar project, the project can compile ok, but can't run correctly. but on master branch iar project can run correctly.

interrupt guide:

void hwi_test()
{
    int a = 1;
    UINTPTR uvIntSave;
    uvIntSave = LOS_IntLock();
    LOS_HwiCreate(HWI_NUM_INT50, 0,0,uart_irqhandle,NULL);//创建中断
    hal_interrupt_unmask(HWI_NUM_INT50);
    LOS_IntRestore(uvIntSave);
    hal_interrupt_mask(HWI_NUM_INT50);
}

hasn't find function of " hal_interrupt_unmask"

调试时程序死在oshwidefaulthandler这个函数的while(1)
烧写完后串口打印的是这些
LOS_TaskLock() Success!

Example_TaskHi create Success!

Example_TaskLo create Success!

Enter TaskHi Handler.

Enter TaskLTaskHi LOS_TaskDelay Done.

Handler.

复位后就收到是
LOS_TaskLock() Success!

Example_TaskHi create Success!

Example_TaskLo create Success!

MindMotion provided us with some boards for porting, this work makes sense for our ecosystem.

issue关闭，移至LiteOS中讨论
在M0+移植中，
LOS_QueueCreate时的参数usMaxMsgSize如果不是4的整数倍，将会造成向队列第二次写入时，有不对齐的内存写入操作，造成hardfault错误.
针对M0+这样需要对齐操作的MCU，参数usMaxMsgSize在函数内是否需要增加对齐处理？

Hi,

I'm so excited to see the gcc support in liteos, but when I tried to build STM32F429I_DISCO_GCC, I failed.

I'm using the cross compiler toolchain: arm-none-eabi-gcc(version 4.9.3)

The log is attached as follow:

work@ubuntu:~/me/liteos/projects/STM32F429I_DISCO_GCC$ make
arm-none-eabi-gcc -g -O0 -Wall -mlittle-endian  -mcpu=cortex-m4 -march=armv7e-m -mthumb -mthumb-interwork  -mfloat-abi=hard -mfpu=fpv4-sp-d16 -D LOS_GCC_COMPILE -D _GCC_WRAP_STDINT_H  -ffreestanding   -D ARM_MATH_CM4 -std=gnu99  --specs=rdimon.specs  -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/base/include -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/include -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/link/gcc -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/config -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cpu/arm/cortex-m4 -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../platform/STM32F429I_DISCO -I /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../example/include -c  -o /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.o /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.c
In file included from /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/link/gcc/cmsis_gcc.h:39:0,
                 from /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.c:37:
/usr/include/newlib/sys/_stdint.h:31:19: error: conflicting types for 'int32_t'
 typedef __int32_t int32_t ;
                   ^
In file included from /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.c:35:0:
/home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_os.h:161:13: note: previous declaration of 'int32_t' was here
 typedef int int32_t;
             ^
In file included from /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/link/gcc/cmsis_gcc.h:39:0,
                 from /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.c:37:
/usr/include/newlib/sys/_stdint.h:32:20: error: conflicting types for 'uint32_t'
 typedef __uint32_t uint32_t ;
                    ^
In file included from /home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.c:35:0:
/home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_os.h:160:22: note: previous declaration of 'uint32_t' was here
 typedef unsigned int uint32_t;
                      ^
Makefile:120: recipe for target '/home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.o' failed
make: *** [/home/work/me/liteos/projects/STM32F429I_DISCO_GCC/../../kernel/cmsis/cmsis_liteos.o] Error 1
work@ubuntu:~/me/liteos/projects/STM32F429I_DISCO_GCC$ STM32F429I_DISCO_GCC

Thx & BRs

Some images with a mistake in lpc54110 and lpc824 migration guide files.

when do cmsis certification，what step we should follow?

We shoud modify thecode about the test code for interrupt，and make it work on stm32f429

we shoud verify liteOS on stm32f411 by keil ，and commit the code

按照参考文档编写下面的代码：

• 1、中断处理函数

void EXTI15_10_IRQHandler(void){
        usart2_printf(" get in key int0\r\n");
        if(EXTI_GetITStatus(EXTI_Line13) != RESET){
	        GPIO_SetBits(GPIOA, GPIO_Pin_5);
        }
        EXTI_ClearITPendingBit(EXTI_Line13);
        return;
}

• 2、在liteos创建中断服务

void hwi_test()
{
        UINTPTR uvIntSave;
        UINT32 uwRet = 0;
         
    	key_init(); /*用户外部中断初始化*/
        uvIntSave = LOS_IntLock();
        uwRet = LOS_HwiCreate(40, 0,0,EXTI15_10_IRQHandler,0);
        if(uwRet != LOS_OK){
		      usart2_printf("create failed\r\n");
    	}
    	else{
		      usart2_printf("create succesful\r\n");
    	}
        LOS_IntRestore(uvIntSave);
        }

• 3、自己的中断初始化（功能正常，略）
• 4、第二步创建的hwi_test()，在osAppInit()使用
  我的问题是：
  不进行上面第二步在liteos创建中断服务hwi_test()操作，中断（按键）可以用，进行第二步hwi_test()操作也正常用，那这什么区别吗？我对系统编程不太了解，感觉不出有什么优势，或者是自己的错误用法。即时我不小心把 LOS_HwiCreate中HwiNum填错了，它也照常运行（HwiNum正确的情况下，建立一个任务，调用函数LOS_HwiDelete(中断号)倒是真的能把中断个禁止了），还请指导。

能否提供一下API接口手册，不是开发指南，这样用起来毕竟省事

two docs based on DISCO-STM32F429 with keil
one is the LiteOS_Migration_Guide_keil.md, the other one is LiteOS_Migration_Guide_stm32f429_Keil.md

which is standard?

Are there anyway to build LiteOS by GCC toolchain, it seem we can now only build from IAR embedded workbench and Keil.

Both of the IDE can't use it on Linux.

Thanks.