distortec / distortos Goto Github PK

Hi,

great work, thank you!

I wonder if you aim to implement further hardware drivers / HAL or similar, or is this development focussed on the RTOS "only"?

Thank you very much,
Jan

I hope I did not miss anything, but it seems there is no support for diagnostic output in the current implementation of distortos? Are there any plans to add for example Instrumentation Trace Macrocell (ITM) output (I dare to say in printf()-like redirection)?

(I would consider a contribution, but at the moment I am wrapping my head around embedded C++11 code...)

Some of the microcontrollers (like in STM32L0's familly) have common interrupt for USART4 and USART5.
Patch to fix thiss issue is here:
CezaryGapinski@484cca3

Change is on my develop branch for STM32L0, but I think that will be easy to get "cherry-pick" from this commit to the new branch direct from "master" branch, but I would like to ask you what do you thinking about that changes?

GitHub events should be posted on the distortos-development mailing list ( [email protected] ).

All other functions seem to use the lock_guard<>, except for open(), and open() is calling into the LFS1 API directly. Therefore, doesn't open() also need synchronization, since LFS1 is not safe to access from multiple threads?

If this is intentional, can you help me understand why this instance is OK?
(I ask this because I'm looking at how to make an existing code base that is using LFSv1.6 safe to call from multiple threads, and if open() is inherently thread-safe for some reason … well that'd be interesting.)

Thank you!

I am just wondering if support for tickless mode is on your TODO list?

I have followed the article -- Configuring and building a distortos-based project to build my project. The content of 'CMakeLists.txt' file is as follows:

cmake_minimum_required(VERSION 3.7)
project(my-project)

add_subdirectory(distortos)

add_executable(my-project EXCLUDE_FROM_ALL
		src/main.cpp
		src/OperationCountingType.cpp
		src/PrioritizedTestCase.cpp
		src/priorityTestPhases.cpp
		src/SequenceAsserter.cpp
		src/TestCaseCommon.cpp
		src/TestCase.cpp
		src/TestCaseGroup.cpp
		src/testCases.cpp
		src/waitForNextTick.cpp
        src/wasteTime.cpp)

target_include_directories(my-project
    PRIVATE
        ${PROJECT_SOURCE_DIR}/distortos/test
)

target_link_libraries(my-project PRIVATE
    distortos::distortos)
distortosTargetLinkerScripts(my-project $ENV{DISTORTOS_LINKER_SCRIPT})

include(distortos/test/architecture/distortosTest-sources.cmake)
include(distortos/test/CallOnce/distortosTest-sources.cmake)
include(distortos/test/ConditionVariable/distortosTest-sources.cmake)
include(distortos/test/Mutex/distortosTest-sources.cmake)
include(distortos/test/Queue/distortosTest-sources.cmake)
include(distortos/test/Semaphore/distortosTest-sources.cmake)
include(distortos/test/Signals/distortosTest-sources.cmake)
include(distortos/test/SoftwareTimer/distortosTest-sources.cmake)
include(distortos/test/Thread/distortosTest-sources.cmake)


distortosBin(my-project my-project.bin)
distortosDmp(my-project my-project.dmp)
distortosHex(my-project my-project.hex)
distortosLss(my-project my-project.lss)
distortosMap(my-project my-project.map)
distortosSize(my-project)

I successfully build this project. The output of command 'ninja' is:

$ ninja
[150/150] Linking CXX static library distortos/libdistortos.a

My problem is why I can't find '.hex' file in my ’output‘ directory? How can I burn the program to the chip?
I am a newbie in this area. Could you give me some advice to quickly get familiar with it? Thank you very much.

I couldn't find how to enable hardware flow control (RTS/CTS) for USART2 on STM32F103. I need it to interface with a GSM modem. Is it supported by distortos?

Hi!
It is a must for read (or write) function to be canceled immediatelly when timeout from timePoint occurs?
I mean situation where local buffer must be switched into SerialPort::readBuffer_ (or writeBuffer) for DMA (like for STM32F4, F7) where transfer cannot be stopped at once and after disable DMA can continue transfer till to flush the buffer.
It is especially issue for reading function if after DMA disable data can still be written to the local buffer which can be out of the read function when we supposse that the read function will finish immediatelly.

Hi,

I discovered some compilation errors for 4.9.3 toolchain (taken from Debian sid packages). Here are some trivial fixes:
#17

Here is a hard one for pure C programmer;)

