Embedded - 274: Swiss Knife of Embedded Systems

Episode Date: January 18, 2019

Ivan Kravets (@ikravets)  spoke with us about PlatformIO (@PlatformIO_Org), IDEs, embedded libraries, and RISC-V. PlatformIO is an editor, an integrated development environment with debugging and unit testing, and/or a library index. Its goal is to make embedded development easier and more consistent across host operating systems and development hardware. It is also a .org because the goal is to make all of this open source and free to engineers. Ivan Kravets is the founder of PlatformIO.org. Personal site, Github, LinkedIn, and a neat interview. He recommends seeing the Dnieper River if you are in his area. Ivan recently attended the RISC-V Summit. RISC-V is an open source processor core (like ARM but open source). SiFive was mentioned as one of the RISC-V processor vendors. RISC-V is being used extensively in research. Western Digital is planning to develop RISC-V based controllers. And MIPS recently joined RISC-V.

Welcome to Embedded. I'm Alicia White alongside Christopher White. And this week we are going to answer some questions. We're going to start with one. Platformio, Platformio. What for art thou, Platformio? I believe it's preferred to be Platform.io. Ivan Kravitz is here to tell us exactly what Platform.io is.

And we're going to talk about compilers, boards, and platforms. Hi, Ivan. Thanks for joining us. Hi, Kyle. Could you tell us about yourself as though we met at a conference? Sure. My name is Ivan, and I am the founder of Platform.io. I started it as a hobby project in 2014. However, for the last three years, it's my full-time job, and I am so happy. Today, I am responsible for all aspects around platform.io

the business, marketing, architecting and even technical support if someone needs it. As for my hobbies, I think the favorite is the skin and engineer. Also in the spare time I like to play piano and time to time compose music when inspiration comes to me. Actually, some of my works are published in my personal blog, and you can visit it by iKravet.com. And yes, I am from Ukraine. Okay, well, then we are definitely going to talk about what exactly it is, because it's more than an IDE. But before that, we're going to do lightning round, where we ask you short questions, and we want short answers. And if we're behaving ourselves, we won't ask you how and why and all of the other things.

Okay. What's your favorite animal? It's a dog, but I don't have it. What is your favorite microcontroller? It's a difficult question because we support around 500, and it's not good if I say favorite. It's like an advertisement for some architecture. But I have different microcontrollers.

Do you want to choose two or three? I mean, out of 500, you have to have some that are better in your mind than others. Yes. I think it's Texas Instruments because I have this Air Launchpad board, and it works for four years uptime for this board, no any issues.

I think this is great for the enterprise product. Which board was that? It's Launchpad, Texas Instruments. Launchpad. Okay, yeah. If you had to bring a toolbox and get lost on a desert island, what would be in it? I don't know. A satellite phone.

Even don't know. All right. What is the worst thing about the Arduino IDE? So it's really the processing ID, not the Arduino IDE. It's the label. But what is really the processing idea, not the Arduino idea, the label. But what is really great is that

this platform allows different people, not only for the beginners, for the students. And I think that we should say a big thank you for the authors of this platform. I mean, like Hernando Barragan, who did his research around

this platform. If one were to visit Kiev, what should they see first? Nice question. I think you should go to other rivers, like the Dnipro River. It's very nice. You have some streets around this. But you need more than one day.

Where is it we should go? I didn't quite get it. So we have the river named Dnipro. This river splits our city into left and right parts. It's very interesting because there are a lot of

nice views from the different points. But also there are a lot of nice views from the different points but also we have a lot of museums chores and good good also we have really good national food like uchin in ukraine uh oh he's talking me into it. Yeah. You're welcome. Do you have a tip everyone should know? So I think it's classic tip, like a kiss. You know, this kiss principle, keep it simple, stupid. And I use this tip or principle every time I try to do everything as simple as much as I can. That's a good one. So Platform.io, getting away from lightning round,

how do you describe it to people who have never heard of it? Yes. So in Ukraine, I call it like Platformio. Oh, you do call it Platformio. No, no, it's okay. I mean, like, luckily, we call it like Platformio, but normally it may be it Platform.io. No, no, it's okay. I mean, like, locally, we call it, like, Platform.io. But normally, it maybe should be Platform.io. But what I really don't like is when people split platform and io.io.

Because there is a separate site, platform.io. It's not our website. It's really a mistake. And so, what is Platform.io? Like in a nutshell, it's maybe like the Swiss knife for embedded development because you can just enter to our ecosystem and you will receive everything. What do you need?

This is build system, multi-platform build system, library management with dependencies, semantic versioning, built-in integration with continuous integration services. Of course, debugging, unit testing, like this. That's a lot. I mean, it's almost overwhelming a lot. Yes, but I think the key feature of the platform IO, or it's better to say

this is the main philosophy of the platform IO, is that we don't force our customers to use a specific operating system or idea. This is really why we are totally opposite to this embedded market. Because we allow our users to decide the combination from the operating system and IDE. So for someone who maybe is used to proprietary development systems like IAR,

