MCU mimicking a SPI flash slave - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: MCU mimicking a SPI flash slave
On 15/06/17 09:25, Reinhardt Behm wrote:
Quoted text here. Click to load it

Good, very usable, but I'm still exploring the degree
of perfection :)

Eclipse + LLVM + GDB based.

Quoted text here. Click to load it

Yes.

Download it and have a go. In the "run configurations"
you choose between "hardware" and "emulator". I haven't
tried "emulator", but I guess it means you don't need a
devkit.

Key documents are:

- 30000 ft overview:  
http://www.xmos.com/published/xcore-architecture-flyer?version=latest
- outline of concurrency: https://www.xmos.com/published/xc-concurrency
- very readable xC tutorial:  
https://www.xmos.com/support/tools/programming?component17%653
-boards (also Farnell, and DigiKey): https://www.xmos.com/support/boards-selector
-app notes: https://www.xmos.com/support/appnotes

Re: MCU mimicking a SPI flash slave
On 15/06/17 09:02, David Brown wrote:
Quoted text here. Click to load it

Agreed. But then there are cliffs in /everything/
so it is unsurprising if this toolset also has them :)

A more interesting question is whether the limitations
are significant in a given context - and that's less
easy to quantify.

XMOS does provide some techniques (e.g. composable
and interfaces) to reduce the sharpness of the cliffs,
but not to eliminate them. But then the same is true
of ARM+RTOS etc etc.

I wouldn't regard XMOS as being a replacement for
a general-purpose processor, but there is a large
overlap in many hard-realtime applications.

Similarly I wouldn't regard an ARM as being a
replacement for a CPLD/FPGA, but there can be
an overlap in many soft-realtime applications

The XMOS devices inhabit an interesting and important
niche between those two.


Quoted text here. Click to load it

Yes, but the learning curve is very short and
there are no unpleasant surprises.

IMNSHO "thinking in CSP" will help structure
thoughts for any realtime application, whether
or not it is formally part of the implementation.


Quoted text here. Click to load it

My only contact with him was via his Elliott 803
Algol-60 compiler - and thanking him for it ~30
years later :)

Re: MCU mimicking a SPI flash slave
On 15/06/17 10:41, Tom Gardner wrote:
Quoted text here. Click to load it

Absolutely.

One point to note is that when I worked with XMOS, one of their big
features was that their architecture was so fast it could make a USB
interface and an Ethernet interface in software.  And yes, it /could/
work - but the cost in hardware threads and memory space (code and data
go in the same ram) meant that there was very little left to do anything
useful with the device.  Since then, XMOS have realised that the big
blocks are much more efficient in hardware - they now have devices with
hardware Ethernet and USB rather than making them in software.  The
devices also have much more ram.

I think XMOS should go further, and include hardware peripherals for
common features - in particular, UARTs, I2C, SPI, timers.  A simple
hardware UART peripheral is a small and easy part to make in a chip
design.  With the XMOS, you can do it in software - you can write a
nice, clear UART software block, without much coding space.  But it
takes two hardware threads - a quarter of your chip's power if you have
a small device.  Turned into cash, that's about $2 for a UART.  On a
chip microcontroller, you have lots of UARTs and they don't take
significant resources - it's a "cost" of perhaps $0.02.  For peripherals
that you often need, it is /much/ cheaper to have dedicated hardware
than to have them in software.

Quoted text here. Click to load it

Yes, there are learning curves everywhere.  And scope for getting things
wrong :-)  XMOS gives a different balance amongst many of the challenges
facing designers - it is better in some ways, worse in other ways.

Quoted text here. Click to load it

Agreed.


Agreed.


At the end of my degree course, I had the chance to stay and do a
doctorate with Professor Hoare as one of my supervisors.  But I choose
to emigrate to Norway, get married, and try to find a job.  It was the
right choice.



Re: MCU mimicking a SPI flash slave
On 15/06/17 12:04, David Brown wrote:
Quoted text here. Click to load it

Sounds very plausible, and answers one of the questions
that was on my "to be answered" list. I don't think
either of us are surprised.


Quoted text here. Click to load it

Hmmm. I understand why you are saying that, but
dayOfWeek%2==1, so I'll disagree. The questions
with such peripherals are:
- where do you stop
- switch matrix connections
- apis
The last is an extra learning curve, especially
w.r.t. configuration.


