stack size

[ghost]

I getting weird crashes (memory corruption) that appear to be related to the number of functions passed to interface(...).

I suspect (but am not at all sure this is correct) it's is because of running out of stack. Doesn't place interface(...) a lot of data on the stack (and copies there in each call)?

Would it be possible to instead allocate the arguments to interface(...) on the heap or as statics?

[jfjlaros]

I don't think there is any stack management done on these devices, so I would expect that at a certain point the stack and the heap collide. In this case, moving memory to the heap will not help much.

How many functions are we talking about here? Also, perhaps you can do some measurements as described here.

[ghost]

I'm using this on an ESP32 which uses FreeRTOS. I fixed the issue with allocating more stack to the task.

There are ways to check for stack overflow; I'll look into this later.

[jfjlaros]

Oh, I assumed you were using an Arduino. My bad.

Just out of curiosity, how many functions are you exporting and how large is the maximum stack size at the moment?

[bboser]

I have about 50 functions defined. Actually, that’s probably only 100 words on the stack (400 bytes), not that much. The problem occurred in the wifi handler. I assume it needs a lot of stack.

I could not figure out how much stack space is allocated to the “default” task. For now I created a separate task for simpleRPC and gave it 16kWords (for now I still have lots of free ram).

FreeRTOS has features to investigate stack usage, I’ll do that later when I run out of ram.

BTW: I program the esp32 as a wifi internet gateway for a small ARM processor running CircuitPython (a flavor of Python 3 for microcontrollers). The hardware I am targeting is https://docs.particle.io/argon/.

Both processors (ARM and ESP32) are fairly powerful compared to the 8-bit Arduino cpus. But I did have to pare down the Python end of simpleRPC some. I also had to slightly modify the comm protocol since the serial connection is shared (mostly log messages and asynchronous results like mqtt messages).

Anyway, works great, thanks!

Bernhard

On Wed, Jul 10, 2019 at 9:54 AM Jeroen F.J. Laros notifications@github.com wrote:

Oh, I assumed you were using an Arduino. My bad.

Just out of curiosity, how many functions are you exporting and how large is the maximum stack size at the moment?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jfjlaros/simpleRPC/issues/4?email_source=notifications&email_token=AAW5XJEZONDKP5WQB3ASDCLP6YH25A5CNFSM4H7KUOA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZUCTVI#issuecomment-510142933, or mute the thread https://github.com/notifications/unsubscribe-auth/AAW5XJHKGRFK7RSL5ZMZNHDP6YH25ANCNFSM4H7KUOAQ .

[jfjlaros]

That's already a lot more functions than I ever tested.

The Python side of this library is indeed pretty heavy, I assumed it would run on a normal PC. I guess you removed all of the documentation generation?

Of course any suggestions and improvements are welcome.

[bboser]

HI Jeroen,

Yes, I dropped the descriptions. But I also made changes to the return protocol to multiplex traffic from other sources.

Now I’m about to implement asynchronous calls.

All rather specific to my application.

Bernhard

On Wed, Jul 10, 2019 at 12:18 PM Jeroen F.J. Laros notifications@github.com wrote:

That's already a lot more functions than I ever tested.

The Python side of this library is indeed pretty heavy, I assumed it would run on a normal PC. I guess you removed all of the documentation generation?

Of course any suggestions and improvements are welcome.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jfjlaros/simpleRPC/issues/4?email_source=notifications&email_token=AAW5XJEGOXANC7HGK7OTFODP6YYZVA5CNFSM4H7KUOA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZUO3XY#issuecomment-510193119, or mute the thread https://github.com/notifications/unsubscribe-auth/AAW5XJHY7MJ5OKRYK3WB7NLP6YYZVANCNFSM4H7KUOAQ .

[jfjlaros]

Perhaps we can think about a dedicated repository for a CircuitPython client?

I am also interested in how you implement asynchronous calls and multiplexing. Perhaps we can add these ideas to the core library.

[bboser]

Hi Jeroen,

I’ve made the repos public (licenses have to be worked out, I like everything MIT so it’s micro-python compatible) - see description at https://github.com/iot49/iot49. At the core is a cooperative multitasking “operating system” (eventio) on the microcontroller.

Beware: the code is neither of the quality nor beauty of what you write. Ultimately (actually, I’m already using this albeit with a few limitations) the idea is to connect to an eventio task from a Jupyter notebook - all while the user task(s) are running (unlike “repl”, which stops the user code).

Examples: https://github.com/iot49/iot49/blob/master/notebooks/doc/SimpleRPC.ipynb.

The SimpleRPC with async processing is at https://github.com/iot49/rpc-server/tree/master/lib/simpleRPC.

Bernhard

On Sat, Jul 20, 2019 at 3:49 AM Jeroen F.J. Laros notifications@github.com wrote:

Perhaps we can think about a dedicated repository for a CircuitPython client?

I am also interested in how you implement asynchronous calls and multiplexing. Perhaps we can add these ideas to the core library.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jfjlaros/simpleRPC/issues/4?email_source=notifications&email_token=AAW5XJHJX5566NRWAODJ3TLQALUTDA5CNFSM4H7KUOA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2NLZZY#issuecomment-513457383, or mute the thread https://github.com/notifications/unsubscribe-auth/AAW5XJGLLZ2G4URLJEAKG2LQALUTDANCNFSM4H7KUOAQ .