would you say that Platform.io is kind of, okay, this is the open-source version of IAR, or is it something more? So it depends what we will try to compare because IUR is not only the idea. So we have the editor, yes, like editor within the IUR and we have the compiler. And I think that the main benefits of IUR is their compiler because it's really good optimization. But if we talk about the platform IOU, we use HTC, we use free and open source toolchains for code compiling. And again, I.O.R. works only on Windows. And if you back again to the platform I.O., you can use Windows Mac, Linux, FreeBSD, and even Raspberry Pi or similar car sites PC because Platform.io is written in Python.

It's pure Python implementation. And we don't have any dependencies to the operating system. Just where the Python works, Platform.io works too. It's very easy. It's fully open source, free. One of the other things that IAR has is the ability to work with many microcontrollers and to provide some libraries related to those microcontrollers, CMSIS and hardware abstraction layers. Platform.io has some of that as well, right?

Yes, but I think it's better to explain from the other side so the rice platform or your core this is like an engine which consists from the build system library dependency things package management and there is separate site called platform io development platform that is called Platform.io Development Platform. That is really where a silicon vendor or software provider will describe Platform.io core, how to build source code, how to do uploading, how to do debugging. So, and I mean that silicon vendor are responsible to provide the things

like frameworks which you described before and things related to the tool chains and specific build flags and other things because platform.io has decentralized architectures and you can create the multiple different development platforms but in case for example with IR you can do that you just platforms. But in case, for example, with IAR, you can't do that. You just should follow their rules and use only what they provide you. Because it's a totally closed source. There is no source code for the IAR. You just need to use what they provide you.

Oh, yeah. And we're picking on IAR. But any of the closed source ones is what we're sort of comparing to Kyle and whatnot. But with those, you get a series of checkboxes. As you start a new project, you get a flow and you don't have to make a lot of decisions. Well, yes. You're guided through the decisions you got you're guided through the decisions with your handheld does platformio have something along those lines yes i i think we have a little a little bit different workflow because for example if you start project with IR, you start it from the microcontroller.

Yes, you select the family, you select the microcontroller. But in case with the platform, you select the board. This is really maybe the first hour issue, which we should fix soon. And we have the feature request in our repository on the github like to allow the star project for the micro control because today we support around 600 different boards and sometimes it's not easy to do some development if we don't support this board. For example, you have development board on your table based on some STMicro chip, yes, but in

production you prefer to use a little bit different chip and there is no development board for this chip, like Nucleo board or other board. And there are some tricky to work with the platform. But, I mean, for example, if you would like to use this Arduino or ARM-based framework, but if you are good with low-level like STM32Cube, there is no problem. Okay.

If I was an Arduino developer, i was new at doing development and i had uh a board say uh an esp32 board because those are so very popular and yet the arduino processing interface for them is at best how How do I get started with Platform.io? Actually, it's very easy because if you open our Platform.io home, this is addition to the ideas which we support. It's our separate component. And there is the button called Import Arduino Project. You will just select the folder where is your sketch for the Arduino. You press import, and you will receive a totally ready project for the platform I own. Because in 99% of Arduino projects, there is just one file, one sketch file.

It's very easy to import or manually to copy this file to the source project folder in the platform. But then the Arduino ecosystem has a lot more to it. One of the reasons I don't usually want it for clients is because there are many hidden files and you can't, I mean, set up and loop get called by a main somewhere else. Do you provide a way to export the processing hidden internals? So, you know, so the first, you know, is it? But that's already, you know, I use this own build system. And it means that you can't, you can't control their build flow.

This is the, this is the big problem because you can't modify any build flags, you can't pass some extra macros if you need. This is why we see a lot of instruction by library developers where they explain that you should go to the Arduino some internal files and edit the source directly. But if we talk about Platform.io, so we have different application interfaces where you are able to control whole build process. If you need to pass some extra flags you will just go to the platform.ini configuration file this is really the main file and you can pass extra extra flags but if you prefer for example to switch to the different tool chain or you prefer to change build to change build logic or to switch totally to different upload tools, you can go to the development platform

which I mentioned before for the AVR and you can modify our source code or you can use advanced scripting based on Python. And with the platform I.O., you are able to control the whole process. If you are a beginner, it will look for you not more complicated like Arduino, but the same. If you need more advanced control, we are ready to provide you at any level.

Sometimes when people are switching from the Arduino ecosystem to a more professional one, I recommend Embed because they have a large support library and they have many processors and development boards that they support. When should I recommend Platformio? Is it instead of Embed? Is it after Embed? How do you compare yes i think that the big problem that is like you mentioned i recommend for next for example next year we will have yet another platform or framework and you will try to say yet we again recommend and every time your customer they change

environment every time they lost time to learn new environment new instruments that is actually what they will do if they try to switch from Arduino to the embed because in case with the Arduino they have their IDE it's very easy but if they move to the arm embed they have just a few options so this is their online compiler or you need to install the command line tool a lot of things you need to pre-install manually manage tool change and a lot of complicated things but again if you back to the platform.io if someone today uses arduino it's very easy to switch to the to the arm embed you will need just to change one line in our configuration file you will just change framework equal embed instead of framework equal arduino

and after that platform will automatically understand what to do with your project. It will automatically install the latest RMBAT framework. It will automatically use proper tool chain. It will automatically use proper upload tools. So this is very good because you will keep the same development environment. You don't need to switch to new IDE because you will decide what to use.

