gRPC for embedded systems( for example - RTOS like ThreadX, FreeRTOS etc. )

[dharam...@cypress.com]

Hello folks,

I'm working on a project where we are planning to create a Google Assistant service instance on embedded/deeply embedded devices( non-linux, ARM processors running RTOS like ThreadX, FreeRTOS etc. )

Our system has support for building executables for c/c++ etc. but it is not same as linux( for example - no posix availability ).

Of course, like RTOSes these days, we have wrappers for providing OS/Networking functionality for applications/libraries to use.

My questions are:

i.   How fit gRPC is for embedded devices? I can see abstraction for different platforms in "port_platform.h" file used to build grpc-core with options given in the file.

     My first thought is it should be doable if I adapt port_platform.h and build grpc-core with the capabilities provided by our system.

ii.  How deep gRPC's love is for posix? If any platform/devices does not provide any posix-like high level APIs, will gRPC still work as expected? How straight-forward such a task is going to be?

iii. Any effort in community in bringing gRPC for embedded devices(for RTOSes) ? Would not it be great to have a tiny(and limited) gRPC library which can be

    easily integrated to embedded devices ? And such a thing supported by gRPC community/authors ?

I understand that I can get most of the answers from reading the code itself(which I'm doing btw).
But it would be nice to know insights/perspective of gRPC authors and community folks who understands gRPC better than me.

Open for suggestions/feedback.

Best regards,

Dharam

[jianhua....@hmdglobal.com]

Hi Dharam

i started looking into similar task in this week. 

just wondering if you've gotten any progress on it since your posted the message almost 1 year ago :-)

Jianhua Song

[jaehong park]

Hello Dharam,

I'm having a similar project like below question.

(III.Any effort in community in bringing gRPC for embedded devices(for RTOSes) ? )

Do you have any progress this issue?

Could you let me know where I can find the answer for this?

Thanks,

Jaehong

[Nicolas Noble]

We have no plans for that, and the current codebase is way too intertwined with posix to ever work on FreeRTOS / lwip. A full third party implementation of grpc would be needed for that at this point.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5a72e682-031f-415b-830f-7818810f434f%40googlegroups.com.

[Dharam Kumar]

Hello Jaehong,

I've been able to put grpc framework on wiced rtos APIs. Basically, Wiced SDK from Cypress provides abstracted RTOS/Networking APIs which is underneath implemented by different rtos/network stacks. For example - Expresslogic's ThreadX/NetX, FreeRTOS/lwip etc. I was able to get threads running, start grpc core service, create grpc endpoints(tcp) etc...

Please note that grpc library does not support embedded TLS stacks like mbed-tls(from ARM). Also, default grpc transports module(chttp2?)might be too heavy for your embedded platform.  So, you may have to work on these aspect. So be remindful of how "embedded" you can go. For example - it probably won't work on a board/platform with 256KB of RAM.

In nutshell, putting grpc framework is totally possible.
@Nicolas Noble - I'm not sure about the grpc being intertwined with posix part - as i recollect there are pretty good grpc abstractions for different platforms(windows, unix, posix etc.) - i just built on that and was able to get the grpc core up and running.

Br,
Dharam

---

From: grp...@googlegroups.com <grp...@googlegroups.com> on behalf of Nicolas Noble <pixel...@gmail.com>
Sent: Wednesday, August 21, 2019 12:31 AM
To: jaehong park <jhpa...@gmail.com>
Cc: grpc.io <grp...@googlegroups.com>
Subject: Re: [grpc-io] Re: gRPC for embedded systems( for example - RTOS like ThreadX, FreeRTOS etc. )

 

You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/A0PlDMi2an8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAEvr0PEr7TM5m3JUtP04Jgc3tZj6zSx%2BmfRdGJNh5hwsB0HH6Q%40mail.gmail.com.

This message and any attachments may contain confidential information from Cypress or its subsidiaries. If it has been received in error, please advise the sender and immediately delete this message.

[leuc...@163.com]

Hello Dharam,

    I'm lucky to see your mail when I'm planning to put grpc to embedded device running ThreadX. 

But it's not easy for me since grpc does not provide any options for embedded device running RTOS. 

    I have following questions and I'm looking forward to your reply.

    1. The compiler I'm using is DS-5 ARM compiler 6.02 armclang  which has unsupported features such as -stdlib=libstdc++, and use of C11 library feature.

   so there're many compiling issues like atomic is not supported, no type named 'memory_order' in namespace 'std'.

   Did you see these compiling issue like these? what compiler are you using for compiling grpc? If atomic is not supported, is it possible to compile and run gprc?

    2. As POSIX APIs are not supported in ThreadX. So these posix-APIs need to be implemented by my own?

    3. When adding options for THREADX in port_platform.h, I disable many features such as GPR_LINUX_LOG, GPR_SUPPORT_CHANNEL_FROM_FD, GPR_LINUX_ENV and GPR_POSIX_TMPFILE

    But I'm not sure if grpc can work properly as these features are disabled. Any suggestions?

Thanks!

Dharam Kumar於 2019年8月21日星期三 UTC-7上午3時22分48秒寫道：

Hello Jaehong,

I've been able to put grpc framework on wiced rtos APIs. Basically, Wiced SDK from Cypress provides abstracted RTOS/Networking APIs which is underneath implemented by different rtos/network stacks. For example - Expresslogic's ThreadX/NetX, FreeRTOS/lwip etc. I was able to get threads running, start grpc core service, create grpc endpoints(tcp) etc...

Please note that grpc library does not support embedded TLS stacks like mbed-tls(from ARM). Also, default grpc transports module(chttp2?)might be too heavy for your embedded platform.  So, you may have to work on these aspect. So be remindful of how "embedded" you can go. For example - it probably won't work on a board/platform with 256KB of RAM.

In nutshell, putting grpc framework is totally possible.

...@Nicolas Noble - I'm not sure about the grpc being intertwined with posix part - as i recollect there are pretty good grpc abstractions for different platforms(windows, unix, posix etc.) - i just built on that and was able to get the grpc core up and running.

Br,
Dharam

To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/5a72e682-031f-415b-830f-7818810f434f%40googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "grpc.io" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/grpc-io/A0PlDMi2an8/unsubscribe.

To unsubscribe from this group and all its topics, send an email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAEvr0PEr7TM5m3JUtP04Jgc3tZj6zSx%2BmfRdGJNh5hwsB0HH6Q%40mail.gmail.com.

[Dharam Kumar]

Sorry, I didn't get your name :) . But here is my take on your questions -

1. I was using gcc compiler - so I didn't see any problem with lack of c++/c11 library features. Most compilers support features like 'atomic' - check if your compiler offers it or not.
   Overall, I think it is good to have, if not essential, to have c++/c11 support in your compiler. It will save a lot of hard-work for you. 
   For example - atomic operation can be emulated in software if your compiler does not support by default - but that's additional amount of work and it will make the system slower.
   
   
2.  I think ThreadX does provide a thin posix implementation(check their sample apps/examples etc). Having said that, you may not have to do the same. You can always add 'ThreadX implementation' 
   to what all grpc OS(posix) interface requires. For example - Queue, Threads, semaphores, mutexes, most of basic constructs are already available in ThreadX.
   
   
3. No, grpc may require some of these features. So, you've to review what you can implement and what you have to disable.
   For example - if GPR_LINUX_ENV is all about setting environment(key-value pair), setenv(...), getenv(...) from a linux-host perspective. Think of how you can achieve the same
   on your system. See if you can implement and fulfill these API requirements on your system. If you'are able to do that, you don't have to disable GPR_LINUX_ENV - as a result - all the code/test-apps/examples etc will continue to work. Alternative is to come with your own, GPR_THREADX_ENV flag and replace it with GPR_LINUX_ENV across the library - but that might be more intrusive and you may miss things.
   
   Idea is to really see what gets you closer to a working piece of grpc library. Like most of porting exercises - it is always good to have a new implementation of the interface
   rather than having a new interface itself.
   
   

---

From: grp...@googlegroups.com <grp...@googlegroups.com> on behalf of leuc...@163.com <leuc...@163.com>
Sent: Thursday, September 12, 2019 3:36 PM
To: grpc.io <grp...@googlegroups.com>

To unsubscribe from this group and all its topics, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4d301f1c-04fd-43a2-9e1c-3061329a0a5b%40googlegroups.com.

[leuc...@163.com]

Dear Dharam,

    Thanks for your quick reply and your suggestion has shed a light on my understanding of the porting the gRPC. 

    I think the compiler I'm using now is a problem. At the beginning, I follow the steps defined in README file in gRPC to cross-compile the project, I found the step is to build the whole project on the Host as there are some 

Dharam Kumar於 2019年9月12日星期四 UTC-7上午5時05分23秒寫道：

To unsubscribe from this group and all its topics, send an email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4d301f1c-04fd-43a2-9e1c-3061329a0a5b%40googlegroups.com.

[leuc...@163.com]

Dear Dharam,

    Sorry for my late reply.

 

    Thanks for your quick reply and your suggestion has shed a light on my understanding of the porting the gRPC:)

    About Atomic feature, I switch to ARM compiler 6.6 which can support <atimic> now. 

    Normally, for corss-compile the gRPC, I checked the README and some information on the web: 

    

    GRPC_CROSS_COMPILE=true 

    PROTOBUF_CONFIG_OPTS=--host=arm-linux --with-protoc=/usr/local/bin/protoc

    HAS_PKG_CONFIG=false 

