Nice job with Renode simulation ;D I myself tried to implement RP2040 but lack of time and development for other MCU made me drop it for few months. Maybe I will put my hands on it again! Powodzenia ;)
Thanks :) currently I am working on adding PIO simulation for the next part. I think I will release a video on how to use it on other projects. Of course it still will be in work in progress mode with contributions warmly welcome :) in which environment have you tried to implement RP2040?
@@matgla95 to be clear - by implementing I meant Renode implementation. I'm more focused on other MCU series right now ;) looking forward to see the video on how to use Renode. Maybe I'll learn something new from it :D
It's not scrapped :) It's just evolution, complexity of hardware is going to be reduced, but components inter-working that I mentioned will be implemented to communicate between motherboard and extension cards. Previously I planned to use exactly the same implementation for northsouth communication and for northextensions. With RP2350 only northextensions is left.
Out of curiosity, why the GNU GPL rather than the GNU AGPL? The GNU AGPL is stronger and would prevent anyone from taking your operating system and turning it into a cloud service and refusing to give anything back to you. As for the hardware, were you aware of the CERN Open Hardware License when you licensed it? The CERN Open Hardware License 2.0 Strongly Reciprocal is essentially the GPL for hardware rather than software.
Thanks, for that comment! That software is created mainly for educational purposes. I don't think that I will be able to create OS/Bootloader/(What ever else) that is able to compete with any other not single person project. Also I don't see any real usecases to run it over network. It's closely related to specific hardware. For other cases there are better tools available. But if someone will find a way to use it: good for him! :) I selected GPL for software, because I like that part you have to share with community if you wanna use it. But I wasn't digging deep through all licenses availble, I just selected first one that was fine for me. AGPL also fits, but I don't think I will change all license headers right now. About hardware part, it's an experiment. I am only hobbiyst, so I decided to publish with just MIT. Basically to allow anyone to do whatever they want with that.
@@matgla95 One of the good things about the GNU AGPL is that the network use is redistribution clause doesn't really apply if you do not make the software available over a computer network. In that sense it is pretty much identical to the GPL for non networked software, but if anyone turns it into a service as a software substitute then the network use is redistribution clause kicks in immediately.
Nice job with Renode simulation ;D
I myself tried to implement RP2040 but lack of time and development for other MCU made me drop it for few months. Maybe I will put my hands on it again!
Powodzenia ;)
Thanks :) currently I am working on adding PIO simulation for the next part. I think I will release a video on how to use it on other projects. Of course it still will be in work in progress mode with contributions warmly welcome :) in which environment have you tried to implement RP2040?
@@matgla95 to be clear - by implementing I meant Renode implementation. I'm more focused on other MCU series right now ;)
looking forward to see the video on how to use Renode. Maybe I'll learn something new from it :D
Most impressive and very interesting. Well done.
Thanks!
Good job
Thanks!
Even though you scrapped this I would love to see a video on this, I am curious if you would use something like LiteRPC
It's not scrapped :) It's just evolution, complexity of hardware is going to be reduced, but components inter-working that I mentioned will be implemented to communicate between motherboard and extension cards. Previously I planned to use exactly the same implementation for northsouth communication and for northextensions.
With RP2350 only northextensions is left.
based
Thanks :)
Out of curiosity, why the GNU GPL rather than the GNU AGPL? The GNU AGPL is stronger and would prevent anyone from taking your operating system and turning it into a cloud service and refusing to give anything back to you. As for the hardware, were you aware of the CERN Open Hardware License when you licensed it? The CERN Open Hardware License 2.0 Strongly Reciprocal is essentially the GPL for hardware rather than software.
Thanks, for that comment!
That software is created mainly for educational purposes. I don't think that I will be able to create OS/Bootloader/(What ever else) that is able to compete with any other not single person project.
Also I don't see any real usecases to run it over network. It's closely related to specific hardware. For other cases there are better tools available. But if someone will find a way to use it: good for him! :)
I selected GPL for software, because I like that part you have to share with community if you wanna use it. But I wasn't digging deep through all licenses availble, I just selected first one that was fine for me.
AGPL also fits, but I don't think I will change all license headers right now.
About hardware part, it's an experiment. I am only hobbiyst, so I decided to publish with just MIT. Basically to allow anyone to do whatever they want with that.
@@matgla95 One of the good things about the GNU AGPL is that the network use is redistribution clause doesn't really apply if you do not make the software available over a computer network. In that sense it is pretty much identical to the GPL for non networked software, but if anyone turns it into a service as a software substitute then the network use is redistribution clause kicks in immediately.