Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Using this library with nRF9160DK, compatible with Zephyr #1

Closed
adeel1710 opened this issue Oct 21, 2020 · 3 comments
Closed

Using this library with nRF9160DK, compatible with Zephyr #1

adeel1710 opened this issue Oct 21, 2020 · 3 comments
Assignees
@parthitce

Comments

@adeel1710
Copy link

Hi , I am using the liblightmodbus library on a nordic nRF9160DK board that is connected to the external modbus communicated sensor. I had to read the holding register values from the sensors and I am tring to use the : modbusBuildRequest0304( &mstatus, 3, 1, 0, 16 ); function and use request0304 struct to transmit a modbus frame from the UART.

Is this the right way to use this library for external communication ? I am using this library for the first time and would appreciate any help in the explanation.

Regards,
Adeel.
@parthitce parthitce self-assigned this Oct 24, 2020
@parthitce
Copy link
Member

@adeel1710 liblightmodbus helps in building the modbus RTU data. Sending the data over UART/RS484/RS232, you have use UART driver API provided by Zephyr.

@adeel1710
Copy link
Author

Hi Parthiban,

Yes, I understood most of the part in the build function.
I am trying to use Zephyr UART library to send out data (basically : uart_fifo_fill() function). But I was confused as to which data field has to be exactly sent over the UART driver.
I assumed that I could send : mstatus.request.frame[] in order to send the modbus data frame out through UART.

Could you let me know exactly which field builds the complete modbus data that I could send out.

Thanks for the help :)

Regards,
Adeel.

@parthitce
Copy link
Member

@adeel1710 zephyr already got native modbus support. Closing it as won't fix!

@parthitce parthitce closed this as not planned Won't fix, can't repro, duplicate, stale Aug 15, 2022
DineshDK03 pushed a commit that referenced this issue Dec 8, 2022
@carlescufi @jhedberg
net: buf: Simplify fragment handling
3d306c1 
This patch reworks how fragments are handled in the net_buf
infrastructure.

In particular, it removes the union around the node and frags members in
the main net_buf structure. This is done so that both can be used at the
same time, at a cost of 4 bytes per net_buf instance.
This implies that the layout of net_buf instances changes whenever being
inserted into a queue (fifo or lifo) or a linked list (slist).

Until now, this is what happened when enqueueing a net_buf with frags in
a queue or linked list:

1.1 Before enqueueing:

 +--------+      +--------+      +--------+
 |#1  node|\     |#2  node|\     |#3  node|\
 |        | \    |        | \    |        | \
 | frags  |------| frags  |------| frags  |------NULL
 +--------+      +--------+      +--------+

net_buf #1 has 2 fragments, net_bufs #2 and #3. Both the node and frags
pointers (they are the same, since they are unioned) point to the next
fragment.

1.2 After enqueueing:

 +--------+      +--------+      +--------+      +--------+      +--------+
 |q/slist |------|#1  node|------|#2  node|------|#3  node|------|q/slist |
 |node    |      | *flag  | /    | *flag  | /    |        | /    |node    |
 |        |      | frags  |/     | frags  |/     | frags  |/     |        |
 +--------+      +--------+      +--------+      +--------+      +--------+

When enqueing a net_buf (in this case #1) that contains fragments, the
current net_buf implementation actually enqueues all the fragments (in
this case #2 and #3) as actual queue/slist items, since node and frags
are one and the same in memory. This makes the enqueuing operation
expensive and it makes it impossible to atomically dequeue. The `*flag`
notation here means that the `flags` member has been set to
`NET_BUF_FRAGS` in order to be able to reconstruct the frags pointers
when dequeuing.

After this patch, the layout changes considerably:

2.1 Before enqueueing:

 +--------+       +--------+       +--------+
 |#1  node|--NULL |#2  node|--NULL |#3  node|--NULL
 |        |       |        |       |        |
 | frags  |-------| frags  |-------| frags  |------NULL
 +--------+       +--------+       +--------+

This is very similar to 1.1, except that now node and frags are
different pointers, so node is just set to NULL.

2.2 After enqueueing:

 +--------+       +--------+       +--------+
 |q/slist |-------|#1  node|-------|q/slist |
 |node    |       |        |       |node    |
 |        |       | frags  |       |        |
 +--------+       +--------+       +--------+
                      |            +--------+       +--------+
                      |            |#2  node|--NULL |#3  node|--NULL
                      |            |        |       |        |
                      +------------| frags  |-------| frags  |------NULL
                                   +--------+       +--------+

When enqueuing net_buf #1, now we only enqueue that very item, instead
of enqueing the frags as well, since now node and frags are separate
pointers. This simplifies the operation and makes it atomic.

Resolves zephyrproject-rtos#52718.

Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
parthitce pushed a commit that referenced this issue Jan 19, 2024
@ycsin @carlescufi
samples: posix: uname: add Makefile to compile on POSIX OS
2cd0265 
Previously the sample was using some headers that aren't
available to the host, now we can add a `Makefile.host` to
compile the example on a POSIX OS like Linux:

```
# Go to the sample dir
cd ${ZEPHYR_BASE}/samples/posix/uname

# Compile the sample
make -f Makefile.host

# Run the binary
./build/uname

sysname[65]: Linux
nodename[65]: LAPTOP-YC
release[65]: 5.10.16.3-microsoft-standard-WSL2
version[65]: #1 SMP Fri Apr 2 22:23:49 UTC 2021
machine[65]: x86_64
```

Signed-off-by: Yong Cong Sin <ycsin@meta.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@parthitce parthitce

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@parthitce @adeel1710