> So it's a pain to rebase... Anyone know what's required to get the base PR
> merged?
Where is your PR?
I was able to auto-merge your branch with upstream devel with no immediate
problems, but only tested a hello world, didn't test all the POSIX stuff.
The question of how to separate the different options is fraught... It would be
great to be able to specify --os:esp-idf and have it work as
That's a good list! But the LwIP and FreeRTOS <=> POSIX brigde requires support
in the Nim standard library to make using Nim sockets/selects/etc libraries
possible.
The port on my branch with networking supports the LwIP, and some of the VFS
via the normal POSIX API's (uart, select, etc). The
The other option is that I may re-apply my changes to 1.2.4 branch and just
develop from there as the "stable" version.
@dponyatov suggests a list of features for embedded
[https://github.com/nim-lang/needed-libraries/issues/81](https://github.com/nim-lang/needed-libraries/issues/81)
suggests it support newlib+FreeRTOS+FAT32+lwip esp-idf specifically provides
newlib,freertos,lwip and 'vfs' which is a filesystem
> Have you given the selectors module a try? It should provide an even nicer
> API on top of the raw POSIX select.
Oh actually that is what I'm using, not the raw posix.select. I meant to say
that wrapping the esp32 libraries in Nim was far enough along to provide access
to the posix.select,
Excellent! It'd be great to get some help. I've got a number of changes for
wrapping a few ESP libraries that could probably be brought out into another
package. Also the branch is pretty out of date and needs some rebasing.
> Currently I'm using Nim on an ESP32 with posix.select for a custom TCP
> protocol.
Have you given the selectors module a try? It should provide an even nicer API
on top of the raw POSIX select.
this is fabulous, thanks for your hard work! I work a lot with the esp, and it
would be such a dream to have first class nim support. I'll check this out and
contribute as much as i'm able
Nice! I'll check it out a bit. Async should be ok on many embedded platforms.
Especially if async is the standard for asynchttp and other protocols. ESP32's
have 328kB of ram and dual 240 MHz cores. Plenty enough for async http servers,
even if it requires ORC that'd be fine. Though nimcsp
There is also [https://github.com/zevv/nimcsp](https://github.com/zevv/nimcsp)
which is better suited for embedded development, it deserves more attention and
development.
I've add a bit of documentation to my main example project, with networking
(ethernet):
[https://github.com/elcritch/esp32_nim_net_example](https://github.com/elcritch/esp32_nim_net_example)
> For stdlib's async you need --gc:orc and Nim devel, otherwise it leaks
> memory. Sorry, I hope we can get 1.2.2 out soon! The good news is that we're
> also planning an async more suited for embedded.
Ah, that makes sense. I look forward to 1.2.2! A better async for embedded
would be great.
> P.S. while the "hello world" http server is working, it currently blows up
> after about ~22 requests. Anyone got suggestions?
For stdlib's async you need `--gc:orc` and Nim devel, otherwise it leaks
memory. Sorry, I hope we can get 1.2.2 out soon! The good news is that we're
also planning
P.S. while the "hello world" http server is working, it currently blows up
after about ~22 requests. Anyone got suggestions?
@Clonk \-- Debugging on JTAG should work with Nim sources as the stack traces
are using Nim source maps. Though sometimes I disable it as tracking at the C
code level is
@Yardanico oh thanks!
@Clonk, it would be nice to support those but are outside the scope of my
efforts. The ESP32 is my current target so that's why I'm going for FreeRTOS +
LwIP. Though, I've been toying with using a "embeededos" or "oslite" so other
embedded RTOS'es could use the work...
NuttX and Zephyr could be also good candidates, they support a lot of hardware.
Since they provide a decent posix API it might be easier.
Implementing [CMSIS](https://os.mbed.com/handbook/CMSIS-RTOS) , could also be
worthwhile as it is an ARM standard API implemented by several RTOS (now I just
FYI: you don't need
--exceptions:goto
--dead_code_elim:on
Run
Because:
1. ARC sets goto exceptions by default
2. Dead code elimination is always enabled nowadays
Got an example asynchttpserver running on an ESP32!
curl 192.168.1.22:8080
Hello World%
Run
You can find the example here:
[https://github.com/elcritch/esp32_nim_net_example](https://github.com/elcritch/esp32_nim_net_example)
The test example is an ESP32 project
@araq, that's great! I was hoping to do a PR, but wasn't sure if there would be
interest. It seems, LwIP and FreeRTOS support could be split. Most of what I've
done is actually port Nim sockets to LwIP. That'd mean it'd be easy to combine
Nim & LwIP on many embedded devices.
Once I get
I'm _very_ interested in this port and would appreciate PRs. Ideally even CI
support.
This is great! ESP32 is a nice platform; I've used it a bit in the past, with
C++. It'd be good to have Nim running on it.
I don't have the time to contribute right now; just offering moral support and
thumbs-up
I've made a bit more progress. I've got an example esp32 Ethernet server to
compile.
But ran into something that's not quite clear:
proc newSelectEvent*(): SelectEvent =
var fds: array[2, cint]
if posix.pipe(fds) != 0:
raiseIOSelectorsError(osLastError())
Also, it'd be cool to see how many standard Nim libraries on threads could be
extended to the ESP32 as well. That's far down the list, but how would one
integrate vTasks*** with Nim?
Hey all! I'm experimenting with an OS port for FreeRTOS, similar to that for
the Nintendo Switch. Currently I'm focusing on the esp-idf (esp32) which
includes LwIP. Essentially so far it's posix.nim with all the non-FreeRTOS
parts removed (probably 80% of it). Importantly, there's a couple
25 matches
Mail list logo
