Sending Fw::Buffer to Drv::Udp

[chroco]

I'm new to Fprime and I'm learning how to use ports. We have a rust driver for our radio that opens a UDP socket that accepts EDL packets and then transmits them.

For starters, I just want to be able to test this functionality within fprime using Drv::Udp with server and client threads. I am trying to properly wire the ports to use a FW::Buffer so that my radio component can pass an EDL packet (struct) to the UDP driver. To simplify this, I'm using an array of U8 instead of the edlpacket_t struct (which requires serialization) to get it working.

Unfortunately, I'm doing something wrong to set this up since it's asserting:
udpSend_out Assert: " ... fprime/Svc/BufferManager/BufferManagerComponentImpl.cpp:97" 65535 120

I've been trying to debug this with GDB but it's not breaking and stepping properly in that portion of the code.

I would appreciate any help or insight that anyone has to offer. Here is my setup:

topology.fpp:

  ...
  topology OreSatDev {
    ...
    instance udpDriver
    instance radio
    ... 
    connections OreSatConnections {
      ...
      radio.udpSend -> udpDriver.$send
      udpDriver.$recv -> radio.udpRecv 
      udpDriver.allocate -> bufferManager.bufferGetCallee
      udpDriver.deallocate -> bufferManager.bufferSendIn

instances.fpp:

  instance radio: Components.Radio base id 0x1000 \
   queue size Default.QUEUE_SIZE \
   stack size Default.STACK_SIZE \
   priority 93
  ...
  instance bufferManager: Svc.BufferManager base id 0x4400
  ...
  instance udpDriver: Drv.Udp base id 0x4D00

OreSatDevTopology.cpp:

enum TopologyConstants {
  ...
		EDL_BUFFER_SIZE = 100 * sizeof(U8),
		EDL_BUFFER_COUNT = 30
};

...

void configureTopology() {
    ...
    upBuffMgrBins.bins[3].bufferSize = EDL_BUFFER_SIZE;
    upBuffMgrBins.bins[3].numBuffers = EDL_BUFFER_COUNT;
    bufferManager.setup(BUFFER_MANAGER_ID, 0, mallocator, upBuffMgrBins);
    ...
}

...

void setupTopology(const TopologyState& state) {
    ...
		udpDriver.init(0);
		udpDriver.configureSend("127.0.0.1",1331);
		udpDriver.configureRecv("127.0.0.1",1331);
		Os::TaskString name("ReceiveTask");
		udpDriver.start(name, true, COMM_PRIORITY, Default::STACK_SIZE);
}

...

void teardownTopology(const TopologyState& state) {
    ...
    udpDriver.stop();
    (void)udpDriver.join();
    ...
}

Component/Radio/Radio.fpp:

  @ UDP send port: sends an EDL packet to the UDP driver
  output port udpSend: Drv.ByteStreamSend
  
  @ UDP recv port: receives an EDL packet from the UDP driver
  guarded input port udpRecv: Drv.ByteStreamRecv

Component/Radio/Radio.hpp

  //! UDP recv port: receives an EDL packet from the UDP driver
  void udpRecv_handler(
    FwIndexType portNum, //!< The port number
    Fw::Buffer& recvBuffer,
    const Drv::RecvStatus& recvStatus
  ) override;

Component/Radio/Radio.cpp:

	void Radio :: udpClientTaskEntry(void *ptr) {
		FW_ASSERT(ptr != nullptr);
		Radio *radio = reinterpret_cast<Radio*>(ptr);

		U8 data[80] = {0};
		Fw::Buffer buffer(data, sizeof(data));

		U8 i = 0;
		for (;;++i) {
			data[0] = i;
			printf("udpSend_out ");
			radio->udpSend_out(0, buffer);
			Os::Task::delay(Fw::TimeInterval(1, 0));
		}
	}

[zimri-leisher]

I think your problem is in Radio.cpp.

You're manually constructing a buffer when you should be getting it from your bufferManager's bufferGetCallee port. So instead of:

Fw::Buffer buffer(data, sizeof(data));

you should do

// allocate a buffer from the bufman
FwBuffer buffer = this->allocate_out(0, sizeof(data));
// check if allocation of sufficient mem failed
if (buffer.getSize() < sizeof(data)) {
    FW_ASSERT(0, buffer.getSize(), sizeof(data));
}
// write the data into the buffer
// args are: U8* arr, len of the arr, and True to stop the serialize method from writing the len of the array into the buf
Fw::SerializeStatus stat = buffer.serialize(data, sizeof(data), True);
FW_ASSERT(stat == Fw::SerializeStatus::FW_SERIALIZE_OK);

then you can send the buffer to the driver, which will send it via a socket and return the buffer to the buffer manager.

However, I would note that I'm confunsed why you seem to be declaring a thread entry point:

	void Radio :: udpClientTaskEntry(void *ptr) {

If you're constructing a separate thread yourself, instead I would recommend using a combination of ActiveRateGroup, LinuxTimer and RateGroupDriver components to run your "udpClientTaskEntry" code on a regular schedule.

[zimri-leisher]

Other than that, nice work on figuring out the various drivers and buf mans.
You are rarely supposed to directly construct Fw::Buffers. In this case, you can be sure that it wouldn't work because as soon as that buffer gets passed to udpSend, the pointer it's holding to U8 data[80] is no longer gonna be valid, because data is just a local variable in the function and has no guarantee of being accessible outside of the function.

[chroco]

That solved my problem, thank you for your help!

I'm just using the thread to figure out the UDP driver and how to pass buffers. Is there an advantage to using the rate driver and Linux timers over tasks? One of my upcoming projects is to see I can connect the rate driver to a PRU on beaglebone black.

[zimri-leisher]

Glad I could help!
There's no reason you can't make your own thread, but using rate group driver+linux timer is the idiomatic way to have some regularly scheduled execution of a code block. That way you get all the nice benefits of the FPrime system--your rate groups will warn you if things go over their cycle time, you have the option of queueing up these cycle calls, you can easily hook up more components such that they get executed on the same thread before or after your scheduled code, etc.

[chroco]

That makes sense. Which brings up a question about these queued calls. I changed the UDP client code to use the rate group driver instead of a task. I noticed that the LedBlinker example uses async input port run: Svc.Sched and works happily. However, if I try and use this same async input port in the Radio active component then Radio hangs and eventually asserts from what looks to be a full queue. Other components are still executing normally from what I can tell. If I just use a sync input port on Radio, then everything is happy. How come the Led component can get away with the async port? I don't see how it is handling any queued messages. How do I handle these queues?