Re: MCU mimicking a SPI flash slave

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.arch.embedded
Subject	Re: MCU mimicking a SPI flash slave
Date	2017-06-21 13:08 +0200
Organization	A noiseless patient Spider
Message-ID	<oidjs9$b47$1@dont-email.me> (permalink)
References	(21 earlier) <oib6je$vjk$1@dont-email.me> <bea2B.1$TL4.0@fx04.am4> <sjc2B.3$Ik7.2@fx39.am4> <oic0ap$sl1$1@dont-email.me> <iEi2B.153$122.141@fx47.am4>

Show all headers | View raw

On 21/06/17 01:58, Tom Gardner wrote:
> On 20/06/17 21:28, David Brown wrote:
>> On 20/06/17 18:46, Tom Gardner wrote:
>>> On 20/06/17 15:24, Tom Gardner wrote:
>>>> Overall C/C++ has (arguably) become too complex for simple
>>>> things, and (unarguably IMNHSHO!) become too poorly
>>>> specified for complex things.
>>>> Nowadays C (and even more with C++) is part of the problem
>>>> rather than part of the solution. The abstractions, which
>>>> were a useful valid advance in K&R days, have become *very*
>>>> leaky over the years with the advance of technology.
>>>
>>> Examples I've come across include such gems as...
>>>
>>> "However, many C compilers use non-standard expression
>>> grammar where ?: is designated higher precedence than =,
>>> which parses that expression as
>>> e = ( ((a < d) ? (a++) : a) = d ), which then fails to
>>> compile due to semantic constraints: ?: is never lvalue
>>> and = requires a modifiable lvalue on the left. Note
>>> that this is different in C++, where the conditional
>>> operator has the same precedence as assignment."
>>> http://en.cppreference.com/w/c/language/operator_precedence
>>>
>>> "i = ++i + 1; // undefined behavior[in C] (well-defined in C++11)"
>>> http://en.cppreference.com/w/cpp/language/eval_order
>>>
>>
>> Neither C nor C++ is a problem here.  People writing absurd obfuscated
>> nonsense
>> in their code may be a problem, but that applies in any language.
> 
> Agreed, but the differences between the two languages is a
> big hint that there are surprising and unnecessary dragons
> lurking to catch people that haven't spent several decades
> following the differences and /newly introduced/ pitfalls.

What pitfalls?  Everyone who has ever been involved in C (or C++) knows
that expressions like "i = ++i + 1;" are classic examples of undefined
or unspecified behaviour.  There is never a reason for writing such
things in code, and it is always unclear to the reader (even in later
C++ standards where some cases now have defined ordering).  Just don't
write such silly code - problem solved.

Later C++ standards some such cases defined behaviour - that does not
affect C, or introduce new pitfalls to either C or C++.  At most, it
makes previously undefined code into defined code - that will either fix
the broken code or leave it broken.  It will not break code that was
previously working.

If you are interested, the reason why these things are now defined in
C++ is not because anyone would ever /want/ to write "i = i++ + ++i;".
It is merely a side-effect of making certain other orders defined, where
they /are/ useful.  In particular, people have assumed that expressions
like "cout << ++i << ++i;" are fully defined - in fact their orders were
not.  But compilers helpfully /did/ follow the order that programmers
expected, and the standards have merely been updated to codify existing
practice.

> 
> Do you have any comment about the previous point about
> /some/ compilers apparently /choosing/ non-standard
> expression grammars? That seems remarkable to me.
> 

As far as I can see, the difference for C is merely which error message
the compiler will give depending on the way it interprets the
expression.  If it follows the C grammar rules for how a mixture of ?
and = is to be interpreted, the result cannot be parsed and is therefore
an error.  If it follows the C++ grammar rules (which is the
non-standard C compiler behaviour mentioned), the result can be parsed
but is a constraint violation (a bit like writing "5 = a;"), and is
therefore an error.

I don't see a significant practical difference here.

(There are plenty of other cases where some C compilers get the details
of the standards wrong - but unless you are talking about really poor
quality compilers, these will very rarely be seen in real-world code.)

