[Atmel studio] won't accept !==

[tggzzz]

The oversampling is done in software, you just sample over and over and average. An array could keep more of a rolling average if you have the ram. My current algorithm just adds many samples to a temporary variable and then shifts to divide.

Oversampling relies on the noise having a random distribution. Are you sure that is the case in your system?

Alternatively you can ensure it is random: add known pseudorandom noise at the input, digitise, and subtract the known noise digitally. That's the basis of spread spectrum systems.

Aphorism: If you know how to optimise, then do it. If not, then randomise".

[Simon]

Well it's always a trade-off between speed, silicon size and flexibility.

[exit_failure]

The oversampling is done in software, you just sample over and over and average. An array could keep more of a rolling average if you have the ram. My current algorithm just adds many samples to a temporary variable and then shifts to divide.

If you have a rolling average, you don't really need that much memory, takes eight samples by summing them in one variable, rightshift 3, store that in another varieable, take another 8 samples , rightshift 3, take the average of that and the previous average and store to the second variable

a mockup code might look like this

Code: [Select]

unint16_t eightSamples = 0;
unint16_t  rollingAverage = 0;
uint8_t colletedSampleCount = 0;

//the interrupt routine would be something like:

if(colletedSampleCount  < 8) {
    eightSamples += sampleFromADC;
    colletedSampleCount++;
}
else {
    uint16_t average = eightSamples >> 3;
    if(rollingAverage == 0) {
        rollingAverage  = average;
        eightSamples = 0;
        colletedSampleCount = 0;
    }
    else {
        rollingAverage  = (rollingAverage  + average) >> 1
        eightSamples = 0;
        colletedSampleCount = 0;
    }
}

Of course you'd have to have all of those variables eight times (exccept colletedSampleCount maybe) and, as you said, maybe in an array. But it would need a lot less memory than 8kB per channel or am I overlooking something?[/code]

[tggzzz]

Well it's always a trade-off between speed, silicon size and flexibility.

I'm not sure what you are referring to there. If it is my point about randomness, then no. If anything, it would be a trade-off between valid and not valid.

[sleemanj]

If you have a rolling average, you don't really need that much memory, takes eight samples by summing them in one variable, rightshift 3, store that in another varieable, take another 8 samples , rightshift 3, take the average of that and the previous average and store to the second variable

I don't think that works.

1
1
1
1
1
1
1
1

1
1
1
1
1
1
1
1

1
1
1
1
1
1
1
100

What is the average of this sequence of 24 numbers, ( (8 + 8 + 7 + 100) / 24) = 5.125

What is the average of this sequence using your adding mean-of-eight algorithm

   First 8, mean 1, set rolling average mean = 1
   Next 8, mean 1, set rolling average mean = (1 + 1) / 2 = 1
   Final 8, mean 13.375, set rolling average mean = (1 + 13.375) / 2 = 7.1875


Don't worry, I made essentially the same mistake, and rs20 corrected me, just paying it forward...
https://www.eevblog.com/forum/microcontrollers/absolute-value-of-1000-sample/msg1203405/#msg1203405

[Mechatrommer]

You'll need 3x 32bit variables.. adc_total, adc_count, adc_average. All init to zero except adc_count set to number of averaging required. After each adc reading.. adc_total = adc_total + adc - adc_average, adc_average = adc_total / adc_count... 12 bytes ram, 1 add 1 sub 1 div... further tweak possible...

[Bassman59]

Nope, i have never had to use != before.

Have you considered actually reading a book on C? Obtaining some form of formal programming education? ... reading basically any code in the wild?

I have two books, "Programming in C" which is very long winded and constantly makes reference to examples pages away and has a lot of stuff that is PC related and not really helpful on a µC. I also have "The C pragramming Language" by the language authors themselves, this is so concise that it misses essential bits out expecting me to make assumptions.

So the latter is useless much of the time as it lacks a complete description of the practical implementations and does not even give comprehensive syntax explanation and the former means that by the time I have read the bits I don't have any interest in as not µC related I loose the plot for the bits I may need if i can remember all of the garbage I just read. Using the book as a reference is hard as it's so wordy and diluted nothing can be found with ease.

I could do with a different book i guess that is more embedded orientated. As for formal education I aw doing a pointless HNC in electrical engineering because my boss still remembers the good old days when he went to uni and actually learnt something.

First, “orientated” is not a word. At least not in English. C

Practical C Programming is really pretty good. A lot of the stuff you need with micros is there, such as bit-twiddling and masking, and it’s not specific to any platform. It talks about pointers and how and when to use them. One thing to keep in mind is that you can’t use dynamic memory allocation (malloc() and free(), say) on an 8-bit micro. You can and should use pointers when you need to.