If you prefer to do that from the Veeam or Remix, from the command line, you will use the same workflow for Arduino or for ARM embed. And even again, if you try to switch to the STM32Cube or a real-time operating system, you will keep the same workflow. You also have an IDE, though.

Yes, that is actually why people mostly think that Platform.io is this IDE. If we back again to the Platform.io history, like four years ago, starting from 14 years up to 16, we didn't have our own idea because Platform.io was just Platform.io core, just command line 2. But we had a huge problem that people don't, I mean, like not all people would like to install separately platform.io core and after that run some command like platform.io init type of the IDE and press enter after that you go to your IDE we support today around 10 different ideas you press file import project could be Eclipse, Qt different ideas and this is really the big problem.

And that is why we started a work on the official extensions for the different ideas. So the first experimental project was Atom by GitHub. Why we used Atom? Because it was very easy for us to create this extension because I forget to mention that I have a big, not big, maybe huge experience with web development because I am a web developer in the past. And embedded, this is my hobby, or it's better to say it was a hobby before the platform I own. And now this is my main job but I am not electronic engineer and I don't have electronic education this is actually a hobby which was converted to the full-time work and again if you back to my history with the web development I have

some experience and just I spent I don't remember I spent one week just five or six days and i created the first first version of extension for the atom and the same for the visual studio code just a few days and we have this extension but what we want really to do today or it's better to say that our main goal is to have official extensions for the most popular ideas because it's very easy to get started with Platform.io when you will just do three steps. First, you install your favorite idea. Second, you navigate to the extension or package stores of your idea and so you type Platform.io IDE, press enter, install this extension, restart your IDE,

and you receive a featured IDE. That's actually what you will receive with the Atom or Visual Studio Code today. But again, we just do that just to eliminate this barrier when people want to try to work with the Platform.io. Working with the Platform.io means you get access to libraries and header files,

register files, and hardware abstraction layers. But that also means you support, you said, 500 processors and many libraries and boards and IDEs. How do you manage the complexity of all of that? It's very busy. I think so. So I think it's good to explain in a nutshell the architecture of the Platform.io. So, there is the first level, like bottom level. There is development platform, again, where we explain and describe Platform.io build system,

how to build the source code of the framework, not only of the project. That is actually where we have the issues with the libraries. I mean, not third-party libraries, but libraries related to the framework. Because, for example, if we have Arduino framework, we have some built-in libraries in this framework. The same if we talk with arm-embed, we have some libraries inside this framework. It could be a real-time operating system,

it could be networking libraries. And if we add support for some version of the framework like Arduino, R-Embed or other framework, we explain using the Python scripting language, we explain our build system, how to build this framework and its library. But if you later in your project include some header files from one of these libraries, our Platform.io build system and its library dependency finder will automatically find this library, include this library into the build process, build it and link it on the final stage. I mean that you don't need to manually control these libraries or provide things how to build these libraries. Of course you can turn off this feature but it's enabled by default in the platform here. You will also see very nice

dependency graph where you will see how your project depends on different libraries you will see which version of the libraries will be used in the build process it's very cool but if we go to the second level the level where there is Serpati libraries the libraries which you can install from our platform of library registry, like libraries from the community. In this case, we are not responsible for the source code and for the build process, but we introduced to our community the manifest file called library.json where you can also explain or is better to say instruct our build system how to build your library if you don't do that your manifest is empty or just you you just specify the name of the library and not build things, we will try to automatically recognize the type of your library,

or this is Arduino library, or this is RMBAT library, or this is Expressive IDF component. And after that, if we understand the type of your library, we automatically try to build this library in the standards provided by the vendor of the software. For example, you know that there are some requirements have to build the Arduino library. There is also a lot of things have to build our embed library because we also have a huge registry.

And they have extra manifests, for example, in case we are in Mbatt, they have own manifests like mbatt.json, mbattup.json, where users can tune some things related to the Mbatt operating system. And, of course, we also follow these requirements and parse these files and use this in the build and the final build process okay so we have a layer that has the libraries that are from the i want to say vendors but sort of from the vendors sort of from the compiler makers um and then we have a library that is from your library index where people can post their own libraries. What about debuggers?

How do you decide what to support and how do you integrate with the debuggers? Is it more like embed where everything is printf, or can I step through my code? So, yes, you can do serial printing, like printing debugging to the console. It's not a problem. It's actually what people do with Arduino IDE or similar project. But we have

platform.io unified debugger, which we introduced one year ago. And we call it like one-click debugger, because it's really unique debugger engine in the market, because you don't need to specify or customize any settings per your project and per your debug probe. We follow the same, or better to say, we keep the same principle and the same philosophy within the Platform.io where I will just explain Platform.io what is your board, what is your framework, what is your development platform and what is your debug probe. For example, if you have project, so let's imagine we have some project based on this Sprycev or Sprycev32 which you mentioned before and now you can use different debugging

props yes you can use some ESP proc or you can use OddWires their debugger and within Platform.io you will just specify in Platform.io.ni file debug underscore to equal and the name of the probe. After that, our engine automatically understands how to debug your board. We know which debugging server to start. We know which initial commands we should pass to debug server because it's very between development platforms. For example, if you go to the ARM-based development platforms, there are a lot of different debugging interfaces,

