Open liamw9534 opened 4 years ago
Thanks for this extensive work! I will need some time to review this but will come back to you
That's a great idea concerning the UART parameter. I'll make that change along with the other recommendations.
On Thu, 19 Nov 2020, 08:15 glennergeerts, notifications@github.com wrote:
@glennergeerts commented on this pull request.
In stack/framework/hal/platforms/NATIVE/README.md https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/pull/98#discussion_r526663507 :
+# Why is this useful? + +- Access to physical hardware is not always possible +- Allow application and stack to be tested independently of hardware +- Full stack debug trace can be CPU intensive on small embedded CPUs +- More rapidly try out stack or application ideas + +# Quick start + +Launch virtual serial ports using socat as follows: + +socat pty,link=/tmp/S0,raw,echo=0 pty,link=/tmp/S1,raw,echo=0 & + +Run the following command to build using the assigned device /tmp/S0 from socat above: + +cmake
-DCMAKE_TOOLCHAIN_FILE= /cmake/toolchains/gcc.cmake -DAPP_GATEWAY=y -DAPP_SENSOR_PUSH=y -DAPP_SENSOR_PULL=y -DPLATFORM_UART_DEV0=/tmp/S0 I think this is missing a -DPLATFORM=NATIVE parameter.
In stack/framework/hal/platforms/NATIVE/README.md https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/pull/98#discussion_r526667401 :
- on your Linux machine via the emulated UART layer
+# Why is this useful?
+- Access to physical hardware is not always possible +- Allow application and stack to be tested independently of hardware +- Full stack debug trace can be CPU intensive on small embedded CPUs +- More rapidly try out stack or application ideas
+# Quick start
+Launch virtual serial ports using socat as follows:
+socat pty,link=/tmp/S0,raw,echo=0 pty,link=/tmp/S1,raw,echo=0 &
+Run the following command to build using the assigned device /tmp/S0 from socat above:
Right now the fd to use for the UART is a build time parameter, which means that on one host PC it is only possible to run one node which uses UART right? Unless you have multiple build directories but this is cumbersome. I was wondering if it would not be easier and more flexible to pass the filename to use as a parameter to the binary (eg ./modem -d /tmp/S1)? This would simplify the build a bit and allow to start multiple nodes using different serial ports easily.
This is just a thought, and is not something which is blocking this PR. It can be done afterwards just as well if we decide to do so. WDYT?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/pull/98#pullrequestreview-534164129, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTRSTZBBC6UFVZJCX4WMUTSQTH2DANCNFSM4TH3BB3A .
Hi, are you still working on this PR? Do you need any help from us?
Hi Glenn,
Been a bit busy. Will try to get onto it this week during an evening!
Liam.
On Mon, 1 Feb 2021 at 07:57, glennergeerts notifications@github.com wrote:
Hi, are you still working on this PR? Do you need any help from us?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MOSAIC-LoPoW/dash7-ap-open-source-stack/pull/98#issuecomment-770652166, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTRST3DNOK45T4SHMXAAGDS4ZNHNANCNFSM4TH3BB3A .
Sure, I was just curious ;)
This PR provides some improvements to the NATIVE build support. Refer to the README.md file under stack/framework/hal/platforms/NATIVE for information on how to build and run some applications natively on Linux.
The native build supports:
There are some other changes included in this PR relating to some minor bugs I've encountered in the stack during the development of this PR. I've also extended the alp_layer to support application completion of write ALP commands in much the same manner as read ALP commands, as it led to nicer code not having to do everything explicitly through the file system layer.
This PR also has some new applications and chip support for the U-blox M8N GPS chip which will work both with the native build (if you have one of their "click" eval. boards attached to your computer via a serial port or FTDI cable) and the B_L072Z_LRWAN1 platform.