For embedded stuff, it always boils down to this. Peripherals live at particular memory locations. Reading from, say, the ADCVAL address returns the most recent conversion results. Writing to the UART_TX register loads the transmitter and starts the hardware shifting out. The rest is really just housekeeping. The micro vendor likely supplies a header file that defines all of the registers that are used to access the peripherals, and that header file should have #defined bit masks and constants that enable you to make sense of what you are reading and writing.

The rest of what you’re doing, say averaging ADC samples, is the same on a micro as it is on a desktop computer.

[Simon]

8K of RAM is 16 bit oversampling for a 10 bit ADC and hardly worth doing.

What I currently do is have a 32 bit variable and use a for loop to run enough samples after each readitg I do:

32_bit_var = 32_bit_var + ADC_result

After exiting the loop I bit shift.

Now doing this takes a lot of time most of it waiting around for the ADC so i am trying to making it more "multithreaded". I can use an array being the fastest way to stick a value in a place to empty the ADC result register or I can do the same old addition and when a seperate variable that keeps count of the number of samples taken hits the top I bit shift the sum I already have and move on to the next channel.

I do also wonder if i can do a rolling average by retaining my 32 bit variable taking a new reading, shifting that reading to be of equivalent magnitude, adding it to the 32 bit variable and the dividing by 2 (bit shift again).

[exit_failure]

You could implement your array like a ring buffer, giving you a nice method of calculating your rolling average:

Setup:

Code: [Select]

//storage for the last 8 values
uint16_t buffer[8][8] = {0};
//storage for the rolling sums
uint32_t currentSum[8] = {0};
//storage for the position in the buffer
uint8_t head[8] = {0};

//initilise all with 0 or use global/static variables, otherwise there might be random crap in there



The interrupt routine would be something like:

Code: [Select]

uint8_t interruptNo = 0;

//store the oldest value in a temporary variable
uint16_t oldHead = buffer[interruptNo][head[interruptNo]];

//get the value from your ADC's register overwriting the 'oldest' value in the array
buffer[interruptNo][head[interruptNo]] = getValuefromADC();

//Calculate the new rolling average
currentSum[interruptNo] += buffer[interruptNo][head[interruptNo]];
currentSum[interruptNo] -= oldHead;
uint16_t rollingAverage = currentSum[interruptNo] >> 3;

//do whatever you want with the average here

head[interruptNo]++;
if (head[interruptNo] >= 8) {
head[interruptNo] = 0;
}




Memory usage single channel: (2*8 + 4 + 1 + 2 + 2) bytes= 25 bytes (+overhead, +padding if aligned)
Memory usage eight channels: 25 bytes * 8 = 200 bytes (+overhead)

Overall I woldn't think that this shouldn't use much more than 500 bytes of memory including overhead and padding.




I still don't really understand how the oversampling uses 8kB of RAM. Could you maybe explain that to me or point me in the direction of some documentation?

[Simon]

http://ww1.microchip.com/downloads/en/AppNotes/doc8003.pdf

If you do the working out, if I was crazy enough to do 16 bit sampling with the 10 bit ADC I need to take 4096 readings that each require 2 bytes each.

IF i want to have a constant rolling average on THAT channel I need a dedicated array to that channel that i cycle through. This is all worse case paranoia. If i am doing 13 bit sampling I only need 64 samples and 128 bytes of RAM. Or I just add each new value to an accumulator variable in which case for 16 bits I only need a 32 bit variable or 4 bytes of RAM. This is probably more sensible and does allow for a fully automated and free running ADC routine that will just update global variables as they become available.

[Mechatrommer]

I still don't really understand how the oversampling uses 8kB of RAM. Could you maybe explain that to me or point me in the direction of some documentation?

also available in http://www.ti.com/lit/an/slaa694a/slaa694a.pdf page 4... few bytes is all it takes to achieve that, except if we want to keep N number of over sampled data, then memory requirement will be 2 x N bytes + the few bytes...

[donotdespisethesnake]

a small reminder and clear syntax examples just make life a little easier. one character wrong and all sorts of errors come up in compilation. I am not a machine reading the book I am a human

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler

Hmm, I've seen quite a few fools struggle with the former, and many self-claimed "good programmers" writing cryptic gibberish, so I would rephrase that

“Any good programmer can write code that a computer can understand. Exceptional programmers write code that humans can understand.”

Oh, and don't forget the +++ operator.

Concatenating operators is genius though, I expect to put it into my next language. Then !&& is the NAND operator, !|| is NOR.

[Mechatrommer]

Cryptic gibberish is required in resource limited system to get the most. Even the native machine code is cryptic gibberish.

[hamster_nz]

There is stylish code, there is cryptic gibberish, and then there is the somewhat avant-garde.

For your wonderment, I submit mac.h, from V7 UNIX:

Code: [Select]

