Real-time operating systems (RTOS) have found their way into nearly every embedded system. The problem though is that an RTOS can often complicate implementation, increase module coupling and make debugging a nightmare.

In this workshop, Jacob Beningo will walk attendees through RTOS implementation and debugging techniques that will help developers accelerate their design cycle and implement more robust and flexible design techniques. Attendees will learn hands-on about topics such as:

• How to initialize tasks
• How to properly set task stack size and monitor for stack overflows
• Decouple application code from the RTOS
• Properly protect shared resources
• Minimize response time for system events
• Perform application tracing and performance analysis

Additional topics and details about specifics boards and RTOS will be provided closer to the conference.

16:01:58	 From  Leandro Pérez : Hi again from Colombia :)
16:02:50	 From  Jón Hákon Richter : hello from Iceland!
16:03:44	 From  Michael Kirkhart : I remember developing for PIC microcontrollers in assembly
16:04:02	 From  Piotr Zdunek : Hello from Poland :)
16:04:03	 From  Grant : can anyone else see Jacob maximized on the screen? For me he is just showing up as an icon.
16:04:03	 From  Leandro Pérez : Yes I too... I started with those in 1999
16:04:17	 From  Daniel : Hello everybody from Germany! :)
16:04:35	 From  Scott K. : Change to speaker view @grant
16:04:50	 From  Grant : cool thanks!
16:04:57	 From  Bill Tilman - Abaco : Hello from Albuquerque, New Mexico
16:05:37	 From  Bhargav Shah : Hello from India 
16:06:24	 From  Lee Thalblum : Hi from New York City
16:07:03	 From  javi : trazalayzers for everyone!
16:07:05	 From  Peter Jamrozinski : What do you think about Seggers RTOS tools like SystemView?
16:07:06	 From  Bob Dowling : Hi from Albany, New York!
16:07:08	 From  Pulkit Gupta : Hi from The Netherlands :)
16:07:13	 From  Mikael Albertsson : Hi all, joining from Sweden here
16:07:37	 From  javi : Hi from Spain :)
16:07:38	 From  Marinna Martini : Hello from Cape Cod, MA
16:08:03	 From  Aldo Coronado : Hello from Guadalajara, Mexico
16:08:35	 From  Mike : what was that URL?
16:08:43	 From  Miehl : http://bit.ly/3fnT...
16:09:00	 From  Mike : Thanks!
16:09:06	 From  Piotr Zdunek : What is the most versatile and cost effective RTOS currently available on the market in your opinion?
16:09:08	 From  Miehl : The rest is missing
16:09:18	 From  Miehl : http://bit.ly/3fnT4cF
16:09:39	 From  Jason Cose : proxy blocked...
16:09:44	 From  Iain Chalmers   to   Stephane Boucher(Direct Message) : Stephane, I'm seeing a noticeable degradation in video quality compared to James session due to Jacob relying on his video feed to show the slides (and not sure how Zoom will like recording that?!). A screen share is likely to be higher quality.
16:09:51	 From  Miehl : https://www.dropbox.com/sh/ah1wal7f5m51svg/AAAOXQm5xqRUWna5cpCqC5C5a?dl=0
16:10:01	 From  Lee Thalblum : Piotr: FreeRTOS is very flexible and the price is (obviously) free.
16:10:04	 From  Frederic : dropbox blocked by firewall
16:10:35	 From  Lee Thalblum : I used it for the last 2+ years
16:11:00	 From  Jón Hákon Richter : What's your opinion on the Zephyr-RTOS?
16:11:19	 From  Leandro Pérez : I have used AWS FreeRTOS for the last 2 years too
16:11:22	 From  Piotr Zdunek : Lee: I like FreeRTOS, but I was wondering how it compares to other solutios like Zephyr, uOS, GreenHills etc.
16:11:41	 From  HarriR : Zephyr seems nice, although a bit linuxy
16:12:09	 From  Piotr Zdunek : I would say that's an advantage
16:12:12	 From  Lee Thalblum : I haven't used Zephyr, but as compared to uC/OS and Nucleus I found FreeRTOS very comparable
16:12:55	 From  Michael Kafarowski : Are many other people using VMs for Embedded development?
16:13:23	 From  Alessia Botta : Michael: Yes, I do
16:13:26	 From  Marko : Zephyr has a steep learning curve, but after realizing that you can move your code from one micro to another (plus that many drivers are available to you) you start to appreciate it
16:13:45	 From  Daniel : I use Docker for development, usually I don't use IDE.. I hope I won't be that hard :)
16:13:46	 From  Jón Hákon Richter : I've used qemu for raspberry pi
16:13:47	 From  Keith J : Yes
16:13:48	 From  Marinna Martini : yes
16:13:49	 From  javi : yes
16:13:50	 From  Roman Hvozd : yes
16:13:50	 From  Stefan Petersen : Yes
16:13:52	 From  Daniel : yes , I didn't have any problem
16:13:52	 From  Steve Wheeler : yes
16:13:54	 From  Michael Kirkhart : Yes
16:13:56	 From  Andrew : yes
16:13:56	 From  Mikael Albertsson : Yes
16:13:56	 From  barnberg : yes
16:13:57	 From  Jay : yup
16:13:58	 From  Carlos : yep
16:13:58	 From  Frederic : no
16:14:00	 From  Burak ŞEKER : waiting to download
16:14:32	 From  Derek Konigsberg : Downloaded, and imported into STM32CubeIDE.  Building it seems to depend on some external stuff I don't have.
16:15:32	 From  Marinna Martini : I ran an RTOS demo in Visual Studio - can I try this workshop code in that without hardware?
16:15:35	 From  Tim Michals : you have to download the STM32 library for the part
16:15:59	 From  Marko : Does anyone use VIM text editor for embedded projects?
16:16:01	 From  Derek Konigsberg : Its Segger stuff it complains about.
16:16:22	 From  barnberg : Marko: yes, several folks where I work us it.
16:16:24	 From  Stephane Boucher   to   Iain Chalmers(Direct Message) : I see what you mean.  I'll let Jacob know on the side, don't want to de-stabilize him too much.  But something to learn from for future sessions for sure.
16:16:42	 From  Derek Konigsberg : Actually, it very well could simply be Windows-vs-Linux Makefile assumptions. Probably not worth the time to debug right now.
16:16:53	 From  Gerhard : Marko: I am a terminal and Neovim user
16:17:04	 From  Iain Chalmers   to   Stephane Boucher(Direct Message) : Seems sensible. Thanks.
16:17:10	 From  Jay : vi plugin in VSCode
16:17:14	 From  Piotr Zdunek : vim ftw
16:17:43	 From  Marko : barnberg: nice to know, which micros are you programming, using?
16:18:04	 From  nicholas.dijkhoffz : Barnberg Hello!
16:18:13	 From  Marko : yes, vim + tmux is really awesome!
16:18:14	 From  barnberg : Nicholas!
16:18:36	 From  Carlos : the key word with Zephyr is "promise".  Not all promises are kept.  I've found that out over last year
16:18:46	 From  Leandro Pérez   to   Stephane Boucher(Direct Message) : I see the image in low resolution
16:18:47	 From  Stephen Roberts : The text in the video seems pretty blurry, am I the only one that sees this?
16:18:54	 From  Leandro Pérez : I too
16:18:59	 From  Carlos : nope, blurry
16:19:02	 From  Alessia Botta : Me too
16:19:03	 From  Scott K. : Blurry here, too.
16:19:07	 From  Piotr Zdunek : super blurry
16:19:19	 From  Gerhard : Yes, it’s very blurry
16:19:31	 From  Glenn : Yeah, Jacob's desktop resolution is very poor (a.k.a. blurry).
16:19:42	 From  Marko : Carlos: what did you found missing in the Zephyr?
16:20:43	 From  Kelly McClellan   to   Stephane Boucher(Direct Message) : The screen share is low resolution, very hard to read.
16:21:23	 From  Leandro Pérez : Thanks
16:21:24	 From  Rocco Brandi : zoom keeps disconnecting and reconnecting
16:21:31	 From  Piotr Zdunek : I need to try Zephyr
16:22:01	 From  Kelly McClellan   to   Stephane Boucher(Direct Message) : share screen with full screen view should be readable
16:22:08	 From  Bob Everson : Can't read the 'zoomed' text either.
16:22:10	 From  James A. Langbridge : If you know your way around CubeIDE, you can guess what is going on, but it might be complicated to follow exactly on the code later on
16:22:15	 From  AnnaB : zoomed text is still blurry
16:22:16	 From  Kelly McClellan   to   Stephane Boucher(Direct Message) : he won't have to zoom in 
16:22:42	 From  Daniel : yes
16:22:45	 From  AnnaB : And I think I'll likely get a headache from the blurriness
16:22:46	 From  Bruce Lueckenhoff : yes
16:22:47	 From  Stephen Roberts : Kinda
16:22:49	 From  Miehl : readable
16:22:49	 From  René Andrés Ayoroa : Barely
16:22:52	 From  Théophile Bornon : readable
16:22:52	 From  Kelly McClellan   to   Stephane Boucher(Direct Message) : I think the video window forces MPEG type compression, bad for text
16:22:53	 From  Iván GB : Even doing this it is a bit blurry :(
16:22:53	 From  Bob Everson : Nope
16:23:02	 From  James A. Langbridge : Text in explorer yes, the pin names, not so much
16:23:16	 From  Burak ŞEKER : Readable with a little imagination
16:23:29	 From  Jason Cose : Thankyou!
16:23:29	 From  barnberg : hot dog
16:23:30	 From  Alvaro Muro(Bilbao) : That's great
16:23:33	 From  Stephen Roberts : Wayyy better.  Very readable
16:23:34	 From  Burak ŞEKER : Now, perfect!!
16:23:39	 From  Leandro Pérez : perfect
16:23:39	 From  René Andrés Ayoroa : huge difference
16:23:41	 From  Michael Kafarowski : I can still see the original screen too
16:23:42	 From  Bob Everson : Much better.
16:23:43	 From  Iván GB : WOW!!!! This is another world
16:23:44	 From  Mike : Love it
16:23:46	 From  Keith J : whole screen clear...
16:23:48	 From  Iván GB : From 8 bits to 64
16:23:50	 From  Piotr Zdunek : maybe try dual screen sharing and put the video on the second screen?
16:23:55	 From  Stefan Petersen : No need for zooming in now
16:23:56	 From  Leandro Pérez : Could repeat the last steps?
16:24:05	 From  James A. Langbridge : Can you then open up a camera program to see your webcam so you can show the board and the blinkenlights?
16:24:09	 From  Mikael Albertsson : We have pretty much the same view as before, only super crisp =)
16:24:13	 From  Michael Kafarowski : Right when you switched to screenshare I could still see your slides and face
16:24:20	 From  Iain Chalmers : You can pin your webcam video to allow both at the same time too
16:24:33	 From  javi : we dont need to see the board, we will trust you if you say the led is blinking ;)
16:25:09	 From  Keith J : very legible... thank you
16:25:16	 From  i1A597358 : Looks good!
16:25:26	 From  James A. Langbridge : Thanks for the last minute changes Jacob!
16:25:33	 From  James G : Looks great now
16:25:46	 From  Jay : yes very nice
16:25:51	 From  Daniel : neat! 
16:26:02	 From  Piotr Zdunek : Zoom settings -> General -> Use dual monitors
16:27:03	 From  i1A597358 : Is the STMCube IDE, free?
16:27:08	 From  Michael Kafarowski : Yes
16:27:25	 From  i1A597358 : thanks!
16:27:42	 From  Michael Kafarowski : https://www.st.com/en/development-tools/stm32cubeide.html
16:27:46	 From  Michael Kafarowski : Just need an ST account
16:27:49	 From  James A. Langbridge : You just need to register on ST, then you can download STMCubeIDE and STMCubeMX free of charge, no code size limitation
16:28:38	 From  HarriR : Anyone have experience using Active Objects that Miro Samek talks about?
16:28:49	 From  Roman Hvozd : yes
16:29:15	 From  Roman Hvozd : I have
16:29:52	 From  HarriR : Do you feel like it's a nice approach?
16:30:00	 From  TEW : Can you share the workshop link again pease
16:30:07	 From  TEW : please
16:30:28	 From  Miehl : http://bit.ly/3fnT4cF

