Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31544
| 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> |
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
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