NetStamp project

XCore Project reviews, ideas, videos and proposals.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.
Contact:

Post by leon_heller »

Sounds a bit like the transputer. That had an external memory interface and could run an OS.


Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

leon: "Sounds a bit like the transputer"

Exactly. How wonderful that would be.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Oh the irony ;-)
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Here's a question, forget using external memory for a moment (for reasons already stated). How much on package memory would be enough?
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

There is no answer to that question. There is never enough RAM:)

But in this modern world I'm seeing a lot of embedded devices, control systems, monitoring systems etc etc that are happily soaking up 128/256MB of RAM and running Linux on an ARM. Then they have to surround themselves with other devices to handle the real-time stuff. I guess we are unlikely to that on a single chip any time soon.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Hmm are you assuming the use of an OS like Linux (or any OS) for example?

My assumption is the opposite, in an event based system no OS.

This could make a big difference about memory assumptions
User avatar
skoe
Experienced Member
Posts: 94
Joined: Tue Apr 27, 2010 10:55 pm
Contact:

Post by skoe »

Just my opinion: I don't need no OS. At least not in the classical sense like e.g. uClinux. That's just bloat for small embedded systems. If somebody uses this on a 128 or 256 kByte system I think it's just proof of concept.

But of course it depends on how much of the definition of an OS a software fulfils. What you told about the Amino Stack sounds a bit like an OS already. Or one could say that some aspects of an OS are implemented in the XMOS hardware (e.g. share processing power between up to n * 8 threads, communicate between processes)

And btw: Most OSs are event based :) It's called interrupts, signals, messages, sockets, pipes or whatever. Didn't implement stuff which had to poll anything actively for long. Most of the time it's something similar of posix select() (oh, I know this name...) and handler code respond to this event (signal, message, packet, software interrupt). The only difference is that XMOS can do this in hardware by using event vectors.

To come back to the memory size (w/o OS): In a project I worked a while ago we had 64 kB flash and 4 kB SRAM. It contained an FS, parser code for commands coming from UART including texts for error messages etc. An implementation for a proprietary protocol stack, some bit banging for a proprietary bus, a boot loader for in field updates. This took the whole memory. No OS, no Display UI.

This is what could be done with an single- or dual core XMOS, too. But larger code, e.g. use a Display UI could be realized with any kind of VM and (possibly slow?) external or internal memory. For this I don't expect to need MBytes, but maybe several 100 kBytes. But I don't need a quad core XMOS.

I'm sure something useful can be done with the netstamp as is. It could be dynamically loaded code modules like Folknology suggested or a "slow" VM (e.g. ZPU) which could even run from the serial flash.

Edit: This all is no criticism of XMOS. It's good as it is. I know how expensive SRAM is and that flash memory can't be produced with the current process. I only talk about about possibilities using the current hardware.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

I wouldn't really compare Amino to an OS even a light weight RTOS primarily because:

1) The scheduler is the hardware so we don't need one, although you could dedicate several threads to produce virtual low priority threads, but these could be just a HSM's not part of the "system"
2) We aren't really having to deal with realtime threading because realtime is built in.
3) We are not using virtual memory except when we load say a ZPU as a HSM, and then that's private to that HSM rather than being a systems function.
4) We don't envisage a file system although a FAT32 HSM could be dynamically loaded, again its not system wide, but would be HSM private.
5) We don't have device drivers instead we use HSMs, I understand the similarity of course, but these are not the same thing.
6) We don't have inter-process communication, this is handled by channels in a decentralised fashion.

In fact distribution is the key here rather than centralisation, you couldn't even term it a nano-kernel because it isn't even system centric in nature except for a code repository. To me the key point is Operating systems have always been about resource sharing, Event driven systems like XS1 with multicores and hardware threads enables us to move from resource scarcity to resource abundance, those resources are now distributed across nodes and joined by channels. The trend indicates a likely increase on this vector, hence Amino is also aligned with this thinking.
Heater
Respected Member
Posts: 296
Joined: Thu Dec 10, 2009 10:33 pm

Post by Heater »

No I was not assuming the use of an operating system. Well not necessarily. As you say there is not much need for one within the XMOS chips. There we have threads and channels and an event mechanism already.

But what about that big blob of code that I might want to put into external RAM and execute from a VM running on a single xcore thread? Or without a VM, xcore code executed from an external RAM with a dedicated bus. That big blob of code could well do with some OS to organise things. Who cares? Could be FreeRTOS or ecos or whatever the designer wants.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm
Contact:

Post by Folknology »

Well you could certainly run FreeRTOS (its already ported to XS1) on a single thread and have it do this, perhaps pulling its code from SPI memory for example. I guess the real question is apart from running legacy code or emulation why would one architect an Xmos solution in this manner? what would be the benefit given the extra memory overhead etc... I could probably benefit from a good example Rowan any chance you can provide one to help me get my head around it.
Post Reply