like DAPLINK, SIMCIS, DAP. You can use Blackmagic Probe, where there is no debugging server, or if you would like to use JLINK. And if you will try to do that manually, there is a lot of work for you. Yes. Yes, a lot of work for you. Yes. Yes, a lot of work. Even if you try to switch just from JL into yet another debugger,

you need to pre-configure a lot of different things. You need to Google, you need to find or you need to read some data sheet from your debug prop, how to do debugging. But with Platform.io, you will just change one line. You will just explain my debug prop is this. And after that, we have the combination of five things like board, platform, debug tool, framework. And after that, joining all this data, we understand how to do proper debugging for your board. That with this configuration,

you can move between different ideas. For example, today you use Eclipse. Tomorrow you can even open Sublime Text Editor and press the same F5 button and your debugging session will be established with the same configuration. No need to do extra steps. Since you're doing all this in the background, well, not in the background.

Yes, you are. You're setting up all these debug parameters and invoking the right things. That seems like a big challenge because things do go wrong even when everything's correctly set up. For example, with Jlink and JDB server, I know sometimes things just get wedged

and I have to murder everything and start over. Do you provide any kind of help there, intelligence, to say, hey, we're unable to talk. JDB server is informing us that we're unable to talk to your board. We'll restart it. Or is it kind of, it worries me a little bit when things are completely in the background because then I can't tell when something's wrong. So when something is wrong, how do you service that?

Yes, so the first, there are two ways how you can use this platform unified debug. You can use it from the command line. In this case, you will see all the issues with your debugging server. But in case, for example, with the IDE or Visual Studio Code extension, which we have, there is a debug console where we print different things into the console. Also,

there are extra settings where you can enable advanced debugging information. You will see full communication interface between Visual Studio Code frontend and backend side, and also the RSD console command line where I can pass extra commands. If you need, for example, to pass some extra commands to your debug server, you will just type monitor, prefix the command, and after that, just type some subcommands of your debugging server, and you will see some answer or status of your debug server. So you hide a lot of the complexity,

but most of it is pretty easy to get to if you have problems or want to have the control beyond what a normal user might want. Yes. So every time we try to make our thing as simple as we can, but again, if you need some full control, even in case with the debugging, you can use a lot of different pre-configuration things. It's better to go to our documentation

where you will see that you can control this debugging engine with a lot of different things. You can even specify your own debugging server, command for initialization command, or things related for the debug monitor. A lot of things you can control this from the disease-unified platform.io.ini file.

Okay, so we've talked about IDEs and compilers and debuggers and libraries. This seems like a lot of work, but it's an open-source project. How do you get paid? Nice question. So today we have business to developer models called Platform.io+, where we provide some extra features, extra tools for our developers. For example this Platform.io Unified Debugger and Unit Testing Engine. These features are not free but that is not our plan to make these features paid.

Because this is a great solution for us to be independent from any silicon vendors and to keep Platform.io project alive and to be tolerant to any architectures or any boards. And my dream is to have everything in the Platform.io free for everyone. That is my dream. Because when I started this project five years ago, I created domain platform.io.org. I didn't create platform.io.com because my vision was like platform.io should be not for tomorrow, not for this year, but for 10 years or 20 years. And every time I think about platform.io

like a project for the years, not for the months. And last year was very important for us because we had a lot of conversation with lead silicon vendors. And I hope that our community will be surprised this year because we plan to make some things free and open source also, which we made today in the Platformer Plus. And it should be really win for both of us, not only for the developers, but for the Silicon vendors too. Because you know, there is a huge problem today in the market. If you are a Silicon vendor and you want to create your own idea.

You will need to spend a lot of resources. I don't mean only financial resources. I told about the time. It could be six months. It could be one year. But in case of the platform I.O., you don't need to spend these efforts. No.

You will just create a development platform for the Platform.io, provide integration, it's very easy. 100 lines of the code. You explain Platform.io how to build source code for your architecture and your product is ready for the market.

This is great because Platform.io offers quick integration for market-ready processors, and it reduces time-to-market costs. No need to wait six months. And this is very important for the risk file. Yes, it's open-source architecture because there are a lot of small, small companies which try, not try, which provide some IP cores, a processor. And for them, it's so expensive to create yet another IDE based on the Eclipse. Because if you try to summarize from the top silicon vendors, 99% of them has own IDE based

on the Eclipse. And if you have five or 10 different boards on your table, you will need to install 10 different Eclipse in your system. You have described my computer very well. Yes. And I think that is, that is, I mean, this is, this is big problem, not only for the Silicon vendors, but also for the end user. Because every time you switch between these ideas, and you need to understand what I changed this, I forgot what I changed this.

And again, a lot of machine resources. It's like two gigabytes per one instance of the Eclipse. And our aim our aim, our aim is to make platform are you really like daughter real organization, where every every every silicon vendor can participate in our improvements. I am I really dream about platform foundation, and I'm ready to move whole source code and IP to this foundation.

This is actually my goal. That is a very cool, very public-facing goal. But it will need financing from the chip vendors or some organization because it is a never-ending goal. There will always be new boards.

There will always be new debuggers. There will always be new compilers. It just will go on and on. And then there's the library aspect, which is partially based on vendors, which change constantly, and partially based on your users. So it does require continuing effort.