Quoted text here. Click to load it

Agreed. Horses for courses.

I feel comfortable with XMOS for bit-banging, DSP and
similar. I am unclear about having non-trivial ethernet
protocol stacks and similar.



Quoted text here. Click to load it

Curiously I made similar choices, although the
University (Southampton) and destination were
different.

Re: MCU mimicking a SPI flash slave
On 15/06/17 13:31, Tom Gardner wrote:
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

I am not sure you really /are/ disagreeing - because I agree that there
is a balance here, and "where do you stop?" is an important question.

The answer is somewhere between "I use this peripheral a lot, it is
cheap in hardware but expensive in software" and "I use this peripheral
occasionally, it is expensive in hardware but cheap in software".  I.e.,
no, there is no clear dividing point, and different developers will have
wildly different opinions.  And different hardware designers have had
different opinions too - from FPGA, through XMOS, PSoC, 68332/MPC5xxx
with TPUs, to microcontrollers with configurable pin selections.  A
common theme is that while the more flexible systems let you make
marvellously complicated peripherals that fit just right for a
specialised need, most of the time they are used for simple UARTs, SPI,
timers with capture or PWM, etc., and they are mostly very inefficient
for those uses.

And I agree that a simple peripheral is easier to use than a complicated
one, and gives an easier interface.  So if you want an 11-bit UART, and
you have an XMOS UART, it is an easy matter to change the
"NUMBER_OF_BITS" from 8 in the sample code to 11.  But a hardware UART
that is that flexible is likely to have scores of pages of register
definitions to wade through to find the right options.

Quoted text here. Click to load it

When you are the kind of nerd that is likely to end up in an ivory tower
doing all your "programming" as symbolic manipulation on a blackboard,
you don't let the chance of a lifetime with a good woman pass you by!



Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/15/2017 7:04 AM:
Quoted text here. Click to load it

I think that depends on the design.  Perhaps you are familiar with the GA144  
with 144 processors at a cost of around $0.10 per CPU.  They took a similar  
route with NO dedicated I/O hardware other than a SERDES receiver and  
transmitter pair.

It is expected that all I/O would be through software.  Along that line the  
chip boots through one of three I/O ports, async serial, SPI serial, a 2  
wire interface and I believe there is a 1 wire interface but I'm not  
certain.  Three of the CPUs can be ganged to form a parallel port/memory  
interface, two CPUs with 18 bits of I/O and the third 4 bits.  All of this  
is controlled by software.

I find the device has significant limitations overall, but certainly with a  
peak execution rate of 700 MIPS there is a lot of potential.  Much like no  
one focuses on the idea that using the 4 input LUT of an FPGA as an inverter  
is excessively wasteful, the GA144 with its 10 cent CPUs gets us out of the  
thinking that using a CPU as a UART is wasteful.

Not trying to be negative, but I see the $2 cost of an XMOS CPU as being  
excessive and wasteful.  Heck, you can buy complete MCU devices for a  
fraction of that price.


Quoted text here. Click to load it

The question is whether it is worth investing the time and energy into  
learning the chip if you don't focus your work in this realm.  Personally I  
find the FPGA approach covers a *lot* of ground that others don't see and  
the region left that is not so easy to address with either FPGAs or more  
conventional CPUs is very limited.  If the XMOS isn't a good price fit, I  
most likely would just go with a small FPGA.  I saw the XMOS has a 12 bit, 1  
MSPS ADC which is nice.  But again, this only makes its range of good fit  
slightly larger.


Quoted text here. Click to load it

I prefer Forth for embedded work.  I believe there is a Forth available.  I  
don't know if it captures any of the flavor of CSP, mostly because I know  
little about CSP.  I did use Occam some time ago.  Mostly I recall it had a  
lot of constraints on what the programmer was allowed to do.  The project we  
were using the Transputer on programmed it all in C.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 15/06/17 23:46, rickman wrote:
Quoted text here. Click to load it

I had a little look at the GreenArrays website for the GA144.  It
appears to be pretty much a dead company.  There is almost nothing
happening - no new products, no new roadmaps, no new software, no new
application notes.  It is a highly specialised device, with a very
unusual development process (Forth is 50 years old, and it looks it -
and these devices use a weird variant of Forth).  I think it would be a
very risky gamble to use these devices for a real project, even though
there is a lot of interesting stuff in the technology.

Quoted text here. Click to load it