/*
 * UNIX shell
 *
 * S. R. Bourne
 * Bell Telephone Laboratories
 *
 */

#define LOCAL static
#define PROC extern
#define TYPE typedef
#define STRUCT TYPE struct
#define UNION TYPE union
#define REG register

#define IF if(
#define THEN ){
#define ELSE } else {
#define ELIF } else if (
#define FI ;}

#define BEGIN {
#define END }
#define SWITCH switch(
#define IN ){
#define ENDSW }
#define FOR for(
#define WHILE while(
#define DO ){
#define OD ;}
#define REP do{
#define PER }while(
#define DONE );
#define LOOP for(;;){
#define POOL }


#define SKIP ;
#define DIV /
#define REM %
#define NEQ ^
#define ANDF &&
#define ORF ||

#define TRUE (-1)
#define FALSE 0
#define LOBYTE 0377
#define STRIP 0177
#define QUOTE 0200

#define EOF 0
#define NL '\n'
#define SP ' '
#define LQ '`'
#define RQ '\''
#define MINUS '-'
#define COLON ':'

#define MAX(a,b) ((a)>(b)?(a):(b))

WHILE/DO/OD, LOOP/POOL and REP/PER/DONE have to be considered an outstanding efforts in trying to make a tool fit in with long-established thought patterns that have disappeared.

I was thinking the other day about all the knowledge and skills that have been lost going from mostly tape based batch processing to online systems. The ability to process large volumes of nearly offline-data with minimal resources starts to sound quite a bit like "map-reduce" and other big data paradigms.

[Mechatrommer]

...and then there is the somewhat avant-garde....

Code: [Select]

#define OD ;}
#define FI ;}


VB/Pascal guy want to make a better world?  some prominent people should have thought to make pic and avr cross compatible... virtually not physically...

Code: [Select]


;/////////////////////////////////////////////////////////////////////////////////////////////////
;// microchip compatible opcode
;/////////////////////////////////////////////////////////////////////////////////////////////////

.macro return ;clock = 4/5
    ret
.endm

.macro retlw;(val) [W = val] ;clock = 5/6
    ldi W, @0
    return
.endm

.macro retfie ;clock = 4/5
    reti
.endm

.macro goto;(addr) ;clock = 2
    rjmp @0
.endm

.macro decfsz;(reg) ;clock = 2 (not skip), 3 (skip)
    dec @0
    brbs SREG_Z, (PC+2)
.endm

.macro incfsz;(reg) ;clock = 2 (not skip), 3 (skip)
    inc @0
    brbs SREG_Z, (PC+2)
.endm


and then there are more user friendly less cryptic gibberish...

Code: [Select]


.macro clearBitW;(bit) ;clock = 1
    cbr W, (1 << @0)
.endm

.macro clearBitF;(reg, bit) ;clock = 1
    cbr @0, (1 << @1)
.endm

.macro clearBitR;(io, bit) ;clock = 2
    cbi @0, @1
.endm



;/////////////////////////////////////////////////////////////////////////////////////////////////
;// status and arithmetic
;/////////////////////////////////////////////////////////////////////////////////////////////////

.macro setCarry ;clock = 1
    sec
.endm

.macro clearCarry ;clock = 1
    clc
.endm



.macro rotateLeftW ;[rotate left W through carry @ rlf] ;clock = 1
    rol W
.endm

.macro rotateLeftF;(reg) [rotate left reg through carry @ rlf] ;clock = 1
    rol @0
.endm

.macro rotateLeftR;(io) [rotate left io through carry @ rlf] ;clock = 3
    setValueWR @0
    rotateLeftW
    setValueRW @0
.endm



.macro rotateRightW ;[rotate right W through carry @ rrf] ;clock = 1
    ror W
.endm

.macro rotateRightF;(reg) [rotate right reg through carry @ rrf] ;clock = 1
    ror @0
.endm

.macro rotateRightR;(io) [rotate right io through carry @ rrf] ;clock = 3
    setValueWR @0
    rotateRightW
    setValueRW @0
.endm


just a few snip taken from the miscellaneous "avr_gen_01_asm.inc"

[donotdespisethesnake]

Cryptic gibberish is required in resource limited system to get the most.

Yes, I've seen that lazy excuse used by poor programmers many times. It's not even true.

[Mechatrommer]

Yes, I've seen that lazy excuse used by poor programmers many times. It's not even true.

yeah just because its not in your reality or you are C# programmer programming Structured Query Language all the time doesnt mean it doesnt or shouldnt exist.

[Cerebus]

Yes, I've seen that lazy excuse used by poor programmers many times. It's not even true.

yeah just because its not in your reality or you are C# programmer programming Structured Query Language all the time doesnt mean it doesnt or shouldnt exist.

