MCU mimicking a SPI flash slave - Page 6

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
David Brown wrote on 6/20/2017 10:48 AM:
Quoted text here. Click to load it

You are showing your ignorance of Forth.  The test code catches the errors  
at compile time same as C.

If you are going to forget tests you are doomed.  Every piece of code should  
be written to a set of requirements, each of which must be verified, usually  
by testing.  Forget a test and you have unverified code.


Quoted text here. Click to load it

See above... You don't understand Forth.


Quoted text here. Click to load it

I've never seen a C editor that would catch anything more complex than  
mismatched parentheses.  Do editors look for missing variable declarations now?


Quoted text here. Click to load it

Again, you don't understand Forth.  You use single cells or double cells.  
Forth does not specify the cell size just as C does not specify the size of  
an integer.


Quoted text here. Click to load it

Forth has cells (a word) and chars (a byte).  I don't find it to be a  
problem, but then I don't typically jump back and forth between 32 and 16  
bit processors.  What 16 bit processors do you actually use?


Quoted text here. Click to load it

No one has customers asking for simple functions.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On 21/06/17 18:54, rickman wrote:
Quoted text here. Click to load it

That is interesting to know, thank you.  I have assumed that the tests  
being discussed were run-time tests.

Do the compile time tests work correctly even for cross-compiled  
systems, where there may be different capabilities (say, different sizes  
for cells) from the host?

Quoted text here. Click to load it

I did not suggest that tests should be omitted - I suggested that  
compile-time checks are useful in addition to run-time tests.  And I  
still think that the kind of automatic compile-time checking that is  
possible with a language like C is better than having to manually write  
tests in Forth - quite simply, you need to write fewer test cases if the  
toolchain can check more things automatically.

Quoted text here. Click to load it

Yes.

(As a technicality, the IDE might do this sort of thing by running a  
program like cppcheck in the background, but it appears the same to the  
user.)

Quoted text here. Click to load it

I understand that fine.  And in a lot of C programming, it is a big pain  
that the language does not specify the size of an int - thus  
size-specific types are used (standardised in C99, but used long before  
that).  So with C you have the choice to use efficient integers whose  
size depends on the target, or integers whose size is known and fixed.

Quoted text here. Click to load it

msp430 and AVR (the AVR is 8-bit, but C "ints" and Forth cells are 16-bit).