And I guess you kind of hinted maybe there will be an announcement and I should stop because I can't ask you directly that question, can I? Yes, you can do you think that funding will allow you to be a dot org to allow you to be an ongoing project that is not necessarily profitable but at least supports the developers who are working on it? So the first, if we talk about platform.org, so we don't talk about some big manager, yes? Because the main goal of both of us, not only me, but also of the Silicon vendors,

just to save resources and make happy our customers. And again, if, for example, if the same Silicon vendor will try to create this idea, you know that it's not enough for one engineer for this idea. But let's imagine that the expenses for the one engineer per year,

we will just donate to the platform.org. And if we do that together with 10 or 15 Silicon vendors, we will have some good financial, and we can hire 5, 10 developers, and it's enough to maintain the platform.org. But again, I don't see you maintain the platform.io.org. But again, I don't see on the platform.io.org, or it's better to say I don't plan to monetize platform.io.org. Because as I mentioned before,

it should be like a new standard because there is a new vision in the embedded market. And it would be great if we together maintain this platform and we will help not only Silicon vendors, but also students, universities. Because instead of working with one idea or one architectures, students will be able to use different architectures, different boards. Today they can use, forures, different boards.

Today, they can use, for example, AVR. Tomorrow, they will use RISC-V or similar to that or ARM. I mean, it's very easy. No need to reprint book materials in the school because one tutorial will work for the years. We explain one time how to use Platform.io and after 10 years, we will just explain will work for the years. We explained one time how to use Platform.io, and after 10 years, we will just explain you will need to change the one-line platform

equal some platform with new architecture. It's very cool. But again, if you're back to the Silicon vendor, even if they try to spend some resources making oven ID, they will just work on the one idea. But what to do if you will have yet another editor

two more? You will need again to spend resources to create your branded idea based on this editor. That is really second problem in the market. You can't quickly be ready for the new ideas or new editors.

But within the Platform.io, we do that. If you use, for example, if your hardware is integrated with the Platform.io today, you automatically receive access to our 10 popular ideas. Again, from the other side, if we have yet another better idea or text editor tomorrow, within the platform.io, we will try in a few days

to add software for this idea. And your customers automatically receive software for this idea. You don't need to spend again resources how to do that. Our goal is that silicon vendors, hardware vendors, they should be focused on the hardware. And the software part, it's very similar for all hardware. I mean, like interface for debugging,

build process and different things, they are similar. The only things which differ between them, this is build flags, tool chains. And as I mentioned before, we do that in the totally separated development platforms where every vendor can control how to build this software. I really like the idea of consistency. I mean, I'm working with a new IDE, and F5 does not do what F5 should do. And F7, I think, just deletes the whole project or something. I know that that's a minor thing, but it slows me down.

And not knowing... Well, especially in embedded, because each project is sometimes on a different processor and different framework, and so everything changes all the time. Whereas if you're a desktop developer or a phone developer, you're in Apple's thing or you're in the Android studio and you don't go anywhere and things stay the same.

But for embedded, yeah, we're always switching between IAR and GCC and your favorite editor and it's very confusing. It is. I really like this idea. Yes, but for example, what to do if you have a team from 10 engineers and some of them

prefer to work on Windows, some prefer to work on Mac and some on Linux. It's a big problem. Yes. But with Platform.io, no problem because Platform.io.ini is an.ini file. It's a common file between different operating systems and IDs. And you can concurrently work on the same project.

It's a really huge benefit. You decide. Even if you decide to work from the command line, it's very easy. And again, if you use ir and you do some change in your project you will need to ask your team members to do this change also in their ideas and in case with the platform you will just do one time change in the common file for the project. And after that,

you can commit the change to the source control version system and your change will automatically reflect it on the machine of your team members. No need to replicate these things. Switching subjects, you mentioned RISC-V. We have gotten a few emails

asking us to talk more about R five but uh haven't done it could you what is risk five nice so risk five so risk five uh this is open source architectures i will try to be so so accurate because again we support a lot of different architectures and we try to be tolerant to the different architectures but at the end of the 18 years like previous year we had so huge event

in the Silicon Valley called Risk File Summit and I participated in this event we have a small table, it's not the booth, small table, and we met a lot of different people, and also I can say these are the lead people from the different Silicon vendors,

and I was really surprised, really surprised, because it's over 1,000 attendees, this conference. Not only the conference, because it was our 1,000 attendees, this conference. It's not only the conference because it was four days. It was two days of the conference, two days of exhibition, and some pre-conference parties. It was really cool. And why I'm really impressed? Because I saw a lot of different projects and IP cores

based on the open source instruction set. It's really cool because for example today you know if you would like to create your own processor. I don't I don't I don't talk that you should pay for this IP core to some IP core provider. But I mean that you don't know what is what is inside this IP core. This is like, let's imagine that you want to create the robot. Yes, but someone will provide you the head of this robot and you can change this head. You just can't connect some arms, legs, but you don't know what is inside the head. But in case with the RIGS-5, you can create, I mean, the first, you know what is inside,

the second, you can create your IP core. And if we talk about huge corporation, because you know that Western Digital and a lot of companies, they announced that they will switch totally to the RISC-V. We know that this architecture will allow them to save a lot of financial resources. Okay, I think I want to go back because there are going to be some people out there

