Making XMOS really Open will build community, reduce delays

[Folknology]

Not sure what your client is, but there are versions of Git for most operating systems at the Git Home page that you point to.

This tutorial is also useful if you don't want to buy a book

I believe there are also plugins for IDEs like Eclipse which may help if you prefer them

regards
Al

[dave]

We (XMOS) have discussed open-source again in the last few days. We have always planned to provide most of our software as open-source - and to remain primarily a chip supplier. This is taking us longer than we expected - but the plan hasn't changed.

We intend to move our applications software development to an open-source repository - probably github.com/xmos.

We also intend to move most of our tools. The C and C++ compilers are already open source as they are based on LLVM. We are currently moving the XC compiler to LLVM.

We will be using the same software license as LLVM for both tools and applications. This is the Illinois/NCSA license - it is a permissive license that allows use for commercial purposes and has no obligation to publish derivative work. We have devised a similar license for our hardware designs.

I think that what we are planning will be complementary to the proposed foundation open-source plans but I'd be happy to discuss ways we can work together.

[Folknology]

This is fantastic news Dave

Any idea on time-scales?

regards
Al

[russf]

Yes, that is great news on all fronts. Thanks for letting us know, David.

Ideally XMOS would setup the github as an organization, which would allow you to delegate write to a controlled group of people inside and outside the company. This would be a dream-come-true, and exactly what we have been hoping for.

The license question is still open, though I believe you have made a smart choice, Assuming the Foundation accepts the license, and then once the Foundation is incorporated, members and contributors can sign a contributor agreement that will meet everyone's needs regarding provenance of code, IP, ongoing usage rights, and code access.

I would hope for a liberal policy regarding branches from existing trunk code, to encourage community involvement and to facilitate community collaboration in the main repository. Of course, a conservative policy is needed for merging changes and extensions onto release branches/master. And ideally there would be a small group in charge of each release.

I also hope that tickets against individual components (like the TCP/IP stack, as an example) can remain mostly public in github. If we are working in the repository together, we need that kind of fine-grained communication that is also saved for posterity.

Great to hear from you on this thread, Dave. I'm hope we can all realize a massive super-additive effect from us all working together.

--r.

[lilltroll]

Any activity here??

For XDK users, and other's using LCD's.
XMOS has no real graphics lib to download.

I have written some methods that can co-op with a small-framebuffer (1 or 2) bits per pixel + linebuffer handled by the LCD driver up to 50-60 Hz frame rate. (Which is faster than the LCD-lag)
In total 2 threads. Also a small protocol that can be used by other threads on other cores to update the state of the graphic objects. (For the moment only the text). Here I need to learn how several threads can send messages to one channel-end. Has anyone written a XC plugin for that? Otherwise I search the asm examples.

Rectangles and Ellipse with fill and or boarder, (transparent is also a available colour).
You can use the rectangles as bars/meters, meaning that the rectangle can be filled with two different colours with a chosen height.
Text and char that can be showed both hor. and vert. with different colour. (You can choose to write to the frame-buffer or line-buffer.)
I also have methods connected to the touch, so you can make active buttons with text and stuff like that. I just do not know how to connect everything in a smart "global way".
Of course you can also have a mouse pointer, that changes then you press the screen.

The state of all objects is updated during the pause that the LCD does before a new frame, so the update of the line-buffer is smooth and never flickers. It also makes moving objects to become smooth, since they will move with the same pixels/frame rate all the time.
Just update the field in the structure and your object will start moving or change colour or whatever.

Can a rookie try and upload it to your GIT? I will probably do a lot of beginners mistakes and cannot guaranty any backward compatibility at all now in the beginning. But I have to begin somewhere.
In the end, the protocol should be able to update all different type of objects, and there should be some consistency of everything.

And finally a basic question - since the Xcore projects supports links to GIT :)
I now have my little GIT area.

Is the XMOS-GIT like an umbrella that connects all XMOS-GIT up loaders together, or is it a special area with it's own source-code controlled by some moderators.

Havn't read the GIT-users manual yet :oops: I have to try and error a little first so I now what I need to understand.

(Training in my own GIT space so far...)