In file included from include/distortos/internal/synchronization/MessageQueueBase.hpp:20:0,
                 from source/synchronization/MessageQueueBase.cpp:12:
include/estd/SortedIntrusiveForwardList.hpp: In instantiation of 'constexpr estd::SortedIntrusiveForwardList<Compare, T, NodePointer, U>::Implementation::Implementation(const Compare&) [with Compare = distortos::internal::MessageQueueBase::DescendingPriority; T = distortos::internal::MessageQueueBase::Entry; estd::IntrusiveForwardListNode T::* NodePointer = &distortos::internal::MessageQueueBase::Entry::node; U = distortos::internal::MessageQueueBase::Entry]':
include/estd/SortedIntrusiveForwardList.hpp:75:27:   required from 'constexpr estd::SortedIntrusiveForwardList<Compare, T, NodePointer, U>::SortedIntrusiveForwardList(const Compare&) [with Compare = distortos::internal::MessageQueueBase::DescendingPriority; T = distortos::internal::MessageQueueBase::Entry; estd::IntrusiveForwardListNode T::* NodePointer = &distortos::internal::MessageQueueBase::Entry::node; U = distortos::internal::MessageQueueBase::Entry]'
source/synchronization/MessageQueueBase.cpp:142:18:   required from here
include/estd/SortedIntrusiveForwardList.hpp:278:26: error: too many initializers for 'distortos::internal::MessageQueueBase::DescendingPriority'
     intrusiveForwardList{}
                          ^

Maybe it would be good idea to build distortos on travis using more traditional toolchains (Linaro or Launchpad). Not everyone likes bleeding edge approach :)

Hi!

I would like to ask if you have any plans to implement DMA drivers in HAL layer. As you noticed I've started some time ago implementing DMA on my own, so I it will be nice to know your opinion about this.

Below is a list of most important points what I stumbled across:

1. I was trying to create some abstract classes to DMA and put it into device layer level, but based on your previous comment in my code I realized that really will be better to move DMA driver to chip peripheral layer only without adding abstract to distortos devices level. DMA is too much specific to chip and there is no need to combine with DMA device.

2. There is still need to create other drivers which can use DMA. Based on device layer I've implemented ChipDmaBase interface with callbacks which can be used to create other DMA drivers (like ChipUartDmaTransfer class in USARTv2 peripheral).

3. The main class of DMA is ChipDmaLowLevel which is used to configure DMA peripheral. I was trying to deal with compatibility with future version of DMAv2 implemented in other STM32 families like F4 and F7 (for now I used L0 to develop DMAv1). That's why I've added startDoubleBuffer and exchangeDoubleBufferAddress methods which do nothing in DMAv1, but these have meaning in DMAv2 driver. Probably it is better to remove this methods right away from DMAv1. More important point is the correct approach to start and startTransfer methods. Do you think it is good to have the same method signatures for DMAv1 and DMAv2 versions even if burst or fifo threshold is not supported in the DMAv1? Maybe should be somewhere in perihperal abstract class with common interface for DMAv1 and DMAv2 or it is too complicated? I'm just worrying about conditional preprocessor in the code to use different start and startTransfer methods for DMAv1 or DMAv2 it they have different signatures.