https://www.dropbox.com/sh/ah1wal7f5m51svg/AAAOXQm5xqRUWna5cpCqC5C5a?dl=0
16:30:51	 From  Roman Hvozd : yes, definitely :)
16:31:06	 From  James A. Langbridge : Jacob's calm in the face of a major presentation change, tools not behaving and all of those fun things is just legendary
16:31:57	 From  Keith J : FYI: ST-Link to Segger only works with the development board integrated link... not the stand-alone ST-Link debuggers
16:32:15	 From  Rocco Brandi : the file is not there
16:32:15	 From  Iván GB : Umh.. I cannot see that pdf
16:33:13	 From  AnnaB : I have it in the download
16:33:16	 From  AnnaB : yes
16:33:20	 From  Stephane Boucher : @James, haha this is not Jacob's first rodeo!
16:33:21	 From  Mikael Albertsson : I do
16:33:24	 From  Mike : i do
16:33:24	 From  AnnaB : I see both
16:33:31	 From  Michael Kafarowski : I see all three
16:33:34	 From  Aditya S : I see both
16:33:34	 From  TEW : I see all 3 in the files
16:33:38	 From  Rocco Brandi : the zip file doesn't have the exercise instruction
16:33:41	 From  paul.pervinkler : I saw/grabbed both
16:33:44	 From  FAIK SAGLAR : Filename is same but contents does not match. Only 6 pages.
16:34:02	 From  Keith J : Thank you Jacob!
16:34:54	 From  Rocco Brandi : yep it's there
16:35:41	 From  Miehl : Do you see his screen?
16:35:45	 From  Gerhard : No
16:35:45	 From  Amilcar : I no longer see your screen
16:35:47	 From  Jay : share?
16:39:05	 From  Michael Kirkhart : Configuration array - old, but very handy trick - used many times
16:40:11	 From  Hitesh Rai : I like this! I have been doing this, but I use .def file for all the RTOS task thing
16:41:01	 From  Hitesh Rai : And then you can extract whatever you need from the .def file
16:41:27	 From  Leandro Pérez : Very organized way
16:43:29	 From  Leandro Pérez : Yes I defined it in that way... all configuration in only point
16:43:38	 From  Jeremy Erdmann : Jacob, can you weigh in on the pros-cons of (A) having tasks share the same priority? and (B) using the CMSIS OS2 API vs. the FreeRTOS API for task creation, etc.
16:44:07	 From  Nathan Jones : Just joining. Is there a link to a workspace or project files that I missed?
16:44:23	 From  Hitesh Rai : https://www.dropbox.com/sh/ah1wal7f5m51svg/AAAOXQm5xqRUWna5cpCqC5C5a?dl=0
16:44:25	 From  Michael Kirkhart : There is a Dropbox link in the chat
16:44:28	 From  SS : https://www.dropbox.com/sh/ah1wal7f5m51svg/AAAOXQm5xqRUWna5cpCqC5C5a?dl=0
16:44:52	 From  paul.pervinkler : How would you recommend handling tasks launched by other tasks? -ex. a task to manage an HTTP connection launched by an HTTP service task that manages control over connections
16:45:17	 From  Keith J : Love the organization... unfortunately especially with STM32IDE using C++ with tasks is hard
16:45:52	 From  Keith J : and creates some messy files and code... but is doable
16:46:06	 From  Carlos : Are mutexes and semaphores dynamically allocated in FreeRTOS?
16:47:32	 From  TEW : I agree with Keith J. 

