xcore / sc_ethernet

10/100 MII Ethernet MAC for XMOS microcontrollers
http://xcore.github.com/sc_ethernet/index.html
Other
37 stars 29 forks source link

Is it possible that XC-3 with two channels does not work? #17

Closed interactive-matter closed 12 years ago

interactive-matter commented 12 years ago

In the ap_led_tile I use two channels for rx & tx:

chan rx[2], tx[2];

par
{
  // Threads constrained by I/O or latency requirements
//the internal 3 port ethernet switch
  on stdcore[2]: {
      int mac_address[2];
    phy_init_two_port(clk_smi, p_mii_resetn, smi_0, smi_1, mii_0, mii_1);
      ethernet_server_two_port(mii_0, mii_1, mac_address, rx, 2, tx, 2, smi_0, smi_1, null);
  }
  on stdcore[2]: {
      ethSwitch(rx[0], rx[1], c_local_rx_in,
              tx[0], tx[1],c_local_tx,
              cWdog[0]);
  }

Which raises an illegal resource exception, discussed in this xcroe thread: https://www.xcore.com/forum/viewtopic.php?f=32&t=1586&start=0

The acommpanying code looks a lot like the bug reported here: https://www.xcore.com/forum/viewtopic.php?f=26&t=610&p=4527&hilit=illegal_resource#p4527

So is it possible that there is some bug with channels as arrays?

DavidNorman commented 12 years ago

I'm not sure that this can be the case, but perhaps it is. Which version of the tools are you using?

-----Original Message----- From: Interactive Matter [mailto:reply@reply.github.com] Sent: 07 December 2011 08:53 To: David Norman Subject: [sc_ethernet] Is it possible that XC-3 with two channels does not work? (#17)

In the ap_led_tile I use two channels for rx & tx:

chan rx[2], tx[2];

par
{
  // Threads constrained by I/O or latency requirements
//the internal 3 port ethernet switch
  on stdcore[2]: {
      int mac_address[2];
    phy_init_two_port(clk_smi, p_mii_resetn, smi_0, smi_1, mii_0, mii_1);
      ethernet_server_two_port(mii_0, mii_1, mac_address, rx, 2, tx, 2, smi_0, smi_1, null);
  }
  on stdcore[2]: {
      ethSwitch(rx[0], rx[1], c_local_rx_in,
              tx[0], tx[1],c_local_tx,
              cWdog[0]);
  }

Which raises an illegal resource exception, discussed in this xcroe thread: https://www.xcore.com/forum/viewtopic.php?f=32&t=1586&start=0

The acommpanying code looks a lot like the bug reported here: https://www.xcore.com/forum/viewtopic.php?f=26&t=610&p=4527&hilit=illegal_resource#p4527

So is it possible that there is some bug with channels as arrays?


Reply to this email directly or view it on GitHub: https://github.com/xcore/sc_ethernet/issues/17

interactive-matter commented 12 years ago

Yes, it looks so much the same …

I am using the latest 11.2 tools on mac (if that is important)

ajwlucas commented 12 years ago

The two port stuff hasn't had a great deal of testing.

What's the reasoning behind passing 2 rx/tx channels to the ethSwitch thread? I'm not sure if it's a limitation of the communication protocol that you can only connect a single rx and tx between the server and a client thread.

interactive-matter commented 12 years ago

Yeah, hence I am testing it in the LED Tile Application on XC-3 ;) If you have a look at the AP Led Tile there is this ethSwitch https://github.com/xcore/sw_led_tile_controller/blob/master/app_ledtile/src/ethernet/switch/ethSwitch.xc which took two channels (one for each side of the XC-3. So I placed the sc_ethernet as drop in replacement one layer below that. So the ethSwitch remained and got connected to the new sc_ethernet.

A) Do you think I can throw out the ethSwitch from ap_led_tile too? It simply routes the packages either too the other side or the internal package handler. B) no matter what the results are. But if the behaviour documented in the original forum post is still present it should be fixed ;) - if it is already fixed you can perhaps post some update to the orignal forum post

ajwlucas commented 12 years ago

I had a quick look and you don't seem to be using mac_rx() from https://github.com/xcore/sc_ethernet/blob/master/module_ethernet/src/client/ethernet_rx_client.xc in your client. The client needs to implement the other side of the server protocol.

interactive-matter commented 12 years ago

Uhm, yes, uhm, I think so …

Ok this is new to me. I think I will look into this tomorrow again (currently I am occupied with another project). Does that replace the ap_led_tile ethServer? Or at least am I right that I do not need this ethServer? I am using the ap_ethrnet_bridge as example. Is this the right source to use?

Thanks for you help

Marcus

interactive-matter commented 12 years ago

OK,

got it. I understood the mac_rx and I also think that the ethServer has to be rewritten and by that most probably looses it two rx/tx channels. That is the way to go. Nevertheless there is one thing in app_bridge I do not understand: There are packages received with mac_rx but I do not see where they are send to the 'other' side. Or this handled inside the mac_rx function for two ports?

DavidNorman commented 12 years ago

Yes. The Ethernet rx and tx servers have a built in forwarding function.

If you look in the body of the Ethernet rx server code you will find a short section of code which decides to mark a packet as requiring forwarding.

David Norman Bristol

On 11 Dec 2011, at 10:33, "Interactive Matter" reply@reply.github.com wrote:

OK,

got it. I understood the mac_rx and I also think that the ethServer has to be rewritten and by that most probably looses it two rx/tx channels. That is the way to go. Nevertheless there is one thing in app_bridge I do not understand: There are packages received with mac_rx but I do not see where they are send to the 'other' side. Or this handled inside the mac_rx function for two ports?


Reply to this email directly or view it on GitHub: https://github.com/xcore/sc_ethernet/issues/17#issuecomment-3096499