Hi Bob, firstly thanks for sharing this :D.
Having only the PSoC 4M prototyping kit and still being a n00b to RTOSes i did the boring task of toggling an LED and another task that prints a message to a terminal emulator using the Software UART component.
The project didn't worked until i increased the heap size to 0x400, with 0x300 the HardFault error/routine is triggered which in this project turns the LED on "for ever", i still don't know how to calculate the heap size.
And the only comment i have is maybe all the routines related with ARTS can have the ARTS_ prefix, a component having the ARTS header and source file would be great aswell :D.
ARTS_043kit.cywrk_.Archive01.zip 464.2 K
Increase the heap size to its maximum. ARTS only uses heap memory (asides a few bytes for internals).
and I increased the stack size.
That's all. I wasn't quite sure whether the software UART would run. It does! fine!!
"And the only comment i have is maybe all the routines related with ARTS can have the ARTS_ prefix" The routines ARTS uses internally should be declared as "static", so they cannot be seen from outsides. All APIs have got the ARTS_ prefix, or did I forget one?
Maybe ARTS_Task and ARTS_ParameterTask would be a little more intuitive, still have to dive in deeper.
Task() and ParameterTask() are just macros, the concept "Task" is unique to RTOSses, so I did not prepend them with "ARTS_"
Some tips to get your ARTS projects working:
In the System view of Creator: Set the stack size to 0x0200 and the heap to 0x3800 (lower that, when sram gets busted)
In ARTS.c: Set a breakpoint at ARTS_ErrorHalt() in case something goes wrong you will see where and why.
In your main.c: ARTS_CreateTask(YourTask,70,1) The second parameter is the task's stack size, use values > 60
To save flash, you may set ARTS.c optimization by right clicking on it in the Workspace Explorer window -> Build Settings -> ARM GCC -> Compiler -> Optimization and set to speed or size.
This feature you may use for any other .c module that you do not need to debug any more.
I have run into a issue using the PRoC 256K and am wondering if you think your ARTS could help me. My application uses the PRoC ADC to read acceleration values and I need to insure that I maintain a read every 20 ms. The ADC data is written to external flash and transmitted over BLE every 20 ms. The problem I am having is that when the BLE connection gets weak my ADC reads are getting blocked by CyBle_ProcessEvents() so I start dropping ADC reads. Do you think putting the BLE and the ADC separate tasks using you ARTS could solve this issue?
N o, that will not help you. Storing data in flash is consuming a considerable amount of time. I would suggest you to use a "Circular Buffer" to store the ADC results in sram and read them off when BLE is available. With a buffer depth of 100 you will be able to bridge 2 seconds.
I found this topic today.
What a masterpiece!
I downloaded the package at the first topic.
Some filename miss-matches because of the case needed to be adjusted,
and as Cypress changed the API for I2C_I2C_ functions,
they added "timeout" which I think as a good move though,
modifications to I2C functions were required.
For that matter I added
#define I2C_TIMEOUT_MS 500
in the accelerometer.c.
Except these, project was built and worked fine with PSoC Creator v4.2 and CY8CKIT-044.
Although my wife has consumed more than half dozen of Coffee Makers,
I still have a lot to learn, and that's fun ;-)
Thank you very much!
ARTS_190627.cyprj.Archive01.zip 813.3 K
Thank you for your comment!
I created the ARTS Project mostly for educational purposes. So indeed there is a lot to learn from. I wrote my first RTOS in 1980 using PASCAL running on a Z80 Controlling a (real) concrete mixer systrem. I even had an RTOS for a PSoC1, but it left too few of the tight resources. Since Cypress decides to support Free RTOS I did not continue the ARTS Project.
Due to an Error in the Forum Software I cannot log in using my old account, so I needed to create a new one.