> 
>>> The ability to break a compiler's legitimate optimisations
>>> by "casting away constness and volatility" (IIRC that took
>>> several years of committee deliberation as to whether
>>> it was required or forbidden behaviour!)
>>
>> "casting away constness and volatility" means writing code that
>> explicitly tells
>> the compiler "I know better than you do here, and I know it is safe to
>> break
>> rules about the code".  Either that is true, and it lets you write the
>> code you
>> want, or it is wrong and you've made a mistake - as you can do in all
>> languages.
> 
> That is problematic when a library is compiled and optimised
> assuming that the const statements are correct, and later on
> someone else in a different company uses that library in a
> way which violates those assumptions.

No, I cannot see any problem here.

If a library exports some constant data, then it is absolutely fine that
the library is compiled and optimised on the assumption that the data
never changes.  If user code casts away constness and tried to change
that data, the user code is clearly wrong.  It is wrong in the same way
that code passing -1 to a square root function is wrong, or code that
calls a sin() function but is expecting to get the results of cos().

> 
> In those circumstances the user probably doesn't know better.
> 

If the user does not know that he should not be changing data that is
specified to be constant, then the user is not qualified for the job as
programmer.

> 
>>> And of course, the amusing C++ FQA.
>>
>> Have you read it?  It is mostly misunderstandings, repetitions, outdated
>> information, or completely unrealistic code.  There are a few good
>> points in it,
>> but you have to work hard to find them.
> 
> Indeed. But not all of the points can be "wished away"; many
> a truth is spoken in jest.
> 

The FQA is not particularly funny or truthful.  (I have read it, as well
as the original C++ FAQ - have you?).

C++ certainly has plenty of flaws - it is a /big/ language.  Some of
these flaws get fixed over time in newer standards, others remain, and
yet more get introduced.  And of course there is plenty that is a matter
of taste or style.  But wild exaggeration of the problems is no more
helpful than any claim that the language is perfect.

<https://gist.github.com/klmr/5423873>

> 
>>> All of which makes the simplicity of Forth seem appealing :)
>>
>> C is mostly simple and clear (if well written).  C++ is a much bigger
>> and more
>> complex language - it has greater scope for writing good code, but
>> also greater
>> scope for making a mess.  Simplicity of a language is not necessarily
>> a good
>> thing any more than complexity is - you don't get much simpler than a
>> Turing
>> machine, but I would not want to use it for application programming!
> 
> I completely agree :)
> 
> The major problem with C/C++ is that it can't make up its
> mind whether it wants to be simple low-level and near to
> the silicon, or an expressive high-level general purpose
> applications language. Either would be valid, but in
> trying to be both it misses both targets.

One of the major problems with C/C++ is that there is no such language -
but a lot of people seem to think there is.

A lot of people find C++ works fine for one or both targets.  It is, I
think, the only language that covers such a wide range.  But it is not a
/simple/ low-level language - it is a big language, whether you use it
for low-level tasks or high-level tasks.

There is, however, no need to use /all/ of C++.  If you are writing PC
code, you will use the standard library a lot - you will use containers,
strings, etc.  But you don't use them on low-level code.  Different
parts of C++ are better suited for different needs.

C, on the other hand, is not well suited for higher level work at all.
There was a time when it was one of the better choices, because there
were so few alternatives.  But not now.

> 
> Fortunately the marketplace has decided that in most cases
> C/C++ isn't "the best" general purpose application language;
> Java, Python and similar are the future there.

Most of my embedded programming is in C, with a small (but increasing)
part C++.  Most of my PC programming is in Python.

Thread

MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-14 10:44 -0700
  Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-14 16:30 -0700
  Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-14 21:54 -0400
    Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:01 +0100
      Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 12:13 -0400
        Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 18:01 +0100
          Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 16:52 -0400
            Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 23:37 +0200
              Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:15 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 09:25 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 13:52 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-18 22:56 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:21 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 09:02 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 08:36 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 14:47 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:23 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 15:34 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:16 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 09:49 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 22:44 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 12:10 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:40 -0400
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 18:19 +0100
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 14:34 -0400
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:41 +0100
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 17:14 -0400
                Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 13:54 -0700
            Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 23:33 +0100
              Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 23:12 -0400
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-16 07:05 +0100
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 02:27 -0400
  Re: MCU mimicking a SPI flash slave Tim Wescott <seemywebsite@myfooter.really> - 2017-06-14 23:17 -0500
  Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:03 +0100
  Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 09:14 +0200
    Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 08:25 +0100
      Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:02 +0200
        Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 16:25 +0800
          Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 10:32 +0200
            Re: MCU mimicking a SPI flash slave Reinhardt Behm <rbehm@hushmail.com> - 2017-06-15 21:48 +0800
          Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:09 +0100
        Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 09:41 +0100
          Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 13:04 +0200
            Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 12:31 +0100
              Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-15 14:20 +0200
            Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 17:46 -0400
              Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 13:21 +0200
                Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 13:55 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-16 16:34 +0200
                Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-16 15:40 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 00:47 +0200
                Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:47 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:15 +0200
                Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 15:50 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:16 +0200
                Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-21 18:00 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-22 11:24 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 12:12 -0400
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-16 14:22 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 03:15 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 00:54 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 10:30 +0200
                Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 12:54 +0200
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 13:49 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:28 -0400
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 09:19 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 16:23 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-19 23:57 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:36 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 08:20 -0400
                Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-19 14:44 +0000
                Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-19 21:39 +0200
                Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-19 14:59 -0500
                Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-20 09:25 +0200
                Re: MCU mimicking a SPI flash slave Cecil Bayona <cbayona@cbayona.com> - 2017-06-20 11:50 -0500
                Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:37 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-19 22:59 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-20 00:12 -0400
                Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 10:25 +0300
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 10:44 +0200
                Re: MCU mimicking a SPI flash slave dp <dp@tgi-sci.com> - 2017-06-20 02:36 -0700
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 11:25 +0100
                Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 13:49 +0300
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 12:54 +0100
                Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 16:09 +0300
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 15:24 +0100
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-20 17:46 +0100
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 22:28 +0200
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 00:58 +0100
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 13:08 +0200
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:28 +0200
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:58 +0200
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 12:57 +0200
                Re: MCU mimicking a SPI flash slave Dimiter_Popoff <dp@tgi-sci.com> - 2017-06-20 14:19 +0300
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:19 +0200
                Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-20 12:12 +0000
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 16:48 +0200
                Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-20 21:16 +0100
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-20 23:15 +0200
                Re: MCU mimicking a SPI flash slave Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-21 07:30 +0100
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 12:54 -0400
                Re: MCU mimicking a SPI flash slave David Brown <david.brown@hesbynett.no> - 2017-06-21 19:29 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-21 15:05 -0400
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-21 21:34 +0100
                Re: MCU mimicking a SPI flash slave "Elizabeth D. Rather" <erather@forth.com> - 2017-06-21 18:04 -1000
                Re: MCU mimicking a SPI flash slave albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-22 10:26 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:56 -0400
                Re: MCU mimicking a SPI flash slave stephen@mpeforth.com (Stephen Pelc) - 2017-06-22 09:20 +0000
                Re: MCU mimicking a SPI flash slave Wasell <from_usenet@wasell.eu> - 2017-06-22 14:02 +0200
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:59 -0400
                Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-22 11:58 -0400
                Re: MCU mimicking a SPI flash slave anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-06-22 08:19 +0000
                Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-19 09:53 +0100
        Re: MCU mimicking a SPI flash slave Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-06-15 10:16 +0100
  Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 13:56 -0700
    Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-15 14:41 -0700
      Re: MCU mimicking a SPI flash slave John Speth <johnspeth@yahoo.com> - 2017-06-15 15:08 -0700
        Re: MCU mimicking a SPI flash slave Don Y <blockedofcourse@foo.invalid> - 2017-06-16 11:34 -0700
    Re: MCU mimicking a SPI flash slave rickman <gnuarm@gmail.com> - 2017-06-15 18:20 -0400
    Re: MCU mimicking a SPI flash slave edward.ming.lee@gmail.com - 2017-06-21 07:58 -0700
  Re: MCU mimicking a SPI flash slave Walter Banks <walter@bytecraft.com> - 2017-06-19 12:23 -0400

csiph-web