Certainly - working with XMOS means thinking a little differently.  But
it is not /nearly/ as different as the GA144.

Quoted text here. Click to load it

If you have lots of experience with FPGA development, it is natural to
look to FPGAs for solutions to design problems - and that is absolutely
fine.  It is impossible to jump on every different development method
and be an expert at them all - and most problems can be solved in a
variety of ways.

Quoted text here. Click to load it

Available for what?  The XMOS?  I'd be surprised.

Quoted text here. Click to load it

Occam has its own advantages and disadvantages independent of the use of
CSP-style synchronisation and message passing.

I have looked at Forth a few times over the years, but I have yet to see
a version that has changed for the better since I played with it as a
teenager some 30 years ago.  The stuff on the GA144 website is absurd -
their "innovation" is that their IDE has colour highlighting despite
looking like a reject from the days of MSDOS 3.3.  Words are apparently
only sensitive to the first "5 to 7 characters" - so "block" and
"blocks" are the same identifier.  (You would think they would /know/ if
the limit were 5, 6 or 7 characters.)  Everything is still designed
around punch card formats of 8 by 64 characters.

I can appreciate that a stack machine design is ideal for a small
processor, and can give very tight code.  I can appreciate that this
means a sort of Forth is the natural assembly language for the system.
I can even appreciate that the RPN syntax, the interactivity, and the
close-to-the-metal programming appeals to some people.  But I cannot
understand why this cannot be done with a modern language with decent
typing, static checking, optimised compilation, structured syntax, etc.



Re: MCU mimicking a SPI flash slave
On Fri, 16 Jun 2017 13:21:03 +0200, David Brown

Quoted text here. Click to load it

The versions shipped by the professional companies have changed a lot.
The major commercial suppliers are Forth Inc and MicroProcessor
Engineering. See
  http://www.forth.com
  http://www.mpeforth.com

Forth does not suit everyone, but it has changed a lot since you
were a teenager.

Stephen

--  
Stephen Pelc, snipped-for-privacy@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 16/06/17 15:55, Stephen Pelc wrote:
Quoted text here. Click to load it

I had a look.  No, FORTH has not progressed that I can see (unless you
think adding colour to the editor is a revolution).  Some FORTH
compilers might be good at producing optimised code on microcontrollers,
but that is an improvement in the implementations, not the language.



Re: MCU mimicking a SPI flash slave
On Fri, 16 Jun 2017 16:34:55 +0200, David Brown

Quoted text here. Click to load it

We use standard editors with syntax colouring files as we have done
for decades. The professional Forth compilers, whether for
microcontrollers or for the desktop, produce optimised native
code.

The current Forth standard is Forth-2012. See:
  http://www.forth200x.org/documents/forth-2012.pdf

What you used 30 years ago did not include target code for
  USB stack
  FAT file system
  TCP/IP stack with HTTP, FTP and Telnet servers
  Embedded GUI
  and so on and so on

Having been in the Forth compiler business for a very long time,
I can assure you that the tools and libraries supplied in this
decade are vastly superior to those of 30 years ago.

Stephen

--  
Stephen Pelc, snipped-for-privacy@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 16/06/17 17:40, Stephen Pelc wrote:
Quoted text here. Click to load it

The reference to colour was for the "new" colorForth used by the GA144.  
I am not surprised you have syntax highlighting in your editors -  
/Forth/ may not have moved on, but your implementations of Forth  
toolchains seem top class and with modern features.

Quoted text here. Click to load it

Those are all libraries provided by your implementation.  That makes  
your implementation good and useful to users - it does not make the  
/language/ any better.

Quoted text here. Click to load it

Again, you are missing my point entirely.

The /language/ has not changed.  You are still stuck with a typeless  
system relying on programmers writing comments to describe a function's  
inputs and outputs.  You are still stuck on doing everything with  
"cells", that are usually 16-bit or 32-bit, or double-cells - no  
standardised way of working with data of specific sizes.  You are still  
stuck on a single word list, with 31 characters significance (the GA144  
Forth is limited to "5 to 7" significant characters) - no modules,  
namespaces or other local naming.  You are still tied to blocks of 16x64  
characters.

Some details have changed, but the language has not.


Re: MCU mimicking a SPI flash slave
On Mon, 19 Jun 2017 00:47:31 +0200, David Brown

Quoted text here. Click to load it

