[amnb] build error with code from g071 example

[Tecnologic]

Hi all,

i'm quite new to modm an trying to evaluate if the amnb protocol is something for my application. With the great docs i started a project on the F4-disco board and used the nucleo-g071 amnb example as a base.

But when compiling i get this error:

`main.cpp: In member function 'bool Thread::update()':
modm\src/modm/processing/protothread/macros.hpp:91:22: error: jump to case label
   91 |                 case __LINE__: \
      |                      ^~~~~~~~
main.cpp:111:32: note: in expansion of macro 'PT_CALL'
  111 |                         res1 = PT_CALL(node2.request<uint8_t>(1, 1));`

The code is a direct copy of the example:

class Thread : public modm::pt::Protothread
{
	modm::ShortPeriodicTimer tmr{1s};
	uint32_t counter{0};
	Result<uint8_t> res1;
	Result<uint8_t, uint8_t> res2;

public:
	bool inline
	update()
	{
		PT_BEGIN();

		while(true)
		{
			PT_WAIT_UNTIL(tmr.execute());

			LedGreen::toggle();

			node1.broadcast(1, counter++);
			node3.broadcast(2);

			res1 = PT_CALL(node2.request<uint8_t>(1, 1));
			MODM_LOG_INFO << "Node1 responded with: " << res1.error();
			if (res1) { MODM_LOG_INFO << " " << *res1 << modm::endl; }

			res2 = PT_CALL(node1.request<uint8_t, uint8_t>(3, 2, counter));
			MODM_LOG_INFO << "Node3 responded with: " << res2.error();
			if (res2.hasUserError()) {
				MODM_LOG_INFO << " " << *res2.userError() << modm::endl;
			}
		}

		PT_END();
	}
}
thread;

I cant see the error here. PT_BEGIN is where it should be, i see no declaration of a local variable which could be uninitialized in a next case, in short i dot get what gcc is saying to me.

Is this a potential bug or is it me doing something wrong with protothreads?

Thanks

[salkinium]

Are you using GCC13 by any chance? Our protothreads macros only work with ≤GCC12 sadly.
We're therefore moving away to fibers for which there exists a backward compatible option for protothreads and for resumable functions.

Try to either use GCC12 or enable the modm:processing:protothread:use_fiber option.

[salkinium]

Ah sorry, no. The use_fiber option automatically schedules the protothreads on construction, so you should only have to replace the while(true) loop with the modm::fiber::Scheduler::run();. But there was another bug in the where the AMNB update() function got stuck in a (unnecessary) while(1) loop. I've updated my PR with another change that should unblock the fibers.

sry for all my questions, but i find it a good problem to get familiar with modm :)

No worries, I'm also interested in getting this to work with fibers! I initially wrote the AMNB for this project and achieved very throughput good results even in congestion.
But I think the code could be simplified with a proper port from protothreads to fibers. I'll hack on it more properly this weekend.

[salkinium]

Btw I tried to get this to work with fibers and it's indeed getting stuck somewhere. I think there isn't an easy fix, I'll have to debug this further. I would suggest you downgrade to GCC12 and use Protothreads for your evaluation.

[Tecnologic]

Thanks, I will continue first with pwm, ADC and then revisit this later

[salkinium]

I fixed it in the PR, turns out I implemented AMNB with two threads one for transmission and one for reception.

[Tecnologic]

I try to pull the pr and test it out!

[Tecnologic]

I read from that, that fiber is the way to go for my application?

[salkinium]

It depends on how much RAM you have available. Stackful fibers are more ergonomic since you can use local variables, but they require a lot more stack memory (particularly if you use printf), thus might not be great on smaller devices.
I recommend you measure the stack usage with the watermarking feature.

[Tecnologic]

Thanks for the reply.

I want to port my foc esc project from chibios rtos to modm, because i dont need a rtos for all the stuff but some sheduling to keep the code neat and tidy is nice. So fibers seem a good alternative for all the non control stuff.