Huge fan of 8bit mirocontrollers but ¿Why XMOS?

[renechawy]

Huge fan of Arduino board (ATmel, parallax boebot (PICStamp), but why XMOS so important to all folks in the forum?

[russf]

I'm a very recent convert to XMOS, but I do have a background in Occam, and the Transputer, from the 80s/early 90s.

For me it's the ability to quickly prototype software and hardware, using an integrated development system. My first week using XDE and an XC-2 board has been very encouraging, and I see a lot of promise in this technology.

XMOS devices seem able to drive hardware fast, but at the same time run higher-level code that would normally be running in user space. You don't have the same memory space as you'd have in a full system running a big OS, but often you don't need that.

I hope you have a chance to try out XMOS. The risk is pretty low, with development kits starting at $50.

[Heater]

Could be the speed. 400MIPs per processor (core) with perhaps 4 cores is a lot more than Atmel and Stamps etc

Could be the fact you can have 8 threads running on a core at the same time at 50MIPS without having to get into interrupt programming or using a complicated operating system on the chip.

Could be the ease of communication between multiple XMOS chips. No complicated hardware required or complicated comms software to write.

Could be the timing determinism of the I/O ports and program execution. Not to mention the speed of I/O being massively faster than the devices you mention.

[mio]

I had interest in what Heater said, too, and began to use XMOS.
But, to tell the truth, there is some discontent in present XMOS.

1.You must use precious 1 thread in 4 thread for the simple structure like UART.
2.Communication with channel is slower than I thought before use of it.
3.The size of SRAM is not sufficient because code and data must be shared.

However, I think that XMOS has such a charm that it isn't anxious about these. :P

[Heater]

I must admit that using a 32 bit CPU for a UART or in the XMOS case a precious thread does seem to be very wasteful.
However you can often find that something simple like a UART can be combined with one or more other simple things, depending on speed requirements, or even multiple UARTS in a single thread.
This kind of flexibility starts to win you over the typical MCU where "oh dear we've run out of built in hardware gizmos means a choosing a different member that that MCU family.

Anyway don't we have 8 threads per core to play with? That makes things look much better.

Cant' speak about channel speed but from my end it looks like the internal communication is wacky fast and the external serial links at 80Mb/s or 160Mb/s is huge. More for the parallel connections. The device I want to connect external channels to can only shift bits in and out at 5Mb/s.

Yes, RAM could always be bigger:)

[mio]

I must admit that using a 32 bit CPU for a UART or in the XMOS case a precious thread does seem to be very wasteful.
However you can often find that something simple like a UART can be combined with one or more other simple things, depending on speed requirements, or even multiple UARTS in a single thread.
This kind of flexibility starts to win you over the typical MCU where "oh dear we've run out of built in hardware
gizmos means a choosing a different member that that MCU family.
Anyway don't we have 8 threads per core to play with? That makes things look much better.

Yes, I partly agree.

XMOS give me "select-case" waiting for multiple input.
but it is slightly difficult for one who does the thoughtway of programming of regular CPU.

Cant' speak about channel speed but from my end it looks like the internal communication is wacky fast and the external serial links at 80Mb/s or 160Mb/s is huge. More for the parallel connections. The device I want to connect external channels to can only shift bits in and out at 5Mb/s.

It is a fact that the specifications of the channel are thought to be very high.
The XMOS channel is much faster than "ordinary OS" ,when they use strict synchronism between the threads.

But XMOS channel is not "The hole to which you can push data whenever you need to."
Asynchronous streaming channel has a buffer only 8 bytes(2 words) at the time of the present.
Therefore you must write an additional code when it tries to give asynchronous data delivery any further.

Because I had tried to use the channel without knowing the above, I was not able to put out the performance.

[Heater]

Interesting thoughts about channel speeds.

I reckon the channel can be a "hole" into which you push data when you want to. Provided of course that the other end is constantly sucking the data out fast enough.

The other can do that if it buffers the data ( or throws it away even) as fast as the producer is producing.