In the same way that C hasn't changed.

Quoted text here. Click to load it

Just like C. And I read a lot of C.

Quoted text here. Click to load it

Unless you use a library for the purpose. Just like C.

Quoted text here. Click to load it

No, not me. We use 256 character significance. The base system has
about 20 named namesspaces.

Quoted text here. Click to load it

You persist in believing that colorForth represents the state
of Forth. It doesn't. It's a one-man system for one man's use
and Chuck Moore does not pretend anything else.

Stephen

--  
Stephen Pelc, snipped-for-privacy@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 21/06/17 17:47, Stephen Pelc wrote:
Quoted text here. Click to load it

No, but that has already been discussed and there is no need to repeat it.

Quoted text here. Click to load it

No, because C is a typed language.  It is not a particularly strongly  
typed language, and some people write their C code in very weak ways  
(making everything an "int").  But it is a big step up from a typeless  
language and lets the compiler do a good deal of checking.

Quoted text here. Click to load it

C has different sized types as part of the language, not just a library.

Quoted text here. Click to load it

Very good.  I was commenting here specifically on Forth as found on the  
GA144 toolchain, but I am glad you have namespaces and long identifiers.

Quoted text here. Click to load it

Again, the context has been Forth on the GA144 - and that /is/  
colorForth.  But again, I am glad to hear that it is not the state of  
Forth in general.


Quoted text here. Click to load it


Re: MCU mimicking a SPI flash slave
On Mon, 19 Jun 2017 00:47:31 +0200, David Brown

Quoted text here. Click to load it

I haven't used blocks for decades. You are deeply misinformed.

Stephen

--  
Stephen Pelc, snipped-for-privacy@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 21/06/17 17:50, Stephen Pelc wrote:
Quoted text here. Click to load it

That was from information from the GA144 website.

Quoted text here. Click to load it


Re: MCU mimicking a SPI flash slave
On Wed, 21 Jun 2017 19:16:08 +0200, David Brown

Quoted text here. Click to load it

You are still deeply misinformed. Surely it's up to you to
do your own research rather than blather "fake news" across
the interwires. </g>

Stephen

--  
Stephen Pelc, snipped-for-privacy@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 21/06/17 20:00, Stephen Pelc wrote:
Quoted text here. Click to load it

It is safe on Usenet - it is the best self-correcting medium :-)

I am quite happy to learn that modern mainstream Forth does not use
blocks at all, and that the Forth used by the GA144 is a bit weird,
old-fashioned, limited and niche compared to the Forth versions more
commonly used in embedded programming.

(Have you looked at the GA website and read their stuff?)


Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/22/2017 5:24 AM:
Quoted text here. Click to load it

It is odd that you rely so much on subjective/emotional words to describe  
what you like or don't like about a language.

--  

Rick C

Re: MCU mimicking a SPI flash slave
David Brown wrote on 6/16/2017 7:21 AM:
Quoted text here. Click to load it

Yeah, I don't know of any product using the GA144.  I looked hard at using  
it in a production design where I needed to replace an EOL FPGA.  Ignoring  
all the other issues, I wasn't sure it would meet the timing I've outlined  
in other posts in this thread.  I needed info on the I/O timing and GA  
wouldn't provide it.  They seemed to think I wanted to reverse engineer the  
transistor level design.  Silly gooses.

I don't know why the age of a computer language is even a factor.  I don't  
think C is a newcomer and is the most widely used programming language in  
embedded devices, no?

The GA144 is a stack processor and so the assembly language looks a lot like  
Forth which is based on a stack processor virtual machine.  I'm not sure  
what is "weird" about it other than the fact that most programmers aren't  
familiar with stack programming other than Open Boot, Postscript, RPL and  
BibTeX.


Quoted text here. Click to load it

"A little" is a *lot* larger learning curve than any other MCU I am aware of  
(the GA144 aside).  My point is that can be worth it only if you do a lot of  
designs that would make use of its unique features.  I'm not sure there  
really is a very large sweet spot given that the chips are not sold at the  
low end and other devices will do the same job using existing techniques and  
tools.


Quoted text here. Click to load it

Yes, but you don't need to know a "variety" of ways of solving problems.  
You only need to know ways that are highly effective for most design problems.

The many misconceptions of FPGAs relegate them to situations where CPUs just  
can't cut the mustard.  In reality they are very flexible and only limited  
by the lack of on chip peripherals.  Microsemi adds more peripherals to  
their devices, but still don't compete directly with lower cost MCUs.