who don't really know how these cores work with if you want an arm cortex m0 or m4f normally as a developer you go pick up a board from st or nxp or whoever but those people have made microcontrollers based on ARM's Cortex-M whatever. And they buy that core from ARM. And it is hugely expensive. Even just getting some of the material is hugely expensive. And ARM is pretty voracious in taking licensing money. Well, that's their business.

It is indeed. And I do like their course, so I'm not going to say that's bad. Just if you are thinking about making your own processor, which you really shouldn't. If you're making less than a million of something, or you're making something that is going to cost less than a million dollars, you should not be making your own core. Or you should not be making your own processor. Processors are super expensive. And having to license ARM or having to set up the ARM core development, the IP for them is expensive so risk 5 is a core i don't know how it compares to the cortex line i think it's in the m area i don't think it's a big processor do you know yes so the first we can't we can't compare riskISC-V with Cortex-M

because Cortex-M, this is some specific core with some features. I mean, it's better to compare RISC-V with ARM because left and right side, we talked about architectures. If you want to compare for example cortex m with some something it's better for example to go to the sci-fi maybe you have heard sci-fi the public company which provides different ip cores based on orix 5 architectures and they actually do this comparison. They have different families of their chips,

whereas they compare this IP core in comparison with ARM Cortex-M. You can see this comparison. You can see the benchmark things. But if we talk about Oryx- risk file we will just talk about instruction set so this is the set the same is the the same the same is the arm it is not so we can't talk just only with the cortex m0 but again again if you want to have your own processor based based on the arm of course you need to you need to pay them for the license yes and what i know so i'm not sure this is this is truly correct information but you also need to pay some royalties i mean from each so much yes from each produced chip from each produced chip, you need to pay them 15% or more.

I don't know. I mean, there are like two prices. The first, you need to pay for the IP core license. Where are you now select? Is it the Cortex-M or is it like Simon? They have a lot of different Cortex. And after that, you also need to pay the second. But I think, my point of view,

the problem is not to pay. Because if you talk about huge monsters, like huge companies, ST, Nordic, or different companies, you know, they use ARM cores. And for them, it's not the problem to pay. I think the big problem is that if you have some specific requirements for your processor, you don't want to share these

requirements with ARM. Let's imagine that I want to create some specific processor which will solve this, this and this. For example, the base generic cores in the ARM don't fit very well for my processor. I want to have some specific individual core for my task. And it will be so expensive to do that with the arm. But it's very easy with Rix5 because architecture is open source. A lot of universities, it's a huge

community. I was really impressed because mainly what I saw, a lot of people in the universities work on their own course. It's great that today students learn how to make oven processor. Not how to use, but how to make. And I think it's great.

And I think that's great. But it's one of the reasons we haven't talked about RISC-V much, is that it is primarily a research project project or has been for a long time. At the conference, did you see it becoming a truly commercially viable core? Sure, sure. I was really impressed. For example, Western Digital, they announced their own core. I don't know, it's called like Swerve, their own core.

And they announced, the first, they totally switched to the RX-5 and they plan to use fully RX-5 in their products. It's the million, million, million devices. And again, if we will just talk about this example with the Western Digital, again, I'm sure that we don't talk only about the money where Western Digital saves. But what is really important is that they protect their IP.

Because, you know, if you talk about SSD or hard drive controllers, there are a lot of IPs around how to do that. And I'm sure that for them it's very cool because now they can create some specific, very well-optimized core for their tasks. It should be really low power, maybe some things related to the memory. I'm not so expert in that.

But it's very cool. I guess what I'm hearing that's that's interesting to me that kind of has changed my mind a little bit is um like alicia said you shouldn't consider making your own it really shouldn't see or or or processor but risk five may be changing that by making it way easier and way more possible to do that. And that opens up a lot of opportunities for people to customize things in a way that they haven't been able to before. Does that sound accurate?

Yes, yes. It'll be nice to get her away from the 80-51 course. Yeah. Yes. Yes, maybe we need more time I don't know one year or two but I'm sure that this is right

this is actually what we did with the open source software because if you back again 10-20 years before everything was closed source but take a look at the revolution which we did with the open source related to the software and I think it will be was closed source. But take a look at the revolution which we did with the open source.

I mean, related to the software. And I think it will be really great for all of us if we will do the same with the hardware, with the processors. Where everyone can create own processor for the specific, specific task.

It's really great. And again, you no need to worry about the millions you should pay to some IP cores providers, because it will be so cheap for you. Architecture is open source, you know what you need. You can merge together both things and you have your because today it's very cheap. It's very cheap to very cheap it's very cheap to print it's very cheap to print your own processor for example if you if you pay for the end microcontrollers we pay just one dollar or similar to that it means that the price for physical microcontroller it's very cheap the the huge price this is ip intellectual. And to print this chip, it's not expensive. And let's

imagine that everyone can print your own chip. It would be really great. Yeah, I mean, the silicon is cheap. It is? Why? Last time I was at a fabulous semiconductor company, we spent $350 million.

It will look the same as how you today want to print your own PCB. It will just send some files and you receive your board. It maybe will look the same. Even today, you can go to the Sci-Fi website. They have online configurator

where you can configure your own IP core, press build or order button and you will configure your own IP core, press build or order button, and you will receive your own customized core. Again, I don't promote this company. I don't know their prices. But I mean that this is actually what we would like to see in the future, where you can go, you can customize