After that buffer a third thread can more slowly pick data out.

Out of interest what throughput were you aiming for ?

[mio]

>Out of interest what throughput were you aiming for ?

I wanted to get and buffer data from parallel input 8bit ADC as fast as XMOS chip can.

English is more difficult for me than xc :mrgreen:
Please let me write the example by the program.

At First, I wrote below (This is partially or pseudo code).

Code: Select all

in buffered port:32 RXD8 = XS1_PORT_8A ; // Data From ADC
out port ASYNCCLK = XS1_PORT_1K ;

int main()
{
  streaming chan c ;
  par {
    sample_from_adc(c) ;
    comsumer(c);
  }
}

// Sample From ADC
void sample_from_adc(streaming chanend c,chanend trigger)
{
     unsigned d , tmp ;
 
     clock_setting() ; // set clock provide to ADC
      while(1) {
                trigger :> tmp ; // WAIT SAMPLE START
                for (unsigned address=0;address<MAXDATAS;address++){
		   // Sample 4 datas = 32bit (Bufferd input)
		   RXD8 :> d ; 
                   c <: d ;
		   // ASYNCCLK : for speed constraint check.
                        It should be more than 1/8 (1/2*(32bit/8bit)) of samplerate.
		   ASYNCCLK <: (address & 0x01) ;
                } 
                trigger <: ENDOFSAMPLE_MESSAGE ;
      }
}

// Comsumer example , save ram
#define SIZE (0x4000 - 1) // must be all 1
void consumer(streaming chanend c)
{
   int address ;
   unsigned d ;
   while(1)
   {
      c :> d ;
      memory[address++ & SIZE] = d ;
   }
}

But, this code is too slow,
It could buffered data at most few mega sps. (I'm watching ASYNCCLK's rate with Oscilloscope).

So, I rewrote the code , below.

Code: Select all

#pragma unsafe arrays
void sample_from_adc(chanend trigger)
{
     unsigned d , tmp ;
 
     clock_setting() ; // set clock provide to ADC
      while(1) {
        trigger :> tmp ;
	for (unsigned address=0;address<MAXDATAS;address++){
		// Sample 4 datas = 32bit (Bufferd input)
		RXD8 :> buffer[address] ; 
		// ASYNCCLK : for speed constraint check.
		//            It should be more than 1/8 (1/2*(32bit/8bit)) of samplerate.
		ASYNCCLK <: (address & 0x01) ; 
	}
        trigger <: ENDOFSAMPLE_MESSAGE ;
    }
}

Without using channel, I can get data over 20Msps (ASYNCCLK is constant).
So, I don't use channel for fast data aquisition.

[mikef]

I've been using almost exclusively AVR for about 6 years, for the past year I've tended towards the Arduino Framework for many projects (simply for ease of code distribution to others).

I've tended to stay away from larger chips, either because of the cost of development tools (for instance, a real ARM JTAG), or because of the complexity of embedded operating systems (I just really don't like dealing with that stuff..). It initially took me some time to wrap my head around the XMOS architecture, but I've found the time investment was worth it.

The AVR has suited most of my needs, but, I've occasionally had projects where it just wouldn't cut it. One project I was working on recently was a dual motor controller, with path planning. Much of my code was in place on an AVR, but the AVR's clock rate wasn't high enough to count the encoder pulses and decode the quadrature encoded signals -- the XMOS is, so an $8 XMOS can replace a $7 AVR and 2 $6 encoder counters, and give me a whole lot more cycles to compute other stuff in. Sure, I'll still use AVRs for certain projects, but having the XMOS in my arsenal of tools is a huge step forward.

-Fergs

[Heater]

mio: OK looks like you have done what I was thinking with about the fastest possible data sink sucking from the channel into a buffer.

I was about to suggest the unsafe arrays but you are ahead of me:)

Like all "safe" languages I predict that with XC making it "unsafe" with pragmas like "unsafe arrays" will be very common:)