Less new projects?

Non-technical related questions should go here.
User avatar
Interactive_Matter
XCore Addict
Posts: 216
Joined: Wed Feb 10, 2010 10:26 am
Contact:

Post by Interactive_Matter »

Folknology wrote: 1) Forget if its opensource or not, its moving from individually written pieces of code to code that needs to fit into modules, not only that but it is also recognised that the code will be built by a variety of folks. The same issues would occur if this was proprietary or opensource i.e. the code requirements and inter-operational overheads increase. I think your actually saying moving to a modular code base makes it harder to understand?
My claim is not that the stuff get's more complicated itself. My claim is that we changed a lot of stuff from the web site to the forum. We all know where to look for things and how find it. But if somebody joins he/she has a hard time to understand everything since a lot of knowledge about the structures is not plainly explained but hidden in the forum discussions.
I think it is just a matter of documentation and structure.

There is nothing wrong with the modules itself.
Folknology wrote: 2) Xmos as far as I am aware has always been oriented towards the expert, I have seen little evidence of any shift in that positioning irrespective of the addition of the github repository. …
That is true and there is nothing bad about that. XMOS is a tad more complicated than Arduino and I do not think it will ever be a beginners platform like Arduino (at least not without a ridiculous amount of effort).

On the other hand if you are up to the complexity you get much back. So it is worth the effort.


I personally think XMOS will always be some solution for more advanced users. But with a bit better structure we can attract more (advanced) users.


User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

I personally think XMOS will always be some solution for more advanced users. But with a bit better structure we can attract more (advanced) users.
I am afraid you may well be right, but it really doesn't have to be that way, XS1 technology could be much more accessible to a much greater audience and to a wider range of skill sets, but it requires a change in mindset from 'look how clever we are' to 'look how clever we can make you'.

regards
Al
User avatar
Interactive_Matter
XCore Addict
Posts: 216
Joined: Wed Feb 10, 2010 10:26 am
Contact:

Post by Interactive_Matter »

Folknology wrote: I am afraid you may well be right, but it really doesn't have to be that way, XS1 technology could be much more accessible to a much greater audience and to a wider range of skill sets, but it requires a change in mindset from 'look how clever we are' to 'look how clever we can make you'.
Hehe struggling with my current employer about the same problems. This would need a lot of change in most engineers (no disrespect).

But perhaps it gets easier and more promising from another point of view. Arduino also does not come from Atmel, but from - umm - Arduino.

Perhaps it is easier for somebody outside the organization to see how the great technology can be applied to be really simple. Perhaps the XMOS guys (no disrespect again) must think that complex to deal with the inherent complexity of the technology in order to solve the problems and give us the tools.

Perhaps it needs somebody unbiased to break this down to some really simple building blocks.

Which gives somebody with that will and abilities great business opportunities.

Just a thought.
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

On the other hand.

XMOS chips has a little of the benefits of a RICS processor, performance of a DSP, and a little of the flexibility of a FPGA.

I have earlier been working with development board that had both a DSP a FPGA and some type of controller for all of that. Try to build working card with that yourself.

Arduino is the first step into the MCU world, and the Aduino isn't a chip maker.

So I think compared to the large target markets, e.g. people that already have been programming embedded system, and people that have made multi layer boards, it is not a big deal.
On the other hand. If you already have been working with Code Composer Studio for several yaers, you will maybe not shift to XMOS.

But I agree of the documentation. I have learned where to find info now, but it took me a long time, and I was lucky that it was during the time when everyone was new.

It is not the lack of information, it is how to find it, and the continuity of it.
For an example I found this page yesterday by misstake.
http://www.xmos.com/xs1-library-functions
I didn't now that it could be found there, but maybe it is intended to be used with the XDE11.7

Phalt, are you new to XMOS since you took over? Can you see it from a newbies perspective?
If so, you will have a good opportunity to find the "missing links" in documentation, that people who already has the answers in there head doesn't see anymore.
Probably not the most confused programmer anymore on the XCORE forum.
User avatar
phalt
Respected Member
Posts: 298
Joined: Thu May 12, 2011 11:14 am
Contact:

Post by phalt »

lilltroll wrote: Phalt, are you new to XMOS since you took over? Can you see it from a newbies perspective?
If so, you will have a good opportunity to find the "missing links" in documentation, that people who already has the answers in there head doesn't see anymore.

I've always been a more software / web guy, so before XMOS I only had a diploma-level education on electronics and hardware so I can certainly see it from a newbies perspective!

I've taken home dev kits, tinkered with them and even thought about submitting my own projects but I never have the time.

I did struggle to find documentation to help me with getting started .
One of the things that we've done to try and tackle this is an update that improves the documentation on xmos.com greatly, you'll be seeing it live early next week hopefully.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Perhaps it is easier for somebody outside the organization to see how the great technology can be applied to be really simple. Perhaps the XMOS guys (no disrespect again) must think that complex to deal with the inherent complexity of the technology in order to solve the problems and give us the tools.

Perhaps it needs somebody unbiased to break this down to some really simple building blocks.
Well I have spent an enormous amount of time trying to do just that, as far as the software goes I think I have found ways to make it simple enough for an Arduino intermediate user or MCU developer to get there head around. However there are still some road blocks in C that could easily be solved by Xmos. Take for example Mika's link above http://www.xmos.com/xs1-library-functions to the builtins and functions required to use XS1 functionality, as far as I am aware these are only available in XC, you cannot use them in C. Also using event vectors in C is rather tricky and requires ASM macros etc.. behind the scenes. But all of this could easily be solved if Xmos had a mind to do so, these are rather trivial.

