tinygo-org / tinygo

Go compiler for small places. Microcontrollers, WebAssembly (WASM/WASI), and command-line tools. Based on LLVM.
https://tinygo.org
Other
15.42k stars 910 forks source link

Zephyr project integration #379

Open ghost opened 5 years ago

ghost commented 5 years ago

https://docs.zephyrproject.org/latest/

We are using tinygo and it's been a huge help. Now we are looking into the best way to support the OS and BSP aspects.

I know about the yocto project, but am interested in using tinygo with zephyr to get a complete architecture.

Is this something that others are using I wonder ? Anyone have experience using it with Tinygo ?

deadprogram commented 5 years ago

Hi @gedw99 integrating with Zephyr would be great. We've looked at it a little alongside a few others.

Most RTOS will require similar changes. For example, all will require some way of scheduling goroutines, probably in separate tasks instead of how it is implemented now.

I'd love to find out more about your current use cases if you do not mind sharing, or you can contact me privately if you prefer that.

ghost commented 5 years ago

Hey @deadprogram Medical devices is what we are using tinygo for. So EKG and Glucose Continuous meters.

We are not at all good a this actually. More server programmers. Tinygo was chosen because everything else is golang :) Poor excuse i know but for now it works for us.

Updatehub has a golang SDK and uses Zephyr and is able to do transaction A/B updates to the iot devices. That gets that huge hurdle sorted. Managing IOT devices so you dont brick them is hard. https://github.com/UpdateHub We are collaborating with them on this aspect but also embedded in general since we are not embedded architects.

aykevl commented 5 years ago

Great to see your interest in using TinyGo for such a serious application! As Ron mentioned, we don't have support for RTOSes now because it's not really our primary target, but would be interested in supporting them in the future. Challenges here are goroutine starting/scheduling, build tool integration (who manages the build, TinyGo or west/newt/whatever), and heap management (Go needs garbage collection).

Tinygo was chosen because everything else is golang :)

This is one of the reasons why we're making it. Our hope is that it allows code reuse between projects lowering the cost of development.

gordonklaus commented 5 years ago

Hi. Can someone explain to me what the point of Zephyr integration with TinyGo would be? I came to TinyGo with the impression that it is more of a replacement for Zephyr, but I would love to know in what regards that is not the case.

deadprogram commented 5 years ago

The idea to me is to be able to use TinyGo as the compiler, and use capabilities in the RTOS, along with interoperating with other services/libs written for that RTOS.

It is true that TinyGo also has a Hardware Abstration Layer (HAL) of its own, but those are primarily related to peripheral i/o such as I2C, SPI, etc. Seems like you could even also use these things together, stitching together code that use the TinyGo HAL alongside services such as OTA updates, etc.

aykevl commented 5 years ago

Agreed with @deadprogram here. Yes, the runtime and machine packages replace most of the stuff you would normally expect from a RTOS. However, many projects are already built on top of an RTOS and using those facilities allows integrating Go code (compiled with TinyGo) into an existing project. For example, that way you could replace an existing system written in C/C++ slowly with code written using TinyGo, or use existing libraries that expect to be running on an RTOS. Also, RTOSes often provide their own HAL which could be a quick way to support new hardware.

gordonklaus commented 5 years ago

Thanks for your answers, @deadprogram and @aykevl.

Migrating existing projects and taking advantage of existing libraries seem like great reasons for integration with Zephyr or other RTOSs.

But I guess what I'm relly interested in is: What is the planned/desired scope of TinyGo? Are there features of an RTOS that are not feasible to implement as part the TinyGo ecosystem? @deadprogram mentioned OTA updates...

Maybe this issue isn't the best place for the discussion. We could create another issue for including this information in the documentation, if you see fit. I can imagine a lot the people who are attracted to TinyGo (Go programmers new to embedded – like myself and the OP) would find it valuable.

davidg238 commented 5 years ago

Zephyr supports OpenThread, enabling mesh networking of devices. Likely prohibitive to re-implement Thread in TinyGo, whereas using TinyGo on Zephyr devices, would be useful.