Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #52292

Re: Programming Style

From rickman <gnuarm@gmail.com>
Newsgroups comp.lang.forth
Subject Re: Programming Style
Date 2016-10-29 17:35 -0400
Organization A noiseless patient Spider
Message-ID <nv34li$pce$1@dont-email.me> (permalink)
References <nutbsn$k0a$1@dont-email.me> <ec005a6e-ef8a-4b3d-9b52-6c94338872f6@googlegroups.com>

Show all headers | View raw


On 10/27/2016 3:42 PM, Howerd wrote:
> On Thursday, 27 October 2016 19:01:36 UTC+2, rickman  wrote:
>> As I am sure many here know I am only an occasional user of Forth.  I
>> mostly use it to write test code for my hardware projects.  I don't
>> deliver code to my customers so I am free to use any language I wish.
>>
>> I find my coding style is heavily influenced by my heavy use of VHDL.
>> Forth and VHDL are diametrically opposed in philosophies I think.  So
>> I'm curious if my style is what other Forth programmers would use.
>>
>> I do try to keep my definitions small, but I am not crazy about a huge
>> proliferation of words.  Here is an example of one I am writing now.  I
>> think it works, but am not able to test it from lack of hardware, so
>> there may be bugs.  I'm just curious what people think of this style.
>>
>>
>> \ format and send write command with u1 as data and u2 as address,
>> return error flag
>> \ TRUE is passed, FALSE is error
>> : WriteCmd ( u1 u2 -- flag )
>>      HEX OVER SWAP [char] W FormatCmd2
>>      DisplayComFlush ComSendStr ComReadEcho
>>      9 ScanReply <> IF THROW_COMM_WRITE_VERIFY THROW THEN
>>      TRUE DECIMAL ;
>>
>>
>> : ReadCmd ( u1 -- u2 ) \ format and send read command with u1 as address
>>      HEX DUP ReadCmdFmt
>>      ReadCmdSend
>>      OVER = IF DROP ELSE ReadVerErr THEN
>>      6 ScanReply
>>      DECIMAL
>>      ;
>>
>> : VerReadLoop ( reg, n, sel -- )
>>      SelectCmd 0 DO I OVER WriteCmd DROP
>>          DUP ReadCmd 2DUP <> IF
>>              2DUP CR ."*** verify error *** read - " h.
>>              ."  : expected - " h. THEN
>>          DROP
>>      LOOP ;
>>
>> The words ReadCmd sends a command to read hardware and gets a response
>> which is left on the stack.  WriteCmd is similar, but verifies the
>> command was received correctly and leaves a flag on the stack.
>>
>> I'm not providing code for the lower words because they were written at
>> a time when I didn't trust my system comms and added a *lot* of error
>> checking code.  I found the problem in the hardware and some of the
>> error checking got ripped out while other remains.  It is pretty
>> inconsistent and ugly.  No time or need to fix it now as the test system
>> is being used for the last time now.
>>
>> --
>>
>> Rick C
>
> Hi Rick,
>
> Your code looks a lot like any of my code - the important thing is that you have defined the two interface words that you can test independently, then a test loop that calls them.
>
> The fact that you re-wrote your first version is also very Forth-like ;-)
>
> My style of Forth is very user-centric - give the user what they need to talk to the hardware - then improve it until you run out of time or get bored...
>
> Testing hardware like this is amazingly more productive that the usual C/Eclipse/IDE style where you spend so much time constructing a test harness that you have forgotten what you were trying to test. Well I have forgotten it, anyways.
>
> Best regards,
> Howerd

This was prompted by a problem with the test fixture for the boards I 
build (or have built for me actually).  I went up to the contract 
assembler yesterday and ran some of the test code and found the problem. 
  The most likely candidate for problems is always the 
electro-mechanical parts.  The test code created a repetitive pattern on 
the signals of interest so I could follow the path which led back to the 
FPGA.  So the culprit seemed to be the FPGA.  Replacing that required 
flashing the new part and this hasn't been done in some six years, which 
means there's always a chance I didn't have the right version (I've lost 
two computers in that time).  I verify showed the existing FPGA contents 
matched the file I had, so we were good to go.

The assembly folks replaced the part, I reprogrammed it and we were able 
to continue to test boards.  :)

The test guy was interested in what I was using so I tried explaining 
Forth to him.  He had used C and C++ but didn't seem to have a great 
perspective on it all as he was asking me if I was doing "Windows" 
programming.  So I showed him how easy it was to define new words, but 
I'm not sure it sunk in.

-- 

Rick C

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Programming Style rickman <gnuarm@gmail.com> - 2016-10-27 13:01 -0400
  Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-10-27 12:42 -0700
    Re: Programming Style rickman <gnuarm@gmail.com> - 2016-10-29 17:35 -0400
      Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-11-01 02:05 -0700
        Re: Programming Style luser droog <mijoryx@yahoo.com> - 2016-11-02 06:23 -0700
          Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-11-02 09:15 -0700
          Re: Programming Style hughaguilar96@gmail.com - 2016-11-02 12:15 -0700
            Re: Programming Style Howerd <howerdo@yahoo.co.uk> - 2016-11-03 06:40 -0700
              Re: Programming Style alex <alex@rivadpm.com> - 2016-11-03 22:28 +0000
  Re: Programming Style anotherreepca@gmail.com - 2016-11-05 23:01 -0700
    Re: Programming Style Bernd Paysan <bernd@net2o.de> - 2016-11-27 00:18 +0000

csiph-web