your own core, press build button, and you receive at your home your own chip with your own logo. We'll have to let Osh Park know that they have to start making chips too. Yes. Yes. Okay. That was a great introduction to RISC-V,

and now I want to go back to Platform.io and ask a couple of listener questions. Mm-hmm. How do libraries get into your index? I guess I'll start there, and then I have a bunch more after that. So there are a few ways how these libraries go to our registry. The first, we have some crawlers, which go through the internet and analyze different library manifests.

Second, you can manually submit your library to our registry. And third, we have some synchronizing mechanism where we synchronize our registry with Arduino libraries, or even better, because you know that Arduino... Oh, really? Yes. And together today we support about 6,000 different libraries. How can I safely use the libraries in my code without worrying about copyright issues?

So I am not an expert in the legal aspects of the libraries. But my point of view, if you use some library, yes, you will just use its API through the include or similar to that. You don't need to worry about the license of this library. But if you will try to modify this library or include this library in your project,

yes, you need to be more careful with the license of this library. What I mean? Because if you install library within the platform or your IDE, you will just press install button. But this library will not be installed in your... I mean, the source code of this library will not be copied to the source location of your project. The library will be some isolated pass. And you will just use the API of this library.

I think this is, it's okay. This is actually what people do. I'm not sure that everyone modifies these libraries. But what we really want to do, we plan to create some information on our website where people will see more detailed information about license information. And the same would be good maybe to print this information in our build system if a library is inGPL or similar to that, just to inform someone that this library is not MIT or similar to that.

The copyright you're describing, where if you don't go into the library, it's fine to use, you only use the public API, that's sort of the LGPL library, LGPL copyright. And that is good, but do you track any of that with the library registration as part of the index? Do you tell them?

So, the first, we have this manifest field with license and people see the license of the library. But on the build process, we don't track this compatibility, license compatibility between different libraries. And maybe it's a good idea. Thank you so much. I will do some notes.

Yes, it's really great. maybe even to show in our dependency graph because we have the dependency graph where we show the name of the library, we show the version, and I think this will be really informative if you will print the license type. I would like that. That would be very helpful for me. Thanks. I'm always a little paranoid about libraries.

Do you know the answer for this question? For example, if we have a library based on the GPL license, and I don't include this library in my project, but use just only the API, should I also... I mean, is my project also affected by this license or not? GPL, yes. That's the thing. So there's GPL, there's GPLv2,

and then there's lgpl. lgplv3. Right. It means that I must also open source my project. Yes. My understanding is if you use GPL

in any form, that taints your entire project. If you use LGPL, that works the way you're saying, that you can use the API and you don't have to open source the rest of your project. But a lot of things are GPL.

I'm not sure, but if you go to the source a lot of things are GPL. Even Arduino, I'm not sure, but if you go to their source code, it's a GPL. Does it mean that everyone should open source their projects? Yes. Wow. It does. Arduino is very sticky, and most people don't realize that a lot of it does have GPL licenses, which could taint your project.

This isn't something that's well enforced, but if you're trying to be an ethical, professional programmer, then it's something you should at least think about. So yeah, I would like to see that. I'm now asking for features on a program that I've installed but not used. It doesn't seem right. Yeah, we can take that offline if you want. I don't want to get too far into copyright

because I want to ask some more questions about your product. Yes, but it looks so strange now in case with the Arduino. Because even Arduino pad is Apache license, you know, it's Apache license. Apache is one of the nicest licenses. Yes. And so anything Apache, you're safe to use.

But it's very strange with the Arduino, because they don't personally do any jobs, they don't maintain, I mean, the community maintains and supports Arduino. And maybe the community can change these lines, if not. Because if you go to their repository, yes, the Arduino IDE or similar to that, you will see that the community together maintains this platform.

I mean, not like Arduino.cc personally. And once it's a community-maintained GPL license, it is very, very hard to change that. In fact, I mean, I know when you have one or two developers, you can do it with permission of developers. But once you have a community,

I don't know how many people you would need to agree to change the license. Boy, that's weird. Historic, historical, historical issue. Just to clear up, the core libraries, the Arduino core and libraries are all GPL. And the Arduino environment source code is GPL. Right.

Community libraries may be whatever. So that would be where you'd enter into problems if you start bringing in community libraries that you're not tracking properly. Like Adafruit has their sensor library. And I know that that one's safe. That one's Apache or Beerware or something

very open. But if you're working with a vendor, an IMU vendor who has a library, you don't know. you have to check. Thank you, thank you. I think it was very informative for our listener. Okay, so do you think that having the library index is helping to shape the quality of the libraries available?

There are two sides to this matter. So there is the community libraries and there are private libraries. And if we talk about the makers, I'm sure that the open source libraries are very important and making them in our registry and will it have some influence on the quality? I think yes, because more users will use this library. And if they have some issues, they can report this issue to the repository and together we will make better and better this library. This is actually what we have with the Platform.io. Let's imagine that the

Platform.io is closed source. In this case it's very difficult to test and to improve it, but if we have it open source, everyone can review our source code and everyone can provide us some feedback or request some feature request I think that open source and this open registry is cool for both sides

like for the library author and for the end users Okay, one more from the listener. First, Matt had to say that he's been using Platformio with ESP32, and it's made development so much better than when he was using the Arduino's IDE. So yay. But he wonders, do you see an increased priority or future priority

