XC-3 Roadmap

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
Post Reply
User avatar
Interactive_Matter
XCore Addict
Posts: 216
Joined: Wed Feb 10, 2010 10:26 am
Contact:

XC-3 Roadmap

Post by Interactive_Matter »

Hi,

I am currently maintaing the XC-3 AP Led Tile Controller Frimware on github https://github.com/xcore/sw_led_tile_controller

The code itself is more or less better documented (at least I inserted some some comments while understnading the code. The documentation of the whole project is an ongoing project (Still need to create a usable usage documentation in the wiki).

Nevertheless I want to do the following in the not so far future and therefore want to discuss it with you:
a) the code needs to be modularized. This involves removing the ethernet library and replacing it with the library from github (which is just an improved version, with some XC3 features missing - which need to be added)
b) separate the led driver code as library and reduce the XC-3 code to an specific application using the code. This is neccessary since the led driver solution is very flexible, enough to be potentiall integrated into other projects/environments as well.
c) Part part of the code to XC2(since this is more or less what I already did for my HL1606 project.
d) Remove or simplify the driver indirection in the source code. It currently forces all LED tile drivers to use mor or less the same port/channel interface. I would like to see that the creation of the driver is done in the main routine also so that the dirver has complete freedom which ports&channels are used. I do not think that a driver change without a XMOS reboot/firware or configuration update is really needed. Any hints for this use case? Are you using it? How would you like it to be?

There are currently still one ore another issue. So I will create a new tag and branch to also support the current version of the software until a new working version is availaible.

Any ideas what to improve also/instead? Any objections, hints or remarks?

Thanks

Marcus


Noeldi
Member
Posts: 10
Joined: Sun Jan 02, 2011 1:11 pm

Post by Noeldi »

If I ping the XC-3 board about 90% is OK but it seems there is a problem with the remain 10%
I use the firmware "LedRefDesign 10.4.1".

Code: Select all

macbook:~ reinhold$ ping 192.168.0.253
PING 192.168.0.253 (192.168.0.253): 56 data bytes
64 bytes from 192.168.0.253: icmp_seq=0 ttl=64 time=1.023 ms
64 bytes from 192.168.0.253: icmp_seq=1 ttl=64 time=0.601 ms
64 bytes from 192.168.0.253: icmp_seq=2 ttl=64 time=0.597 ms
64 bytes from 192.168.0.253: icmp_seq=3 ttl=64 time=0.530 ms
Request timeout for icmp_seq 4
64 bytes from 192.168.0.253: icmp_seq=5 ttl=64 time=0.530 ms
64 bytes from 192.168.0.253: icmp_seq=6 ttl=64 time=0.537 ms
64 bytes from 192.168.0.253: icmp_seq=7 ttl=64 time=0.628 ms
64 bytes from 192.168.0.253: icmp_seq=8 ttl=64 time=0.648 ms
64 bytes from 192.168.0.253: icmp_seq=9 ttl=64 time=0.627 ms
64 bytes from 192.168.0.253: icmp_seq=10 ttl=64 time=0.646 ms
64 bytes from 192.168.0.253: icmp_seq=11 ttl=64 time=0.645 ms
64 bytes from 192.168.0.253: icmp_seq=12 ttl=64 time=0.628 ms
64 bytes from 192.168.0.253: icmp_seq=13 ttl=64 time=0.642 ms
Request timeout for icmp_seq 14
64 bytes from 192.168.0.253: icmp_seq=15 ttl=64 time=0.534 ms
64 bytes from 192.168.0.253: icmp_seq=16 ttl=64 time=0.581 ms
64 bytes from 192.168.0.253: icmp_seq=17 ttl=64 time=0.622 ms
64 bytes from 192.168.0.253: icmp_seq=18 ttl=64 time=0.627 ms
64 bytes from 192.168.0.253: icmp_seq=19 ttl=64 time=0.855 ms
64 bytes from 192.168.0.253: icmp_seq=20 ttl=64 time=0.543 ms
^C
--- 192.168.0.253 ping statistics ---
21 packets transmitted, 19 packets received, 9.5% packet loss
round-trip min/avg/max/stddev = 0.530/0.634/1.023/0.116 ms
macbook:~ reinhold$ 
I tried it on different computers and Operating Systems (Windows7/OSX)
User avatar
Interactive_Matter
XCore Addict
Posts: 216
Joined: Wed Feb 10, 2010 10:26 am
Contact:

Post by Interactive_Matter »

I assume that there is nothing on the network which causes any packets collision?

You know - there is no guarantee for packets to be delivered …

Currently I do not have a clue what is going on.

Either it is a packet collision - or it is something in the network stack.
The official network implementation has undergone a lot of bug fixes - I hope when we can replace the local copy of the Ethernet lib with the latest version it will improve.

Do you like to help me with this?

Marcus
Noeldi
Member
Posts: 10
Joined: Sun Jan 02, 2011 1:11 pm

Post by Noeldi »

Thanks for the fast response.

There is nothing else on the Ethernet Network - so I assume there is no collision on the network.
It looks like that the receive of the ICMP is always OK:

Code: Select all

        
        // Transmit packet in direction it came from
        ethPhyTx(cTx, packet, &null);
        printstr("Ping "); printintln(Ping++);
On the XDE-Console I get always the Ping.

The actual Ethernet lib use one more Thread per Ethernet port and on the stdcore[2] all 8 are used -
so I assume it will be not so easy to port.
User avatar
Interactive_Matter
XCore Addict
Posts: 216
Joined: Wed Feb 10, 2010 10:26 am
Contact:

Post by Interactive_Matter »

Noeldi wrote:Thanks for the fast response.

There is nothing else on the Ethernet Network - so I assume there is no collision on the network.
It looks like that the receive of the ICMP is always OK:

Code: Select all

        
        // Transmit packet in direction it came from
        ethPhyTx(cTx, packet, &null);
        printstr("Ping "); printintln(Ping++);
On the XDE-Console I get always the Ping.
So you can see that the pings are received but not answered (timely) enough)?
Noeldi wrote: The actual Ethernet lib use one more Thread per Ethernet port and on the stdcore[2] all 8 are used -
so I assume it will be not so easy to port.
Not easy is not impossible ;)
Perhaps we can either shift some load to another core or see how we can adapt the ethernet solution so that it fits - but it may take some time until I find enough time to look into it. But nevertheless I do not think it is worth anything to have two distinctive ethernet implementations.

Marcus
jagspaul
Experienced Member
Posts: 117
Joined: Tue Oct 18, 2011 3:28 pm

Post by jagspaul »

Please join with us and share your knowledge regarding LED tile.
have a look on

Post subject: Make RGB LED Display with xc-3 kit more Economica
(http://www.xcore.com/forum/viewtopic.ph ... 97&start=0)

Regards
jags
Post Reply