I'm curious about why you opted to use CMSIS vs. FreeRTOS or other RTOS paradigms. Like are there size and/or performance ramifications. 
16:48:44	 From  Peter Jamrozinski : What is CMSIS OS2?
16:48:53	 From  Jeremy Erdmann : Jacob, can you comment on the proper configuration of processor interrupts with FreeRTOS?  I've heard differing information on how to configure SysTick ISR priority vs. the ST HAL tick.  Also possibly things like PendSV and others.
16:48:57	 From  Mikael Albertsson : Mutexes at least can be either dynamically allocated or statically dito
16:49:09	 From  Derek Konigsberg : CMSIS is an ARM abstraction layer
16:49:37	 From  Mikael Albertsson : Using xSemaphoreCreateMutex() and xSemaphoreCreateMutexStatic()
16:49:53	 From  Peter Jamrozinski : i'm familiar with the ARM abstraction, just didn't know what the OS2 stuff was -- seems like another layer of abstraction specifically for RTOS hooks?
16:50:20	 From  Jeremy Overesch : It looks like that only allows dynamic memory
16:50:33	 From  Derek Konigsberg : Yeah, CMSIS-OS2 abstracts the RTOS functions, and does some extra boilerplate stuff around them.
16:51:01	 From  Jonny : Jeremy - there are options for using static memory will it too
16:51:12	 From  Peter Jamrozinski : ah, makes sense, thanks @Derek
16:51:38	 From  i1A597358 : no hardware to try it out with. I will order then try it out.
16:51:47	 From  Jeremy Overesch : Jonny - Do you have a reference? In the function call he stated, it didn't show a way to supply the stack.
16:53:08	 From  HarriR : https://www.freertos.org/xTaskCreateStatic.html
16:53:28	 From  Jonny : Sounds like maybe he's about to touch on it, but as part of the config struct for the task you can actually specify a memory address. So one option is to just give that a static array for it to use
16:53:49	 From  Jeremy Overesch : That's in freertos, but not the CMSIS-OS2
16:54:37	 From  Derek Konigsberg : I'm wondering about using tasks for handling operations that aren't long-running, and are only started in response to some event from another task. (and might be paramaterized by data coming from that task)
16:54:49	 From  Jonny : Have a look here: https://www.keil.com/pack/doc/CMSIS/RTOS2/html/group__CMSIS__RTOS__ThreadMgmt.html#structosThreadAttr__t
16:55:11	 From  Tara W : For prod level apps, I typically specify the memory address and yes that is in FreeRTOS.  