for more programming and debug tools in the future of Platform.io? And the example he gave was ICD-3 from Microchip. Do you support Microchip development now? And do you look at doing more debug tools in the future? Is that higher on your priority list? So today we support three development platforms by Microchip. So this is AVR,

this is SAM, I don't know what is the correct pronunciation, Atmel SAM, and the third is the PIC32. In case with SAM, we have debugging support for for there

sum 21 need to check around 10 boards with support debugging debugging for around 10 boards but if we talk about sure because that comes from Atmel

if we talk and Atmel is good no there is there is the problem that we don't have a free or we don't have a free chip debugger for AVR or PIC32. And I told this microchip a few times and asked them to provide some instruction,

how do they do debugging with Atmel Studio or with Microchip, MP Lab, you know, they have this idea. But they don't want to see debugging for their hardware in other development environments. That is actually the second problem when silicon vendors think on the platform I.O. like on the competitive environment. Because if they promote their own ideas, they have control on their community. But let's imagine if you can debug through a different environment, you will lose this control. But this is actually the huge mistake.

This is my point of view. Because the more the more the more tools support your hardware, the more chips you will sell. This is actually the main business model of the microchip. To sell more chips, not

to see increased number of users by their envelope environment. This is my point of view. I think they would understand that. Yeah, it's mine too. They don't make money on their idea. And why do they force? I don't know.

And let me tell you, it is not that good. Yeah. We would like to have support for the AVR, and there are also the issue. There are also some open source project, it's called DebugWire, but it's not very well maintained and doesn't work very well.

But there is no good GDB, there is no, not good, there is no free or open source GDB debugger for... There is Avarice project, but it's also abandoned. And there is no debugging server similar to the OpenOCD, or similar to JlinkGDB. There is no debug server for AVR. There are some proprietary which they use in the Atmel Studio and MPLAB, but you can't go to their website and download it. You need to re-engineer their idea, but that is unofficial. And you can't do that. Even with the J-Link, you know that if you go to the J-Link license, you can't redistribute their source code of their GDB server.

But we have official permission from them where they allow us to redistribute their software. And today, if you will try to debug some project with the J-Link, Platform.io will automatically install the proper version and automatically runs this debugging server in the separate process. But we did, I mean, that we personally contacted J-Link and asked them to make some specific, not like a license, some specific exclusion just for us, for our case. Well, the good news is that I know we have listeners who work at Microchip. So maybe they can contact us.

Maybe we can actually fix this. That would be so cool because I would love to use Platform.io instead of MP Lab. Partially because I want to remount my keys. Partially because I want editors I'm used to, partially because it just would be easier for my brain to have the same editor and same interface through different platforms.

I'm a consultant. It's really nice to not have to remap my brain for every client, although that is what I usually end up doing anyway okay you can you can actually go to their community forum they have for the atlant and you will see a lot of feature because a microchip also plans to close the atlant software framework and I see people really they are not agree with the microchip and they want to move

all customers to the Harmony framework and force them to use this AmpliLab actually don't know who provides this strategy for me it's like strategy 20 years ago maybe it works but not today microchip you should be selling processors

we'll buy your processors if you stop trying to nickel and dime us on the software yes take a take a look at the st micro i think they did really great work the only one year ago they bought what is the name of this idea i don't remember atolicolik, Atolik Studio. Only one year ago, they bought this Atolik Studio. But 20, a lot of years, they even didn't have oven idea. It's actually the same with Espressif. They don't have oven

idea. Why they need it? There are a lot of ideas. Yes? They are actually focused on the hardware. It is great. And both companies are so successful. All right. I think we have kept you for long enough. And we certainly have covered plenty of things.

Are there any thoughts you'd like to leave us with? So, first, I should say a big thank you for the invitation. And for everyone, we have a very good proverb in the Ukraine, and I highly recommend to follow this proverb. In Ukraine, it sounds like, eyes are afraid, but hands are doing the job. But I tried to Google and found an internet-series English version called, like, you never know what you can do till you try.

And actually, this is really the huge problem and the same with me. Every time if I see something complicated, I will just remember this proverb and try to do. And I wish everyone, if you want to do something, you will try to find time for something else. Just repeat this proverb and work on that. Cool. Very cool.

Our guest has been Ivan Kravets, founder and CEO of Platform.io. You can contact Ivan on LinkedIn to learn more about Platform.io. You can contact Evan on LinkedIn to learn more about Platform.io, although of course you can go to platformio.org. I find it's much easier to remember if you call it platformio.org, then you don't get to platform.io, which we aren't going to talk about. So platformio.org. Thank you for being with us. Thank you to our patrons for Ivan's mic. We really appreciate your support.

And if you'd like to support the show, go to embedded.fm and hit the support us link on the top bar. I also want to make sure to thank Valeri for convincing Ivan that this was a good idea. And thank you to Christopher for producing and co-hosting. Also, thank you for listening. You can always contact us at show at embedded.fm or hit the contact link on the embedded.fm website. And now a quote to leave you with. Ah, this one's from Shel Silverstein and the poem is called Everything On It. There are no happy endings. Endings are the saddest part. So just give me a happy middle and a very happy start.

Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.