The steps for cross-compiling are as follows:

# First, clone and make install of grpc using the native compilers for the host.

# Also, install protoc (e.g., from a package like apt-get)

# Then clone a fresh grpc for the actual cross-compiled build

# Set the environment variable GRPC_CROSS_COMPILE to true

# Set CC, CXX, LD, LDXX, AR, and STRIP to the cross-compiling binaries

# Also set PROTOBUF_CONFIG_OPTS to indicate cross-compilation to protobuf (e.g.,

#  PROTOBUF_CONFIG_OPTS="--host=arm-linux --with-protoc=/usr/local/bin/protoc" )

# Set HAS_PKG_CONFIG=false

# To build tests, go to third_party/gflags and follow its ccmake instructions

# Make sure that you enable building shared libraries and set your prefix to

# something useful like /usr/local/cross

# You will also need to set GRPC_CROSS_LDOPTS and GRPC_CROSS_AROPTS to hold

# additional required arguments for LD and AR

# Then you can do a make from the cross-compiling fresh clone

$make 

But the ARM compiler 6.6 I'm using is a windows version, which means most of the command in gRPC make process is not executable.

Then I try to build gRPC on Linux host first(use the Makefile in gRPC source code) in order to know:

1. how many libs will be generated

2. the corresponding sources files compiled for the lib.

3. compiling options for each lib.

By adding these source files to my ThreadX compiling system(windows based), I start to compile them. 

I know it's not a easy task to build a gRPC lib for embedded system and it will take months to make it work.

I'm very happy to know you and your suggestion means a lot to me.

Thank you!

Leon

Dharam Kumar於 2019年9月12日星期四 UTC-7上午5時05分23秒寫道：

To unsubscribe from this group and all its topics, send an email to grp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4d301f1c-04fd-43a2-9e1c-3061329a0a5b%40googlegroups.com.

[nilabh Anand]

Hello Dharam, 

Good day to you. Do you have a rough estimate if you could share on the memory requirements is it more than 1MB?