So that is why I am curious about why to use the CMSIS abstraction vs. using the base level RTOS constructs.  What are the size/performance ramifications if any of using CMSIS vs RTOS constructs. 
16:55:23	 From  mzaleski : Select the project in LEFT pane
16:55:35	 From  Mikhail Skobov : > why to use the CMSIS abstraction vs. using the base level RTOS constructs
16:55:45	 From  Mikhail Skobov : It’s portable across different MCUs and OSes
16:56:15	 From  Tara W : Yes I understand the benefits of CMSIS but my concern or question is more around the tradeoffs. 
16:56:44	 From  Mikhail Skobov : It adds some code size for the port, but not significant
16:57:02	 From  Tara W : Thanks Mikhail. Any performance hits? 
16:57:05	 From  Alvaro Muro(Bilbao) : Thanks Jacob, I need to leave, will watch the video tomorrow!
16:57:23	 From  Jeremy Erdmann : One tradeoff I've found is the API is limited.  FreeRTOS timers allow more than the CMSIS OS2 does
16:58:21	 From  Tara W : Thanks Jeremy ...didn't think about that, it's a good call out. 
16:59:27	 From  Nathan Jones : Jacob, do you use a custom printf implementation or the default?
16:59:28	 From  Mikhail Skobov : Yep, +1 Jeremy. E.g. peek is missing in cmsis queue API, but exists in freertos. Performance implications are limited
16:59:49	 From  Peter Jamrozinski : @Jacob, printf is nice for status -- but what if the task that failed was a critical task? Printing to a terminal might constitute as a silent failure in a situation where you'd want to stop/reset/restart the system.
17:00:10	 From  S : What do you mean by a weak write in printf?
17:00:48	 From  Mikael Albertsson : @Nathan, that works with the standard printf, it uses a weakly defined _write to do the low lever writing (as Jacob mentioned just now)
17:00:51	 From  Tara W : Thanks guys (Mikhail & Jeremy), that really helps. We work on 2 different RTOS and typically use the RTOS constructs vs. CMSIS but were considering whether we should opt for CMSIS. 
17:01:25	 From  Mikael Albertsson : If a symbol is weakly defined in a library you're linking against and you define the same symbol, your implementation will automatically take precedence
17:02:19	 From  Rob Meades : Absolutely agree on local _write() override and using ITM to get debug through SWO but I've found that SWO support is TERRIBLE in almost every development environment (even in OpenOCD), JLink being the best of a bad bunch.  Any comment?
17:03:21	 From  Jeremy Erdmann : I was writing a generic Timer implementation for a reusable software library capable supporting BareMetal and different OSes generically (is a C++ class inheriting from an abstract base class).  The API I spec'd in my abstract base class didn't have full support by the CMSIS, so I opted to go FreeRTOS API route instead of CMSIS.  I can always create another implementation for a different OS, should I choose.
17:03:49	 From  Rob Meades : ;D
17:04:24	 From  Jay : "interesting"
17:04:26	 From  Nathan Jones : @Mikael: Right, but don't many people consider the "printf" function to be too large for embedded systems? I've heard a popular alternative is this one (https://github.com/mpaland/printf), from [mpaland].
17:04:28	 From  Daniel : :D
17:05:01	 From  Rob Meades : printf() with no floats is usually bearable I find.
17:05:13	 From  Leandro Pérez : I have implemented in my project a code like lo4j but for microcontroller... I assigned the log level in each message... and in a parameter I defined the global loger level
17:05:30	 From  Michael Kirkhart : At this point, maybe single stepping would be the right thing to do?
17:05:37	 From  Mikael Albertsson : @Nathan yes, it is fairly big, you can configure what level of support to add in though, I think by default on STM32 projects, floats are disabled, making it quite a bit smaller
17:05:58	 From  Nathan Jones : Oh, neat! Where do I configure that? In CubeIDE?
17:07:07	 From  Tara W : @Jeremy that's interesting issue/challenge. In that case it seems that while CMSIS It reduces the amount of rewrite but you can't naturally execute across OS without changes. 
17:07:40	 From  Mikael Albertsson : Not sure if you can config there, I'm looking at a makefile here, we added -u _printf_float to the linker to enable floating point support in our project
17:08:11	 From  Keith J : Is Tracealyzer software or hardware/software?
17:08:20	 From  Daniel : software
17:08:31	 From  Daniel : it's uses a pointer to save the "trace"
17:08:32	 From  Keith J : thx
17:08:34	 From  Tara W : I missed it what board did he say? L4+? 
17:08:57	 From  Hitesh Rai : My guess is it is software, but it will some hardware for it to run. like SWD target device
17:09:02	 From  Alessia Botta : Does anyone has experience with TraceAnalyzer? How does it compare with Segger System View?
17:09:43	 From  Daniel : in theory you can a have a precise overview of rtos behavior
17:12:12	 From  Daniel : what are the units? 
17:12:35	 From  Jay : bytes?
17:12:56	 From  Keith J : Ok Tracealyzer is similar to uC/Probe
17:13:00	 From  Daniel : dunno \o.o/ 
17:13:00	 From  Mikael Albertsson : Btw, I may be wrong, but I think the overrideable _write and turning on/off floating point using that linker option may be newlib printf() specific
17:13:13	 From  Hitesh Rai : Is there a trigger that we can set on Tracealyzer?
17:13:29	 From  rg : Not used Tracealyzer but System View is free (ish), though looks like it has less views
17:13:45	 From  Daniel : how's the tracealyzer overhead?  memory usage?  performance? 
17:13:45	 From  Jonny : You can get a lot of this info in uvision directly too, although I'm sure tracealyzer has a lot more in-depth information. But in theory all the information is there to look at without additional programs 
17:13:59	 From  Keith J : Sorry Systemview is the software that works with uC/Probe
17:14:02	 From  Rob Meades : Not sure you _can_ turn off float in anything (certainly you can't in GCC), you just don't use it and it doesn't get linked.
17:14:49	 From  Alessia Botta : @rc: I tried System View, but I had stability issues. It was stopping every few minutes due to invalid packet. Thus, I was wondering if Tracealyzer was working better
17:14:51	 From  SS : Dangling..
17:15:01	 From  Rob Meades : ...provided, of course, you don't bring in any libraries that already have floating point references.
17:15:26	 From  Leandro Pérez : I have a question.... There 2 ways to start with FreeRTOS for STM32.... 1) Use directly from STM32 IDE Cube... 2) Download the code from the AWS Console and integrate that... What is the best way in these two options?
17:15:54	 From  Tara W : Leandro: are you looking for Amazon FreeRTOS or FreeRTOS OSS
17:16:20	 From  Jonny : @Alessia it sounds like maybe your trace data just isn't keeping up/keeping synchronized? At which point it wouldn't matter that viewer program you use
17:16:22	 From  Leandro Pérez : AWS FreeRTOS… with the AWS libraries added
17:16:42	 From  Keith J : Tracealyzer does look pretty slick
17:17:09	 From  SS : Yes it does for sure.
17:17:54	 From  Steve Wheeler : I haven’t used FreeRTOS much, but instead of having tasks create other tasks, what I’ve done in the past is to set up the tasks at initialization time, and just enable/disable tasks as required.
17:18:17	 From  Derek Konigsberg : FreeRTOS does not have a task "join" function, which makes clean shorter-lived tasks a bit more difficult.
17:18:39	 From  Carlos : Thank you!
17:20:02	 From  Jonny : @Derek - really? It's in the cmsis-rtos2 api and I thought freertos had an option for that API
17:20:17	 From  Abdi : Does Percipio work with Stlink?
17:20:29	 From  Leandro Pérez : Thanks @Jacob
17:21:18	 From  Leandro Pérez : Is possible connect J-Link to PIC32 to use Segger System View?
17:22:33	 From  Tara W : Nice ....I didn't know it was free now!! Great to know
17:22:52	 From  Alessia Botta : Thanks @Jacob!
17:24:07	 From  Daniel : yes, it works. I tried it yesterday
17:27:12	 From  Tara W : Leandro: Micrium https://www.silabs.com/developers/micrium-os
17:29:11	 From  Gerhard : I would initialize the table with [SYSTEM_ARMED] = {…},
17:29:20	 From  Troy : thanks for pointing out the state machine very cool
17:30:05	 From  Michael Kafarowski : Sorry, I think I missed it, what are the units on the Event Signal Plot?
17:30:20	 From  Michael Kafarowski : 0, 1, 2, 3 on the y axis
17:30:20	 From  Gerhard : Just integer
17:30:26	 From  Gerhard : The state
17:30:55	 From  Michael Kafarowski : Oh, that value comes from the code and is passed to Tracealyzer?
17:31:13	 From  Michael Kafarowski : Okay I see now
17:31:22	 From  Michael Kafarowski : Thanks @Gerhard!
17:33:37	 From  Douglas Renaux - UTFPR - Brazil : Hi, does traceanalyzer work for other OSes, such as CMSIS or Azure ThreadX ? What cost range are we looking at for licenses of Traceanalyzer ?
17:34:16	 From  Mike : https://sites.fastspring.com/percepio/product/tracealyzer
17:34:32	 From  Steve Wheeler : I think it’s about $2500, and they have different versions for each RTOS they support,
17:35:39	 From  Daniel : it's around 20 development hours.  it may worth it :) 
17:37:29	 From  Tara W : @Douglas it does work with other OSes ...nevermind :) I see Mike provided link. (should've scroll down) 
17:37:31	 From  javi : Does traceanalyzer run in Linux?
17:37:59	 From  Tara W : Yes Javi, has Linux support
17:38:02	 From  Daniel : yes, it does, but you should do some softlinks to make it work smoth
17:38:06	 From  Daniel : smooth
17:38:13	 From  javi : ok, thanks
17:39:50	 From  Douglas Renaux - UTFPR - Brazil : thanks guys
17:42:11	 From  Carlos : Marko, sorry I missed your question:  for example, the SEGGER support they claimed to have.  Or...printing floats was broken...or...
17:42:55	 From  Mikael Albertsson : And I finally found what I was looking for with the printf, default disabled floating point support is a newlib-nano feature, grep for _printf_float in  share/doc/gcc-arm-none-eabi/readme.txt in your gcc-arm-none-eabi toolchain.
17:44:08	 From  Troy : That was awesome! thanks
17:44:21	 From  Jakub Telatnik : The tracealyzer demo was awesome. Can you do similar things with SystemView? 
17:44:29	 From  Stefan Petersen : Thanks!
17:45:38	 From  David Kanceruk : What is the difference between a mutex and a semaphore?
17:45:39	 From  Daniel : Hey Jacob, do you know the overhead of tracelyzer?  memory footprint and performance influence.  
17:45:42	 From  Raul Pando : Presumably, since the communication with Tracealyzer is done via Segger the overhead on the MCU is (close to) zero?
17:45:57	 From  mzaleski : What is the reason for swapping out ST Link for J-Link?
17:46:10	 From  Daniel : A Mutex is different than a semaphore as it is a locking mechanism while a semaphore is a signalling mechanism. A binary semaphore can be used as a Mutex but a Mutex can never be used as a semaphore
17:46:25	 From  Daniel : to be able to use RTT 
17:46:25	 From  Jakub Telatnik : Yup thanks!
17:46:28	 From  Carlos : Jakob, can you go a bit into what Thread awareness means (in an IDE)?
17:47:25	 From  Daniel : Hey Jacob, do you know the overhead of tracelyzer?  memory footprint and performance influence.  ?

17:47:46	 From  Hariharan G : Binary Semaphore is not a mutex. There is no ownership concept in semaphores
17:47:47	 From  Carlos : ST Link doesn't have support for the RTT streaming, which tools like this rely on.
17:49:19	 From  Rob Meades : I've found that SWO support (which I guess the bandwidth requirements of Tracealyzer relies on) is TERRIBLE in almost every development environment (even in OpenOCD), JLink being the best of a bad bunch. Have I just been unlucky?
17:49:48	 From  Daniel : memory map? 
17:49:51	 From  Iain Chalmers : @David Kanceruk I would highly recommend Hands-On RTOS with Microcontrollers by Brian Amos for a good intro to RTOSs. Easy read, good examples and I was quite happy to just work through it start to finish:

https://www.amazon.co.uk/Hands-RTOS-Microcontrollers-Building-real-time/dp/1838826734
17:50:01	 From  Michael Kafarowski : What could be a good way to pass large amounts of data between tasks? E.g. processed sensor data to a UI. I've been using a queue with a big union to pass all the different types of data or structs I intend to send, but I'm wondering if there's a better way. Thanks!
17:50:12	 From  Daniel : cool thanks!
17:51:43	 From  Mikael Albertsson : @Jacob, if it's streaming out the data at a very low priority, have you seen what type of behavior you can expect with the tracing data on a system that is heavily loaded with processing?
17:51:51	 From  Miehl : @Carlos: You can update the ST-LINK to behave as a SEGGER J-Link: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

See page 25 of "EOC21_RTOS_Workshop_Exercises.pdf".
17:52:07	 From  Michael Kafarowski : Other -> FreeRTOS
17:53:52	 From  Michael Kirkhart : @Miehl: Thanks for the link.  I did not know that was possible.
17:54:26	 From  Carlos : Yes, I was trying to answer why you would do that.
17:54:35	 From  Michael Kafarowski : I think you have to register the semaphore for it to be shown in the semaphore page, same for queues
17:54:41	 From  Michael Kafarowski : CMSIS OS2 does it automatically I think
17:55:22	 From  Carlos : because someone asked "What is the reason for swapping out ST Link for J-Link?"
17:55:23	 From  Michael Kirkhart : Yes, the good old "priority inversion" problem.
17:55:28	 From  Stephane Boucher   to   Jacob Beningo(Direct Message) : There's a raised hand?  Not sure if Michael has a question...
17:55:39	 From  Leandro Pérez : Yes
17:56:02	 From  Tara W : Michael: I was just about to type that :)
17:56:38	 From  dayolawa : What about ETM support?
17:56:39	 From  Rob Meades : @Jacob thanks!
17:58:30	 From  Leandro Pérez : All must write our experiences developing embedded systems... all could write the best book ever... lol
17:58:55	 From  Daniel : usually memory is a start point , and then reading the dissambler to actually confirm if there is a buffer overflow
18:00:20	 From  Leandro Pérez : In which tool could I document all the queues, semaphores and tasks used?
18:00:34	 From  Leandro Pérez : like an architecture diagram
18:01:55	 From  Leandro Pérez : where I can see dependencies and the relations between them
18:01:57	 From  James A. Langbridge : Well, I might be a baremetal person myself, but this talk was awesome, and makes me want to use RTOS a little bit more. Thanks, Jacob!
18:02:47	 From  Michael Kafarowski : Thanks for the talk Jacob!
18:02:47	 From  Troy : Michael thanks for sharing that great solution
18:02:56	 From  Keith J : Awesome info Jacob - THANK YOU!!!
18:02:58	 From  Michael Kirkhart : No problem
18:03:09	 From  Leandro Pérez : Thanks @Jacob
18:03:19	 From  Tara W : +1 to Troy, great callout Michael. 
18:03:29	 From  Keith J : Good alternative Michael!
18:03:31	 From  HarriR : nice tip Michael
18:03:42	 From  HarriR : Thanks Jacob!
18:03:59	 From  Gerhard : Thanks!
18:04:01	 From  Peter Jamrozinski : Thank you!
18:04:04	 From  Rob Meades : Thank you!
18:04:05	 From  FAIK SAGLAR : Appreciate all :)
18:04:06	 From  Nikola Jovanovic : great talk - thanks JB
18:04:11	 From  Rocco Brandi : thank you very much!
18:04:12	 From  Mark : thanks
18:04:12	 From  Mikael Albertsson : Thanks Jacob, good presentation!
18:04:13	 From  Aditya S : Thanks Jacob
18:04:15	 From  Yuriy Kozhynov : Many thanks!!!
18:04:15	 From  Steve Wheeler : Great talk! Thanks so much.
18:04:17	 From  mzaleski : Great talk!
18:04:21	 From  Marinna Martini : Thanks!
18:04:23	 From  René Andrés Ayoroa : Thank you Jacob
18:04:26	 From  lavender : Thanks!
18:04:26	 From  Frederic : Thanks a lot!
18:04:30	 From  Tara W : Thanks Jacob!! Great talk
18:04:33	 From  mm047 : Thanks!!
18:04:38	 From  Lee Thalblum : Great presentation. Thanks Jacob
18:04:40	 From  Jay : thanks!
18:04:43	 From  Christopher Long : Thank you Jacob. Great talk!
18:04:47	 From  Daniel Fu : Thank you Jacob!
18:04:52	 From  James G : thank you!
18:04:55	 From  javi : thanks!