It looks like the answer is simply that Forth does not support  
convenient portable programming across different cell sizes in code  
where you need to be accurate about your data sizes.  It is /possible/  
(see Gerry's answers), but ugly and inconvenient.

OK, that is an answer.  It is not the only language with limitations  
like that.

(It is quite possible that particular implementations of Forth, targeted  
specifically for embedded systems and cross-compilation, have extensions  
or additional word sets designed to make it easy to get exact sized  
types, to access memory in specific sized units, etc.)

Quoted text here. Click to load it


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

What exactly is the difference?  You compile a Forth program essentially by  
"running" the source code.  So you run the code that defines new words and  
run the code that tests them.

This is at such a basic level of Forth that I find it hard to believe you  
have actually given Forth anything but a cursory glance.


Quoted text here. Click to load it

More lack of knowledge of Forth.  You can use a PC as a compiler for  
embedded Forth, but it is also very common to run Forth on the target with  
the PC just being for file storage and editing.

If you can try not to tick off Steven you can go to his web site and  
download a copy that you can work with.  Same at Forth, Inc.


Quoted text here. Click to load it

"it's easy to forget some tests."

Does that refresh your memory?


Quoted text here. Click to load it

Yeah, but when run time and compile time are hard to distinguish, the  
advantage goes away.

You are writing applesauce about *more* tests.  Which of the tests that  
Anton gave you were for catching the error you wrote in the code?  None  
specifically and all in general.  No extra tests needed.

I would suggest at this point you stop trying to trash Forth based on what  
you thought you learned and instead give Forth a real go.  Come here if you  
have questions and I'm sure you will get plenty of help.

Oh, the only real reason I know of for not using Forth is the lack of Forth  
programmers for hire.  Notice I said "for hire".  There aren't many experts  
out there to bring in quickly if you have a problem.  But it is not hard to  
train someone to use Forth, at least according to many here.  The language  
is great and many have done lots with it.


Quoted text here. Click to load it
 >
Quoted text here. Click to load it

Sounds like the territory someone here was complaining about of the false  
positives as code is typed in.  I wonder how they keep from flagging stuff  
you are creating by going back and forth in code as you think?


Quoted text here. Click to load it

Forth programmers often develop what they need.  I don't see many discussing  
the issues of porting between AVR and ARM.  I guess they don't often need  
that.  Am I wrong?  Mr. Pelc would be one to ask.  He has developed Forth  
for a very wide range of systems with many different word sizes from 8051 to  
Pentiums.  Same for Forth, Inc.


Quoted text here. Click to load it

See above.




--  

Rick C

Re: MCU mimicking a SPI flash slave
On 21/06/17 20:05, rickman wrote:
Quoted text here. Click to load it

An interesting PoV, with some merit.

However, having developed in both Smalltalk (=Forth
for this argument) and Java (=C for this argument),
I know I am /much/ more productive in Java.

By "productive" I mean the time to find other people's
libraries to do hard and complex tasks, use those
libraries, compile and test until the program runs
acceptably.

A prime reason is that the "self-checking" built
into the Java language enables both tool support
(i.e. accurate refactoring and accurate "IDE
control-space") and very rapid development of a
wide range of libraries.

Most other people agree with those sentiments;
that's why Java is so dominant now, and Smalltalk
and LISP are academic niche languages.

(Annoyingly, some youngsters want to throw the
advantages away in the interests of "programming
with fewer keystrokes").

Re: MCU mimicking a SPI flash slave
On 6/21/17 9:05 AM, rickman wrote:
Quoted text here. Click to load it
...

It's quite easy to write code that compiles perfectly but the logic is  
wrong. Most applications require extensive testing even though they  
compile without error.

Quoted text here. Click to load it

You write the application to run on the target, respecting its  
facilities and requirements. Cross-compilers accommodate these things,  
and the good ones support an umbilical to help you test your program  
interactively just as though it were running on the host.

Quoted text here. Click to load it

Correct. An the important tests are the ones that test the functionality  
of the application, not trivial compile-time issues.

Quoted text here. Click to load it
...


Compile-time checking happens, but cannot check the kinds of logical  
errors that thorough functional testing can test. The kinds of  
compile-time checks that Forth generally does not do (e.g. type  
mismatches) are, in my experience, easily caught is preliminary  
functional testing, and not major issues.

Quoted text here. Click to load it

No, but the serious errors aren't detectable by compilers, in my experience.

Quoted text here. Click to load it

So does Forth.

...

Quoted text here. Click to load it

In practice, dealing with chars, cells, and double-cells is quite  
practical. FORTH, Inc. has a fairly vast amount of code that runs  
without change on 8- 16- and 32-bit processors. As our main business is  
with microcontrollers, we have not yet felt pressure to address 64-bit  
systems yet, but do not anticipate serious problems there.

Quoted text here. Click to load it

Open Firmware addressed that by adding some data types with specific  
bit-widths. It was straightforward to do. But in the embedded work I've  
been involved with we haven't really found a need to do that.

Quoted text here. Click to load it

We see both of those a lot. We use a 16-bit cell on those, and have  
8-bit operators in addition.

Quoted text here. Click to load it

Over 90% of the code we run on AVRs and ARMs is portable.

Quoted text here. Click to load it

There have been times when we have used doubles on 32-bit systems for  
portability to/from 16-bit systems. The most prominent example is in the  
output number conversion words, <# # #S #> etc., which are defined to  
work on doubles. Open Firmware made special cell-wise equivalents (with  
different names, of course), as that standard did not support smaller  
cell sizes. It's a perfectly reasonable accommodation, and trivial to  
implement.

Quoted text here. Click to load it

Yes, if that's the requirement we'd probably use doubles, depending on  
other requirements of the project. The added inefficiency is trivial. In  
the 90's, FORTH, Inc. and MPE developed an extensive amount of code for  
smart card terminals using the full range of processors, from 8051's to  
x86's. For that project we standardized on a 32-bit cell size for a  
variety of reasons, and managed to write primitives on the low-end  
processors that were quite civilized in performance, even doing Triple  
DES and RSA. Our terminals ran quite a lot faster than the current  
Java-based ones in use here in the US.

Cheers,
Elizabeth

--  
Elizabeth D. Rather
FORTH, Inc.
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
Quoted text here. Click to load it

There is an other indication he has never run Forth. He aks for
argument number checking while in even the most simple test
argument count is implicitly tested.

Quoted text here. Click to load it

It is easy to forget some tests .. in C.
Testing in Forth means testing a small word with a few possibilities.
Testing in c means testing a larger word with possibilities that
are overlooked.

Example:
I'm experimenting with a different looping.
There are 10 words, one of which has more than one line.
There are 17 tests.
This level of testing is rare (if not unheart of) in C.

I use REGRESS similar to t{ . Anton Ertl is annoyed that I
have made my own words, but the truth is it is so easy that
only compatibility can be a reason not to roll your own.
A few dozen lines at most.

One liners with one execution path are seldomly separately
tested in C. It's too cumbersome.

Quoted text here. Click to load it

Albert van der Horst
--  
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
Albert van der Horst wrote on 6/22/2017 4:26 AM:
Quoted text here. Click to load it

The testing thing in Forth is not insignificant.  It is a great advantage to  
be able to test your code interactively (times when you can do that easily)  
and to test small functions (an advantage because other languages tend to  
have larger functions).  But the examples provided are typically the lowest  
level routines where the base words are well defined and tested over much  
use.  When the level of words increases they are more abstract.  Still they  
work like the lower level words in many ways.  But now the lower level words  
have only just been written and they may do what they were specified to do,  
but the process that developed the spec for the word can have flaws.  Then  
these low level words are not doing what the high level word needs and  
expects.  Now the testing is back to finding a bug at lower levels of code  
while testing the higher levels with all the issues that causes.

I'm not saying there isn't advantages in testing small Forth words, I'm just  
saying unit testing doesn't give a free pass at integration time which seems  
to be what some people suggest.

--  

Rick C

Re: MCU mimicking a SPI flash slave

Quoted text here. Click to load it

You have just ticked off Stephen. Steve or Steven is not my name.

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 Thu, 22 Jun 2017 09:20:06 GMT, in article < snipped-for-privacy@news.eternal-
september.org>, Stephen Pelc wrote:
Quoted text here. Click to load it

He's obviously not talking about you, but about Steven Seagal, patron saint of  
hammy actors. You _really_ don't want to tick him off.

Re: MCU mimicking a SPI flash slave
Wasell wrote on 6/22/2017 8:02 AM:
Quoted text here. Click to load it

Lol.  I can't be too mad at him for anything after he made "Under Siege".

--  

Rick C

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

Sorry.  I would have hoped for a smiley at the end of that post, Mr. Pelc.  
I think in one post I did refer to you as Mr. Pelc.  First time I typed it,  
it came out Mr. Plec.  Good thing I caught it.  ;)

--  

Rick C

Re: MCU mimicking a SPI flash slave
Quoted text here. Click to load it

No.  Why would I care about the stage?  In Forth, it does not incur a
time delay to do it in the testing stage.  Of course, in C that may be
different, and you might ask why C compilers and linkers are so slow.

Quoted text here. Click to load it

Which test patterns would that be?  The test patterns I wrote for
FLOOR5 are designed to test the values, not the stack depth; of
course, the stack depth is tested in the course of testing the values.
Or are you trying to move the goal posts towards correctness proofs by
writing about "tools" instead of "compiler"?

Quoted text here. Click to load it

Sounds like an excuse for C programmers who don't test at all.

Quoted text here. Click to load it

That is contrary to my experience.  E.g., in a Factor workshop the
static type checker successfully prevented me from completing a task
that would have been a breeze in Forth.  It was a pretty small task,
and I spent an hour or so fighting with the type checker before the
time ran out.  Expense: an extra hour, and a failed task.
Productivity: zero.

Quoted text here. Click to load it

When you don't have any code to start with, and want to focus on
something else, insisting on perfect code for something you are not
focusing on is an unwelcome distraction.

Quoted text here. Click to load it

For what?

Quoted text here. Click to load it

That's the theory, in practice it is treated as an alternative.
That's what the gcc people apparently did, and that's what you also
argued for above ("Why would someone bother writing test patterns
...").

Quoted text here. Click to load it

There have been discussions about standardizing memory accesses to
8/16/32/64-bit values for quite some time, but they have not yet
produced a final result.  There also seems to be little urgency.  It
seems that Forth users who want to do such things are happy with
the system-specific ways to deal with that.

Anyway, the usual way if you expect 32-bit values and a 16-bit system
would be to use doubles.  If that is time-critical code and you want
to port it to a 32-bit system, you would rewrite it for the 32-bit
system (maybe using conditional compilation).

Anyway, if we standardize one of the proposals for the memory access
wordset, and these 32-bit values are in some network packet (in
little-endian order) and are to be stored in another network packet
(also in little-endian order), a piece of code involving your floor5
computation might look like this:

packet1 offset + l@ lle l>d dfloor5 lle packet2 offset + l!

[BTW, how do you deal with the little-endian issue in your portable C
code?]

In the code above the 32-bit data is represented by a double on the
stack (L>D just sign-extends if necesary).  On a 32-bit machine a
sufficiently sophisticated compiler (not that much sophistication
needed with the DMAX-using version of DFLOOR5) could notice that the
high cell of the whole computation is dead, and reduce the amount of
actual computation to that of the single-cell case.

I don't expect that Forth compilers will ever do that, because doubles
are rare, and the need to optimize them is even rarer.

Quoted text here. Click to load it

Thought so.  I.e., an unrealistic requirement that does not occur in
practice is the basis of your claim of C superiority.

In practice, while I was using a system with 16-bit cells, I rarely
used doubles (i.e., 32-bit values).  These days I only use 64-bit and
32-bit systems, and again, I rarely use doubles, and very rarely in
time-critical code.  And when I use doubles, it is often because I
need double-cell integers (independent of cell size), not because I
need a particular bit width.

- anton
--  
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
We've slightly trimmed the long signature. Click to see the full one.
Re: MCU mimicking a SPI flash slave
On 19/06/17 05:54, rickman wrote:
Quoted text here. Click to load it

To snip many points and bring together a few comments you made...

Quoted text here. Click to load it


 > You seem to think there is something lacking in the Forth language, but you  
don't say what that would be.

You have previously asked me to give you xC
code snippets. When I provided direct references
to xC concepts illustrated by /easily/ digestible
code snippets, you completely ignored them.

I know it wouldn't be a good use of my time to
/poorly/ duplicate /existing/ information in an
attempt to "enlighten" you.


Quoted text here. Click to load it

 From your statements about what you /don't/ know, it
appears you haven't seriously used modern languages
i.e. those developed since the early 90s.[1]

In that case it is to be expected that you don't
understand the valid points made by David Brown
and others.

Quoted text here. Click to load it

David Brown is making important and useful points.
You have indicated probably reasons why you don't
understand them. That's fine; we can't all be
competent in everything, and I'm sure you are very
competent within your experience.


[1]  I'll note these facilities enabled by Java
significantly exceed those offered by C/C++/etc,
but Java isn't relevant in this context.

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

I suppose I have a bias...

I don't like creating a system then finding
/a late stage/ during testing that it fails due
to /occasionally/ missing timing constraints, or
having livelock issues.

I prefer a toolset that alerts me to those problems
at the /earliest/ opportunity. If there's a cliff, then
I can choose another route, or carefully walk along
the clifftop or simply jump off :)

The XMOS toolkit falls into the latter category.


Re: MCU mimicking a SPI flash slave
On 6/14/2017 10:44 AM, John Speth wrote:
Quoted text here. Click to load it

Thanks all for the suggestions and stories.  We decided to take the safe  
route and design in a SPI flash with an MCU-controlled switch that will  
switch between external and internal access.  We figured the expense and  
certainty of the HW design is less than the time and uncertainty of the  
SW design.

We figured that with enough time end effort plus a worthy DMA engine, we  
could make an MCU SPI slave look like SPI flash, but with some  
yet-to-be-learned challenge.  We didn't have the time.

JJS


Re: MCU mimicking a SPI flash slave
On 6/15/2017 1:56 PM, John Speth wrote:
Quoted text here. Click to load it

Dealing with the timing of the hardware interface (which, IMO, is all you've
*tried* to address with this approach) misses most of the bigger issues that
can arise.

[Disclaimer:  you've not told us anything at all about the Datakey's size,
how it is actually *used* -- as an "online" store (both written AND read)
or as a simple "batch" storage device (insert datakey, press button on
customer device, wait for idiot light to go out, remove datakey), etc.]

Presumably, it is used to stored configuration data and/or "reports"/logs.

The wireless link represents another opportunity for the key to be
"withdrawn" asynchronously (wrt whatever "normal usage procedure" is
imposed).

If the customer device treats it as a bit-bucket, there's no guarantee
that the data written is actually being delivered to the remote (wireless)
device (i.e., interference can corrupt the link at any time, the remote
device could be off-line, etc.).

If the customer device reads data from the datakey (e.g., to verify its
contents), you can only report a locally cached copy of those contents
(cuz you can't query the remote node in the time between address
specification and data read out on the SPI bus).  Can you guarantee that
the customer device will always write any datakey contents BEFORE it
tries to read them IN THIS SESSION?  (i.e., it writes to datakey #6
on tuesday then expects to read from it again on wednesday)

What do you do if you can't access that (previously written) data AT ALL?
Report "No Key Present" (i.e., LOFO released)?

If the customer device writes data, do you fake "WIP" until you know
that the data has traversed your wireless link?  What if the wireless
link takes longer (e.g., noise, busy, etc.) than any "WIP timeouts"
in the customer device will tolerate?

The Datakey has its own notion of atomic operations (per the SPI
interface).  Do you mimic these in your wireless protocol?
E.g., if the customer device writes a single byte, do you forward
that command to the remote device (so it can know that only the
addressed byte is altered and not the entire FLASH page)?
If the device writes X to location N and then writes Y to that same
location (before you've had a chance to inform the remote node
of the X write and receive acknowledgement), do you discard the
first (X) write on the basis that the second (Y) write will
overwrite it?

(The what-ifs are innumerable)

Retrofitting an interposed communication channel to an interface that
wasn't designed with "unreliable" communications in mind is fraught
with opportunities for things to misbehave -- in dubious ways
("Why isn't it working properly?")

And, we won't even address the issues where the customer gets a "brainstorm"
and thinks "Hey, we can put an A/DC on the remote node and use this
hardware interface in ways that we hadn't previously imagined!!"  :>

[My point in all this is to make sure you don't focus on the small
problem of interfacing a few electrical signals to your new device at
the risk of missing the other issues that can/will creep in after
you've cobbled the hardware together]

Re: MCU mimicking a SPI flash slave
Sorry about not being clear describing my endeavor.  My only concern was  
the difficulty of making the MCU look like SPI flash.  All other  
functionality is not a problem.

JJS

Re: MCU mimicking a SPI flash slave
On 6/15/2017 3:08 PM, John Speth wrote:
Quoted text here. Click to load it

OK.  Just "projecting" from problems I've had glomming kludges onto existing
interfaces at clients' requests:
- network interface to replace an existing disk interface
- memory served over a serial port (imagine fetching opcodes!)
- read/write disk hanging on a serial port
- write-only disk in place of a printer port
etc.

Despite the numerous disclaimers that "what you want isn't really going
to work", clients inevitably placated me with assurances that *all* they
wanted is EXACTLY what they've specified -- only to eventually complain
when they changed their software and "broke" the kludged system (because
they now had different expectations/assumptions in play) *or* bemoaned
how they had "paid for" this extra capability but only a portion of it
was actually available ("Yes, those are the limitations I mentioned
when I was trying to discourage you from this path!  You thought you
had found a clever way to get something for nothing and now realize
what you *really* bought!")

Good luck!


Re: MCU mimicking a SPI flash slave
John Speth wrote on 6/15/2017 4:56 PM:
Quoted text here. Click to load it

I will say that while you will have to meet the specs of the data flash as  
presented, I am pretty sure the data flash is meeting the same specs with a  
processor.  But they tailor the CPU to work optimally and tailor the specs  
to match the limitations of the CPU while you don't have any of that  
flexibility.

--  

Rick C

Re: MCU mimicking a SPI flash slave
On Thursday, June 15, 2017 at 1:56:44 PM UTC-7, John Speth wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

I agree with Rick that this should be an FPGA project.  We are working on s
omething similar.  Our first thought was to tap into the SD card.  But the  
SD card only receives data in batch at pre-determined interval.  During tha
t time, the device is suspended and not usable.  We really want better real
 time access.  So, we open up the box and find couple of dip32 sockets next
 to the surface mounted sram.  We would have to disable the onboard sram an
d wire up headers to a custome FPGA board.

Found a cyclone II with 64K sram.  Asking seller if he can upgrade it to 12
8K. If so, save us half of the project time.  Eventually, we can probably b
uild a DIP32 header with FPGA and SRAM.  I can't mount BGA myself, but more
 than happy to pay someone to do it.

The FPGA code is just one page (incomplete with control lines mux), just to
 see if it will fit in the cheapest Max II CPLD.

---------------------------------------------------------

library ieee;
use ieee.std_logic_1164.all;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

  
entity ram is
 port(
 P7: in std_logic;                            -- preserve upper 9 bits for  
next shift
 P6: in std_logic;                            -- preserve upper 10 bits for
 next shift
 P5: in std_logic;                            -- preserve upper 11 bits for
 next shift
 ACLK, clear, pass : in std_logic;            -- Address serial clock
 ASI: in std_logic;                           -- Address serial in
 ASO: buffer std_logic;                       -- Address serial out
 A: buffer std_logic_vector(16 downto 0);     -- Address register
 AA: in std_logic_vector(16 downto 0);        -- Address parallel in
 DCLK: in std_logic;                          -- Data serial clock
 DSI: in std_logic;                           -- Data serial in
 DSO: buffer std_logic;                       -- Data serial out
 D: buffer std_logic_vector(7 downto 0);      -- Data register
 DD: in std_logic_vector(7 downto 0)          -- Data parallel in
 );
end ram;
  
architecture arch of ram is

 begin
  
 process (ACLK, clear)
 begin
 if clear = '1' then
  A <= "00000000000000000";
 elsif (P7 = '1') then
  A(9 downto 0) <= A(16 downto 7);
 elsif (P6 = '1') then
  A(10 downto 0) <= A(16 downto 6);
 elsif (P5 = '1') then
  A(11 downto 0) <= A(16 downto 5);
 elsif (pass = '1') then
  A <= AA;
 elsif (ACLK'event and ACLK='1') then
  ASO <= A(16);
  A(16 downto 1) <= A(15 downto 0);
  A(0) <= ASI;
 end if;
 end process;

 process (DCLK)
 begin
 if (pass = '1') then
  D <= DD;
 elsif (DCLK'event and DCLK='1') then
  DSO <= D(7);
  D(7 downto 1) <= D(6 downto 0);
  D(0) <= DSI;
 end if;
 end process;
  
end arch;


Site Timeline