4. Usage of stopTransfer method (which can be used indirectly in SerialPort to load chunk of data into USART buffer). For DMAv2 I've noticed in the reference manuals descriptions about suspending transactions, where is need to disable DMA channel, and next wait till transfer complete interrupt will be called, to be sure that this chunk of transfer is finished and next DMA transfer counter can be read. For chips which are using DMAv1 I didn't noticed that requirement, so now channel is just disabled and next transfer counter is read. I was thinking about using semaphore to deal with this issue for DMAv2, like in SerialPort class, to wait for interrupt to notify stopTransfer method about correct DMA transfer channel disable. But in this option DMA driver will use Semaphore what causing too much relation between distortos Core and HAL layer. Maybe it is easier to make pull method to check Transfer Complete flag and next channel enable bit is reset to 0.

5. Exemplary usage in USARTv2 driver:
   I was pretty long thinking about how to connect DMA transfer and USART. Eventually I've decided to create ChipUartDmaTransfer objects which hold references to ChipUartLowLevel and ChipDmaLowLevel peripherals. From USART side it is used to configure and start DMA transfer. From DMA side it is used to call specific USART transfer complete and error methods.
   ChipUartDmaTransfer objects are created as global objects. Constructor needs reference to USART and DMA peripherals in compile time, that's why getDmaLowLevel constexpr function is used to get peripheral for DMA module and channel.

6. Configuration in kconfig:
   I mostly based on STM32L0 family. I think the most important problem is with remapping channels to specific peripheral in this commit: CezaryGapinski@f464351
   As you can see there is a lot of code to code with few channels for USART but I didn't have better idea to make this think better.

I have plans to buy STM32F429I-DISC1 board to try implement DMAv2 driver. Maybe then much better idea come into my mind how to bring DMAv1 and DMAv2 to a common interface, etc, but I would like to ask what do you think about my code from dmav1_with_usartv2_for_stm32l0 branch. It is totally screwed and you have other plans to implement DMA transfer. If yes please, let me know, because I don't know if I should continue to work on that or it is better to gave up with this :).

Distortos supports the evaluation boards, but configurations are limited only to support leds or buttons. Often boards have extension headers, that can be used for many kind of custom usages. Where is a good place to put the user configs for pins? Do I need to put my config to main() function (but os is already running)?
Low level Initialization for board is called before main() function and I think this is the best place to put other settings. I need to create my own full customization for eval board and own lowLevelInitialization() function?

Hi,
Just to know whether there are plans or not to support the F7 series?

regards
Haithem.

Windows 10 Pro Build 21286
~\Documents\distortos\build [master ≡ +1 ~0 -0 !]> git describe
v0.7.0-299-g53ee25952

~\Documents\distortos\build [master ≡ +1 ~0 -0 !]> cmake --version
cmake version 3.19.5

CMake suite maintained and supported by Kitware (kitware.com/cmake).

~\Documents\distortos\build [master ≡ +1 ~0 -0 !]> ninja --version
1.10.1

~\Documents\distortos\build [master ≡ +1 ~0 -0 !]> arm-none-eabi-gcc --version
arm-none-eabi-gcc.exe (GNU Arm Embedded Toolchain 10-2020-q2-preview) 10.1.1 20200529 (release)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

=>

~\Documents\distortos\build [master ≡ +1 ~0 -0 !]> cmake .. -DCMAKE_TOOLCHAIN_FILE=..\source\board\ST_STM32F4DISCOVERY\Toolchain-ST_STM32F4DISCOVERY.cmake -GNinja
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:17 (project):
  No CMAKE_C_COMPILER could be found.
...

Previously it was selecting clang (until I uninstalled it).

It looks as if the toolchain file isn't being ran, but when I mis-spell it, CMake complains about 'can't find file'. That said, adding message(...) calls in the toolchain file doesn't result in output.

This works fine in wsl.

Just wondering, I've been poking around the repo and don't feel confident putting in a pull request. I imagine there are some behind-the-scenes scripts to harvest data about a chip family.

I have a https://www.st.com/en/evaluation-tools/stm32g474e-eval.html that I could test on and would be willing to get a NUCLEO-G474RE if that would help.

I tried to build the current version on my Mac and I got:

ilg-mbp:distortos.git ilg$ tup
[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.004s] Reading in new environment variables...
[ tup ] [0.004s] Parsing Tupfiles...
* 1) [0.225s] .
tup error: Expected node 'output' to be in directory '.', but it is not there.
tup error: Failed to find directory ID for dir './output/distortos.elf' relative to 1
tup error [string "builtin"]:217: Error while parsing 'outputs'.
stack traceback:
    [C]: in function 'definerule'
    [string "builtin"]:217: in function <[string "builtin"]:61>
    (...tail calls...)
    [string "Tuprules.lua"]:134: in function 'link'
    [string "Tupfile.lua"]:12: in main chunk
 [          ETA~=10s Remaining=41           ]   2%
 *** tup: 1 job failed.

I installed tup from MacPorts, and added gcc-arm-none-eabi-4_9-2014q4/bin to the PATH.

Any suggestions?

Regards,

Liviu

Hello,

I'm trying to build the distortos for the STM32F429I MCU:
I'm doing the follwing steps:

• make configure CONFIG_PATH=configurations/32F429IDISCOVERY/test/
• make all

but I'm getting the following error:
[ 20%] LD output/test/distortosTest.elf output/STM32F429ZI.ld:49: undefined symbol '__rom_start' referenced in expression collect2: error: ld returned 1 exit status Makefile:247: recipe for target 'output/test/distortosTest.elf' failed make: *** [output/test/distortosTest.elf] Error 1

I'm on fedora 23 with arm-none-eabi-g++5.2.0

regards
haithem.

we did some further tests, and (with the linux toolchain downloaded from https://sourceforge.net/projects/bleeding-edge/files/141220/), when using -Og, the function
void ThreadControlBlock::threadRunner(ThreadControlBlock& threadControlBlock)
is excessively optimised to a while(1) loop.

for the same code, using the latest launchpad compiler, -Og seems ok, the generated code for the above function is correct.

I have no idea what differs between the two toolchains, but apparently they are build differently.

regards,

Liviu

p.s. as a suggestion for your builds: use -Og -fno-move-loop-invariants for the debug configuration and -Os for the release configuration.

Hello,

I have managed to successfully build distortos in Bash on Ubuntu on Windows 10 and I would like to ask if you could consider using readlink instead of realpath --relative-base=. in scripts\generateKconfig.sh ?

There is a slight problem with coreutils package that comes with Ubuntu on Windows release, namely its realpath command does not support --relative-base option, which causes the build to fail. I am aware of the official instructions to use GNU Coreutils and the existing confusion with the other coreutils [1], but it seems realpath is the only command needed to build distortos (I have commented out the line in the .sh script and there have been no other errors) and replacing it would remove the GNU Coreutils dependency, thus making the whole process easier (?)

[1] What's the difference between “realpath” and “readlink -f”

Thanks,
CW2

Is this project dead? No recent activity.

As you noticed I'm working on the STM32L0 line implementation. I've noticed that SPI implemented in the STM32L0 devices is pretty similar to the actual SPIv1 peripheral. There are two differences in registers:
SPI_CR2 register: Bit 4 - reserved for STM32F1, FRF (Frame format 0 - Motorola, 1 TI mode) for STM32L0
SPI_SR register: Bit8 - reserved for STM32F1, FRE (Frame error) for STM32L0

But there is also problem with accessing bits in this registers. SPIv1 use bit-banding and if it is nice for STM32F1 MCUs is a problematic for STM32L0 without this feature. What I noticed SPIv2 is not using bit-banding even for devices with bit-banding functionality.

I would like to implement SPI feature in STM32L0 line thats why I've question if it is good option to just replace actual SPIv1 peripheral without bit-banding access or I should create next type of peripheral for example SPIv3.

If it is a good option to extend present driver it is also possible to add FRF and FRE bits with some sort of #define option configured in Kconfig-stm32ChipFamilyChoices file or it should be implemented with other approach?

hi, is there a plan to support arm cortex a9?

Thanks,
Gerald