Quoted text here. Click to load it

You seem obsessed with your perceptions of the UI rather than utility.  I  
don't have a problem with large fonts.  Most of the designers of the system  
are older and have poorer eyesight (a feature I share with them).  The use  
of color to indicate aspects of the language is pretty much the same as the  
color highlighting I see in nearly every modern editor.  The difference is  
that in ColorForth the highlighting is *part* of the language as it  
distinguishes when commands are executed.  Some commands in Forth are  
executed at compile time rather than being compiled.  This is one of the  
many powerful features of Forth.  ColorForth pushes further to allow some  
commands to be executed at edit time.  I have not studied it in detail, so I  
can't give you details on this.

I just want to explain how you are using very simplistic perceptions and  
expectations to "color" your impression of ColorForth without learning  
anything important about it.


Quoted text here. Click to load it

You can't understand because you have not tried to learn about Forth.  I can  
assure you there are a number of optimizing compilers for Forth.  I don't  
know what you are seeing that you think Forth doesn't have "structured  
syntax".  Is this different from the control flow structures?

I see Stephen Pelc responded to your posts.  He is the primary author of VFX  
from MPE.  Instead of throwing a tantrum about Forth "looking" like it is 30  
years old, why not engage him and learn something?

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 16/06/17 20:22, rickman wrote:
Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

The age of a language itself is not important, of course.  The type of  
features it has /are/ important.

Many things in computing have changed in the last 4 decades.  Features  
of a language that were simply impossible at that time due to limited  
host computing power are entirely possible today.  So modern languages  
do far more compile-time checking and optimisation now than was possible  
at that time.  Good languages evolve to take advantage of newer  
possibilities - the C of today is not the same as the pre-K&R C of that  
period.  The Forth of today appears to me to be pretty much the same -  
albeit with more optimising compilers and additional libraries.

Quoted text here. Click to load it

Even for a stack machine, it is very limited.  In some ways, the 4-bit  
MARC4 architecture was more powerful (it certainly had more program space).

But this is all first impressions from me - I have not used the devices,  
and I am /very/ out of practice with Forth.

Quoted text here. Click to load it

For a programmer who is completely unfamiliar with FPGA and programmable  
logic, the XMOS is likely to be less of a leap than moving to an FPGA.

But I agree it is hard to find an application area for these devices - I  
have only had a couple of uses for them, and they probably were not  
ideal for those cases.

Quoted text here. Click to load it

True.


FPGAs have their strengths and their weaknesses.  There are lots of  
situations where they are far from ideal - but I agree that there are  
many misconceptions about them that might discourage people from  
starting to use them.

Quoted text here. Click to load it

I am merely highlighting what the GA144 website seems to view as being  
modern innovations in the Forth toolchains.

Quoted text here. Click to load it

If your eyesight is poor, use a bigger screen or a bigger or more  
legible font - that's fine.  But it does not make sense to use that as  
the basis for designing your toolchain - just make the IDE configurable.

Quoted text here. Click to load it

It is syntax highlighting.

Quoted text here. Click to load it

You get that in other languages too.  True, it is not always easy to  
determine what is done at compile time and what is done at run time, and  
the distinction may depend on optimisation flags.

But really, what you are describing here is like C++ with constexpr code  
shown in a different colour.

Quoted text here. Click to load it

I've read the colorForth FAQ, such as it is.  I also note that the  
website is dead.

Quoted text here. Click to load it

I fully understand that there are good optimising Forth compilers and  
cross-compilers.  But those are good /implementation/ - I am talking  
about the /language/.

Quoted text here. Click to load it

I am not "throwing a tantrum" - I /am/ engaging in discussion (including  
with Stephen).

I am talking about how Forth appears to me.  I have worked with a wide  
range of languages, including various functional programming languages,  
parallel programming languages, assembly languages, hardware design  
languages, high level languages, low level languages, and a little Forth  
long ago.  I have worked through tutorials in APL and Prolog.  I am not  
put off by strange syntaxes or having to think in a different manner.  
(It might put me off /using/ such languages for real work, however.)  
When I talk about how Forth appears to me, it is quite clear that the  
language has limited practicality for modern programming.  And if that  
is /not/ the case, then it certainly has an image problem.

Site Timeline