Speaking as a man who cut his teeth on mainframes with less memory than many a typical System-On-a-Chip microcontroller, often including the disk arrays (8Mb disk packs anyone), and instruction cycle types measured in microseconds, yet which still managed to concurrently run compilers, database systems, application programs and a few on-line users, I find myself having to side with donotdespisethesnake. Cryptic crap is just that, there's no excuse, no matter how limited your systems resources for that type of coding style. It is lazy, and shows scant regard for the poor bastards who have to read or maintain your code after you get yourself killed by insisting that it's more 'efficient' and 'saves resources' to not look both ways before crossing the road.

A 30Mb disk drive from the era I'm talking about:

[tggzzz]

Yes, I've seen that lazy excuse used by poor programmers many times. It's not even true.

yeah just because its not in your reality or you are C# programmer programming Structured Query Language all the time doesnt mean it doesnt or shouldnt exist.

Speaking as a man who cut his teeth on mainframes with less memory than many a typical System-On-a-Chip microcontroller, often including the disk arrays (8Mb disk packs anyone), and instruction cycle types measured in microseconds, yet which still managed to concurrently run compilers, database systems, application programs and a few on-line users, I find myself having to side with donotdespisethesnake. Cryptic crap is just that, there's no excuse, no matter how limited your systems resources for that type of coding style. It is lazy, and shows scant regard for the poor bastards who have to read or maintain your code after you get yourself killed by insisting that it's more 'efficient' and 'saves resources' to not look both ways before crossing the road.

A 30Mb disk drive from the era I'm talking about:...

You beat me to it in all respects, but then I don't bother correcting Mechatrommer.

In my case the fastest instruction time was 576us (==0.5ms==2kIPS), and the backing storage is shown below. Yes, that is 35mm film, complete with sprocket holes (A significant portion of the movie industry was just up the road from the computer manufacturer!)

or
https://www.flickr.com/photos/sbell/3380330082

[TomS_]

I have yet to encounter a 3-character operator.

You havent tried JavaScript yet have you. 

[Mechatrommer]

...I find myself having to side with donotdespisethesnake. Cryptic crap is just that, there's no excuse, no matter how limited your systems resources for that type of coding style.

if you talking about lack of comment then i have to agree. but even given enough commenting, there are codes you cannot simply read without having the proper material in hand. if a programmer with graphics or data security background dead, there is no way (or will take months or years at least) for your young programmer with pure computing background to handle let alone improve the demised code. from "human readable" point of view of functioning of the program. even programmer with the same background sometimes.. try reading quake's code without reading the documentation and tell me how'd they do it this and this? maybe we are talking about different semantics here.

[Simon]

I'm trying to use descriptive variable and definitions to make it more legible later.

[sokoloff]

As each conversion ends the end of conversion interrupt will fire and the value in the ADC result register will be put into the current location in an array. For as long as the array location used is not the last location the ADC will be restarted, and the array location incremented before exiting the routine. Once the array is full the ADC will no longer be started.
The ADC must be first started externally with the array location reset to “0” and the desired channel selected. To check if the array is full and ready to read a new set of values from, test the current array location in use.

Tip: declare the “location in use” variable as volatile.

[hans]

...I find myself having to side with donotdespisethesnake. Cryptic crap is just that, there's no excuse, no matter how limited your systems resources for that type of coding style.

if you talking about lack of comment then i have to agree. but even given enough commenting, there are codes you cannot simply read without having the proper material in hand. if a programmer with graphics or data security background dead, there is no way (or will take months or years at least) for your young programmer with pure computing background to handle let alone improve the demised code. from "human readable" point of view of functioning of the program. even programmer with the same background sometimes.. try reading quake's code without reading the documentation and tell me how'd they do it this and this? maybe we are talking about different semantics here.

I think you're confusing domain specific knowledge and crap code here. There is no excuse for crap code. If one can only make programs work with crap code, it highlights the incompetence. Further down the road you're guaranteed you won't be able to maintain it, let alone someone else.

Some fields like cryptography, compression, machine learning, etc. are driven by  theoretical computer science based fields, and it will take some time to get up to speed in that kind of code. We're all human after all. But crap code only hinders the adoption effort, and although a common occurrence, introduces the suggestion that a massive project needs a "rewrite". Then during a rewrite, people will write down the exact same formulas and matrix manipulations down, perhaps with a few twists here and there depending on the personal style of a programmer.

[Mechatrommer]

yes crap code can be a different meaning to cryptic gibberish to my understanding. if you are talking about very ill thought codes from the beginning, that need constantly changed/fixed without proper refactoring, then yes its definitely an incompetency. i believe a competent (experienced) programmers should be able to make a very well thought out codes from beginning and know how and when to refactor properly. this is simply a distinguishing between a novice and experienced programmers, a natural thing that happened.