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


Groups > comp.arch.embedded > #31544

Re: Another STM32F103 clone?

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: Another STM32F103 clone?
Date 2023-01-17 19:42 +0100
Organization A noiseless patient Spider
Message-ID <tq6q62$3bfkt$1@dont-email.me> (permalink)
References (4 earlier) <eb5789da-2f3b-45a8-ae0d-f8fe8c8c4c1bn@googlegroups.com> <tq4r09$1uu5$1@gioia.aioe.org> <065743c2-fcd8-4952-ac25-39c657d348d8n@googlegroups.com> <tq65f5$383jo$2@dont-email.me> <tq6kh9$1iaf$1@gioia.aioe.org>

Show all headers | View raw


On 17/01/2023 18:05, antispam@math.uni.wroc.pl wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 17/01/2023 06:07, Rick C wrote:
>>
>>> Maybe I didn't read the thread well enough, but I thought this was
>>> just a way to generate addresses to test RAM, no?  The only specific
>>> property I've seen is that it be "relatively prime" to the memory
>>> address space.  LFSR certainly can manage that.  Heck, a Grey code
>>> can probably manage that.
>>>
>>> With 17 bits, I can generate a PR sequence that is relatively prime
>>> to powers of 2 and of length 82,677.
>>>
>>> Am I missing something important?
>>>
>>
>> Not really, no.  Well, there's the detail that the sequence must be wide
>> enough so that it does not repeat during the testing.  A sequence with
>> length 82,677 will be fine for 128 kB flash (two bytes per element), but
>> is not scalable to a 256 kB flash test.
>>
>> But while LFSR's are nice in some use-cases, they are not the simplest
>> sequence generator for software for this sort of thing.
>>
>> One of the best is:
>>
>>         const uint32_t a = 984830993;
>>         const uint32_t b = 1267261529;
>>
>>         uint32_t pseudo(uint32_t i) {
>>                 return (a * i) + b;
>>         }
>>
>> "a" and "b" are just big prime numbers, as found from this link or by
>> googling around a bit:
>>
>> <http://compoasso.free.fr/primelistweb/page/prime/liste_online_en.php>
>>
>>
>> This gives you a sequence that is deterministic, you can jump into it at
>> any point, it has no correlation with bit numbers, addresses, etc., and
>> is extremely simple to calculate.
> 
> That is more or less one of lousy generators that I used (I had
> different constants).   For memory testing it shares the same
> problems that counters have: low order bits have short period
> that is power of 2.  When you want good randomness, they fail
> relatively simple statistical tests.  One can improve them
> or they may be good enough for some applications, but one
> should be aware of their limitations.
> 

It is not supposed to pass any statistical tests for randomness - all 
you need here is no simple correlation between the values you write and 
the address.  It is not a serious pseudo random generator, just a simple 
deterministic sequence that jumps around enough for the job, with 
insignificant costs in terms of source code and run time.

If you want to remove the power-of-two cycles of the bits (for example, 
if you want to do memory testing and check there is no short-circuit 
between address lines and data lines), include a modulo operation by 
another large prime number.





Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-08 03:30 +0000
  Re: Another STM32F103 clone? Paul Rubin <no.email@nospam.invalid> - 2023-01-08 11:38 -0800
    Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-09 03:06 +0000
  Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-09 23:23 +0000
    Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-09 17:38 -0700
      Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-13 02:28 +0000
        Re: Another STM32F103 clone? Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-15 20:09 -0800
          Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 00:43 +0000
            Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-16 19:39 -0700
              Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-16 19:44 -0700
            Re: Another STM32F103 clone? Rick C <gnuarm.deletethisbit@gmail.com> - 2023-01-16 21:07 -0800
              Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 06:04 +0000
                Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-17 00:10 -0700
              Re: Another STM32F103 clone? David Brown <david.brown@hesbynett.no> - 2023-01-17 13:48 +0100
                Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 17:05 +0000
                Re: Another STM32F103 clone? David Brown <david.brown@hesbynett.no> - 2023-01-17 19:42 +0100
            Re: Another STM32F103 clone? Paul Rubin <no.email@nospam.invalid> - 2023-01-17 11:07 -0800
        Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-15 23:47 -0700
          Re: Another STM32F103 clone? antispam@math.uni.wroc.pl - 2023-01-17 05:41 +0000
            Re: Another STM32F103 clone? Don Y <blockedofcourse@foo.invalid> - 2023-01-17 00:04 -0700

csiph-web