However when it comes to the hardware and packaging itself we hit the deadend, where expertise is required to overcome the obstacles. Sure a stamp dip package 48pin that Xmos have talked about forever would help, but at the end of the day they need to sell chips, which means they need their community to design projects and goods containing chips and that can only happen at a lower level with more accessible packaging. This kind of thing would be a good start:

28 pin SOIC and PDIP

Code: Select all

       __________
4B0  <[          ]> 1A
4B1  <[          ]> 1B
4B2  <[          ]> 1C
4B3  <[          ]> 1D
D+   <[          ]> 1E
D-   <[          ]> 1F
VDD  <[          ]> VCL
VDA  <[          ]> GND
CLK  <[          ]> 1G
RST  <[          ]> 1H
1O   <[          ]> 1I
1P   <[          ]> 1J
1N   <[          ]> 1K
1M   <[          ]> 1L
       ----------
Maybe multiplex Jtag TDO/TDI/TMS/TCK with 4BX and connect TRST internally to some mode pins and rst, the rest of the mode pins could be preset conveniently to fit with internal usb phy clock etc.. Flash inside perhaps quadmode based to avoid using single bit ports, power is 3v3, 1 volt derived internally.

I think folk could create some wonderful and diverse applications with such a XS1 package and simple to use C environment.

But I would imagine Xmos would look down their noses at PDIP ;-)

*Update not sure you could do the USB internally at least with the current solution as it kills to many 1 bit ports. A better solution therefore might be to use 2 4bit ports to bit bang up to 12Mhz software only USB instead. This also allows you to use lower pricing ($2-$3) for this chip as it won't cannibalise your high end chip sales. Plus experts wouldn't dream of using PDIP/SOICs in their designs ;-).

regards
Al
Last edited by Folknology on Tue Sep 27, 2011 2:07 pm, edited 2 times in total.
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

Folknology wrote: Flash inside perhaps quadmode based to avoid using single bit ports, power is 3v3, 1 volt derived internally.
Al
I believe the physics doesn't work that way.
The reason that dsPIC for an example can have an internal LDO is that the Core voltage is almost as high as the I/O voltage, the frequency is rather low, so the current is not so large.
The only option is to use a buck-converter from 3.3 to 1 V and for that you must use a "large" external inductor.
The alternative is a large power-usage and a chip that would need a large heatsink.

The thing with TMSC 60 nm process, I'm not 100% sure, but but I believe that NOR-flash memory is another process, and you will not mix them into one silicon die. (We need NOR-flash for random read acess, and it is not the thing found in USB memories or SD cards)
You need a "high voltage" to achieve quantum tunneling to erase the NOR-flash cells, and if you really need NOR flash inside you have to stack several dies, or use PoP (Package on Package)

Pleas correct me if I'm wrong, but at least I know - we cannot cheat mother nature ;)
Probably not the most confused programmer anymore on the XCORE forum.
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

Maybe it is stupid for us to judge the documentation at the moment then XDE11.7 seems to be in a Beta 1 stage (2010-09-27)
(Everything is a beta on this link at the moment)
http://www.xmos.com/development-tools-beta


XMOS, please consider to update the "Programming XC for XMOS Devices" since so much has happened since it was written, and that is the document you start to read. You need to help the reader to go further in the documentation after reading that.
Probably not the most confused programmer anymore on the XCORE forum.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

I believe the physics doesn't work that way.
The reason that dsPIC for an example can have an internal LDO is that the Core voltage is almost as high as the I/O voltage, the frequency is rather low, so the current is not so large.
The only option is to use a buck-converter from 3.3 to 1 V and for that you must use a "large" external inductor.
The alternative is a large power-usage and a chip that would need a large heatsink.
Sure I think PSOC 3 used external inductors, but you can use small hand soldered smd (or through hole) ones without a problem (VCL) , even with the LDO an external Cap would be required.
The thing with TMSC 60 nm process, I'm not 100% sure, but but I believe that NOR-flash memory is another process, and you will not mix them into one silicon die. (We need NOR-flash for random read acess, and it is not the thing found in USB memories or SD cards)
You need a "high voltage" to achieve quantum tunneling to erase the NOR-flash cells, and if you really need NOR flash inside you have to stack several dies, or use PoP (Package on Package)
At this stage I wasn't thinking about putting flash in memory map (that needs to come with XS2) rather just using existing silicon but packaging it with other silicon. I'm suggesting QuadSPI flash driven by 4bit ports in order to save on 1 bit ports. This is really just a package job rather than XS2..

regards
Al
Last edited by Folknology on Tue Sep 27, 2011 2:42 pm, edited 1 time in total.
User avatar
phalt
Respected Member
Posts: 298
Joined: Thu May 12, 2011 11:14 am
Contact:

Post by phalt »

lilltroll wrote:Maybe it is stupid for us to judge the documentation at the moment then XDE11.7 seems to be in a Beta 1 stage (2010-09-27)
(Everything is a beta on this link at the moment)
http://www.xmos.com/development-tools-beta
Oops that's supposed to be unpublished, thanks for pointing it out ;)
XMOS, please consider to update the "Programming XC for XMOS Devices" since so much has happened since it was written, and that is the document you start to read. You need to help the reader to go further in the documentation after reading that.
Noted.
Post Reply