From PIC16F690 to PIC18F26K20 + The big function!

joeyd999

Joined Jun 6, 2011
5,234
Talking about 'daylight' if I understand well what you guys mean by that...I'll say given that I sample at 4Hkz --> my daylight is 250us --> all the DSP processing must take less than 250us for each sample...
No. ErnieM's reference to 'daylight' means how many instruction cycles do you have left over after all the interrupt processing so that you main loop doesn't get starved of CPU time.


I recently had a discussion on 'general electronic chat' , thread 'Capacity ID' and it was said that by limiting the frequency at 2000Hz I will have problems with the 'consonants' meaning words with same vowels but different consonants will be confused...

I also did a little google about that...yes consonants have higher frequency compared to vowels....range ~1800hz to 2500hz or more for important consonants....

So now I'm considering 3000Hz as my highest frequency --> sampling rate will now be 6Khz...in my circuit I'm going to use a LPF to limit the highest frequency to ~3000Hz....I was thinking of sampling at 8KHz but that would give me only 125us for my DSP processing....
I think that 2khz is pushing it without a hardware mulacc solution (like in the dsPIC).

The more I help you with this, the more I realize how little understanding you have, both wrt what you are trying to do and the (limited) capabilities of the PIC18F (given what you are trying to achieve).

My advice: start small and add capability later as you/the cpu can. You're going to find that you run out of bandwidth quickly!
 

joeyd999

Joined Jun 6, 2011
5,234
So far I only have one pushbutton...

But now I'm thinking of either adding another pushbutton or using the same pushbutton with two functionalities...
what I mean is for instance a 'single press' would something and a 'double press' would do something else!

Why do I need two pushbutton? because I first want to pre-record a few words (3 to 5) into MCU using a pushbutton (I'm actually training my MCU here) and then I want to recognised them using another one!

So those pre-recorded words should not be volitale....now a question is raised! where should I store those pre-recorded words? RAM? ROM? or EEPROM?

Also, How would you modify your 'getkey' routine to control 2 or more pushbuttons? or how would you modify it for a sinle pushbutton with two functions like I explained abobe!

Using a single pushbutton would be so fun but it ain't my level yet:)

Regards, Eric
The code I gave you at:

http://forum.allaboutcircuits.com/showpost.php?p=394756&postcount=21

will work with up to eight push buttons, as is. Just modify the keymsk bits for the actual active bits, and add labels for each bit for keylst and keychg.

Modifying the code to allow for double and multiclicks, as well as press and hold, is quite easy. But I am not going to share that here (there are some methods I don't want to reveal), but feel free to give it a shot yourself!
 

joeyd999

Joined Jun 6, 2011
5,234
I will try to post a macro code for 'mult_accum' with addition tomorrow for correction....thanks!
Why macro?

I would create a subroutine that uses the FSRs as follows:

FSR0 -> Input Variables Record
FSR1 -> Constants Record
FSR2 -> Accumulator.

This way, you can call the same function for each of the seven filters, just modifying the FSRs before hand.
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
No. ErnieM's reference to 'daylight' means how many instruction cycles do you have left over after all the interrupt processing so that you main loop doesn't get starved of CPU time.
Oops! Ok

I think that 2khz is pushing it without a hardware mulacc solution (like in the dsPIC).

The more I help you with this, the more I realize how little understanding you have, both wrt what you are trying to do and the (limited) capabilities of the PIC18F (given what you are trying to achieve).
LOL...but you are not totaly wrong! When I started this thing I thought that would be cool to light some LEds with voice and if it works I could apply this to bigger thingz...and I did some crazy research...found a lil... but understanding is another problem and the more I push with it the more I realise how hard it is !

I came from far...and still going...but it will work sooner or later...

My advice: start small and add capability later as you/the cpu can. You're going to find that you run out of bandwidth quickly!
OK! Is there any PIC24 series powerful enough to do a better job? anyways I ll stick with PIC18F for a while before playing with big boyz

Thanks again
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Why macro?
Coz as for one filter, I'll have to call the 'mult_accumadd/sub' routine 10 times!! and I would need 4 temporary registers, 2 (high and low byte) for the coefficients and another 2 for the samples so each time I load one sample and one coefficient I would call that macro routine and for 7 filters there will be 70 calls...so I thought macro would be better....my bad then!

Guess our approachs were different as usual....

I would create a subroutine that uses the FSRs as follows:

FSR0 -> Input Variables Record
FSR1 -> Constants Record
FSR2 -> Accumulator.

This way, you can call the same function for each of the seven filters, just modifying the FSRs before hand.
I had something similar as well in mind...
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
The code I gave you at:

http://forum.allaboutcircuits.com/showpost.php?p=394756&postcount=21

will work with up to eight push buttons, as is. Just modify the keymsk bits for the actual active bits, and add labels for each bit for keylst and keychg.
OK!!!

Modifying the code to allow for double and multiclicks, as well as press and hold, is quite easy. But I am not going to share that here (there are some methods I don't want to reveal), but feel free to give it a shot yourself!
Hahahahah.....:D:D I like that!

it ok Sir you've already done a LOT...guess I'm becoming a bit too greedy! LOL...I'm just gona add another pushbutton....

I leave the double, multiclicks as HOMEWORK for me for Holiday!!! This is another thang I would like to do...I got lots of stuffs I would like to do...

Thanks!
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Hi All

I'm trying to get back to this old thread as I really like(d) it...
As we all know *Hardware* comes first so I tried to draw a little schematics (attached). Please have look and correct me if any errors.

The operating voltage for the PIC18F26K20 is 1.8V - 3.6V so I decided to put a variable resistor to drop the voltage instead of using a regulator just to avoid too much circuitry (Guess it shouldn't be a problem, huh?).

The mic circuit worked great in one of my previous projects so I'm going to use it again.

When I built this PIC18F26K20 component I couldn't name pins 8 and 19 with the same name "Vss" as Eagle wasn't allowing...any help on that? (There should definitely be a way). As for the footprint of it I just copied and pasted from one PIC having the same footprint and ...

I am planning to recognize 5 different words representing by 5 the Leds on the schematics.

I also have 5 push buttons: 1 reset, 1 to train the MCU, 1 to activate the DSP processing and 1 spare in case I need another one.

Well this is how I visualize it...I'll take a few days refreshing myself on what I was trying to achieve before I get back here discussing about the programming part.

Thanks!
 

Attachments

bertus

Joined Apr 5, 2008
22,270
Hello,

The potentiometer for the voltage drop, will have a different output voltage when a led is lit and when not.
Better use a fixed resistor with a couple of series diodes ( 4 will give about 2.8 Volts).
(you could also use a zener from this list: http://forum.allaboutcircuits.com/showpost.php?p=448158&postcount=2 )
The resistor value will be dependend on the Vdd given to the circuit.
I would give a value that will supply about twice the led current for stability.
(assuming only one led can be lit).

I would also put the top side of R7 to the powersupply pin of the pic.
That way the ADC input is referenced to 1/2 of this powersupply

Bertus
 
Last edited:

John P

Joined Oct 14, 2008
2,025
As we all know *Hardware* comes first...
Maybe it shouldn't always. This might be a case like a few projects I've done, where the processing was so complex that it seemed easier to write the code and get it running on a real computer, and then transfer it to a microcontroller. If it's audio input that's involved, you could work from WAV files to get your input, and that way it would be consistent every time you run the code, and of course you can get indications for all sorts of intermediate results to check what's happening. Once you get it to work properly with some particular input, then you can start testing it with other sounds and see how it behaves, and maybe tweak your algorithms, or if necessary find new ones.
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Maybe it shouldn't always. This might be a case like a few projects I've done, where the processing was so complex that it seemed easier to write the code and get it running on a real computer, and then transfer it to a microcontroller.....
I guess you are right! The software part here is much more complex than the hardware. I think I'll leave the hardware for now and focus on the implementation of the algorithm (coding) BUT I wanted to post a schematic so people can follow easily...

If it's audio input that's involved, you could work from WAV files to get your input, and that way it would be consistent every time you run the code, and of course you can get indications for all sorts of intermediate results to check what's happening. Once you get it to work properly with some particular input, then you can start testing it with other sounds and see how it behaves,
This sounds interesting although I don't clearly see how/what but I ll get it as I progress...I think this part will done when training the MCU...
... and maybe tweak your algorithms, or if necessary find new ones.
Yes! I also think the above algorithm is hard to implement but that's what I have for now and I learn a lot in the process...Will try FFT as suggested after this one.

@Bertus: Vdd is 5V

Will try to be quick refreshing myself...

Thx!
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Hey!

I been away as I had a little $$$ job and now I am tryna push with this thead... I am currently trying to use MplaSim *for the first time* :D as I figured out it would save me lots of time and energy...coz Im used to work everything in head and with pencil and paper but realised that it's not an efficient way of working as you guyz suggested wat back.

I am trying to do little simulation as after working for a while with my paper and pencil I am still confused about a little thing so I would like to see the contents of two registers...BUT I am getting the attached simulation eror message...

Any help on this one would be appreciated!
 

Attachments

Markd77

Joined Sep 7, 2009
2,806
Stack underflow would indicate a return, retfie, or retlw without a call.
In one of the settings menu you can get it to break on error (I think it isn't the default, and sometimes it's better to have it turned off).
It will then stop on the instruction after the error but if you view the stack, it should contain the location of the return instruction.
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
When i ignore all or some it's running but the cursor does not move.
Also I do not see register from the Watch windows ( I cannot add Symbol)...

The attachment is the default...not sure how to det (ignore, break or report) them tho

In the meantime I am doing the manual Simulation as I can't make it work yet...
 

Attachments

Markd77

Joined Sep 7, 2009
2,806
Hardware stack is in the view menu. Looks like the default was right after all. In normal run mode you don't see any changes until a breakpoint or similar, there is an animation mode but I find it a bit tedious. The key is getting the breakpoints in the right place, or using complex breakpoints mode, then single stepping when you get to the bit you are interested in.
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Not sure what to do next...

There's no setting for the hardaware stack...
Should I add _config in the simulated code or what...?
Can't see any of the registers in there...
 

Attachments

Markd77

Joined Sep 7, 2009
2,806
It can take a bit of getting used to. Actually I was wrong in my last post, it's been a while since I've had stack problems. You get the location of the instruction that caused the underflow from the error message (0x00000 in your case). Have a look at the "disassembly listing". The numbers down the left side are the addresses of the instructions.
I think what might be happening is that the PIC18 that you are using can be set to reset when a stack underflow happens and for some reason the debugger isn't reporting the real location of the overflow, but the value after the reset. I think you can clear the STVREN bit, probably in one of the config words, and then it won't reset and the error message might show the location of the problem.
It's entirely possible that the instruction that causes the underflow isn't the actual cause of the problem. There could be a return somewhere else that shrinks the stack and then the error message location is the final nail in the coffin.

Anyway the stack:
Here the arrow points to the current return address in the stack. The program is in the interrupt, which happened directly before instruction 0x73, and when the retfie happens the arrow will point at level 0 and execution will continue with instruction 0x73. At some point in the past a call happened from location 0x1E

 

Attachments

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Hi

I have a few comments/questions about post #95

This PIC18 multiplier only works with *unsigned bytes* as stated in the datasheet, Is there any mutiplier on any PICs working with signed numbers? (just curiosity).

Where in datasheet it says that this " variablename:n" notation is allowed to create an array "variablename [n]" like in C? And where it says "variablename+k" is allowed for indexing an array? I love it tho!
The Only book I refer to when writing PIC codes is the *datasheet* and nothing else! Is it by any chance in the " Data Memory and Extended Instruction Set" section? I just quickly scrolled on it...

"BANKSEL f1flags" could be replaced by "movlb 1" that will execute in 1 instr. cycle, correct? maybe you used it to be more meaningful...

movlf has been used (and not movlb) as tblptr is a SFR contained in Access Bank, correct?

I can also see that temp0, temp1 and bitcnt have been put in Access RAM for quick access to them for the arithmetics, correct?

Looking at the code it seems to me that data (coefficients) in ROM (and RAM) are aligned in "little endian":

! low byte ! high byte ! ...
Is it always aligned in little endian by default or what?

The code is beautiful but the design of algorithm behind this is even more beatiful and brilliant but I am still confused with the bit of code below:

Rich (BB code):
movfw    temp0                ;set negative flag for this coefficient
    iorwf    f1flags,f,1
    movfw    temp1
    iorwf    f1flags+1,f,1
 
cprrnn    clrc      ;rotate p/m flags
    rlcf    temp0,f    
    rlcf    temp1,f
I understand the idea of the algorithm BUT when I work the actual piece of code I get confused and I am tired of working this without a simulation to view the content of these registers...but while getting the simulation work you can maybe explain a bit more what I am doing wrong!

I know the algorithm assumes that *all* coefficients are positive and pays special attention to the -ve ones and put a '1' to the bit corresponding to the coefficient and *that's what I get wrong* although i understand as you can see in my attachment

in my example if there's four (five) -ve ones I get the four (five) '1' BUT at the wrong location.

I can feel your *expertise* in the algorithm coz I would do this part differently and that would result in a much longer code. You must have worked it out in reverse order I mean from the desire expectation to the start...

Thanks in advance for you comment!
 

Attachments

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Here's what works for me:

Initially, tempo = 0000 0010 ('1' is the signed bit of the 1st coefficent)
temp1 = 0000 0000

Rich (BB code):
...
clrc
rrcf temp0,f
rrcf temp1,f
...
I am rotating to the right (not to the left).
Have a look at the attachment. I am am double checking in the meantime.
In the example attached I assumed the coefficients signs were: - - + + - + - + + -
 

Attachments

Last edited:

joeyd999

Joined Jun 6, 2011
5,234
Hey, Eric.

I will be entertaining guests this weekend, so I won't be able to help much, but I will answer what I can now.

This PIC18 multiplier only works with *unsigned bytes* as stated in the datasheet, Is there any mutiplier on any PICs working with signed numbers? (just curiosity).
No for PIC12-18. Not sure about dsPIC or others.

Where in datasheet it says that this " variablename:n" notation is allowed to create an array "variablename [n]" like in C? And where it says "variablename+k" is allowed for indexing an array? I love it tho!
The Only book I refer to when writing PIC codes is the *datasheet* and nothing else! Is it by any chance in the " Data Memory and Extended Instruction Set" section? I just quickly scrolled on it...
It's not in the datasheet. You need to look at the assembler documentation. Also, remember that labels are just numbers. You can apply math expressions (like +1) to a label.

"BANKSEL f1flags" could be replaced by "movlb 1" that will execute in 1 instr. cycle, correct? maybe you used it to be more meaningful...
They are equivalent. BANKSEL is easier to read/interpret, and comes in handy if you use the linker.

movlf has been used (and not movlb) as tblptr is a SFR contained in Access Bank, correct?
movlf is just one of my macros that represents "movlw" followed by "movwf". Makes code cleaner, but you must remember that WREG is changed by this "instruction". movlb affects the BSR! Don't get confused. TBLPTR is an access bank register.

I can also see that temp0, temp1 and bitcnt have been put in Access RAM for quick access to them for the arithmetics, correct?
Actually, I consider them "general purpose" scratchpad registers, which may be used in multiple locations throughout the program. Think of them as having local scope in the C mindset. They are not really local in scope as they are defined globally. Just assume that they must be initialized prior to use, and their values are not persistent upon reentry to the routine in question. And, yes, I put them in Access RAM for quick access.

Looking at the code it seems to me that data (coefficients) in ROM (and RAM) are aligned in "little endian":

! low byte ! high byte ! ...
Is it always aligned in little endian by default or what?
If you are using the same assembler as me, yes.

The code is beautiful but the design of algorithm behind this is even more beatiful and brilliant but I am still confused with the bit of code below:

Rich (BB code):
movfw    temp0                ;set negative flag for this coefficient
    iorwf    f1flags,f,1
    movfw    temp1
    iorwf    f1flags+1,f,1
 
cprrnn    clrc      ;rotate p/m flags
    rlcf    temp0,f    
    rlcf    temp1,f
I understand the idea of the algorithm BUT when I work the actual piece of code I get confused and I am tired of working this without a simulation to view the content of these registers...but while getting the simulation work you can maybe explain a bit more what I am doing wrong!

I know the algorithm assumes that *all* coefficients are positive and pays special attention to the -ve ones and put a '1' to the bit corresponding to the coefficient and *that's what I get wrong* although i understand as you can see in my attachment

in my example if there's four (five) -ve ones I get the four (five) '1' BUT at the wrong location.

I can feel your *expertise* in the algorithm coz I would do this part differently and that would result in a much longer code. You must have worked it out in reverse order I mean from the desire expectation to the start...

Thanks in advance for you comment!
I don't have time to guide you line by line at the moment, but get you simulator up and running and the operation will quickly become clear to you.
 

Thread Starter

Eric007

Joined Aug 5, 2011
1,158
Hey, Eric.
I will be entertaining guests this weekend, so I won't be able to help much, but I will answer what I can now.
Have fun! I'll be working in the meantime and waiting...

No for PIC12-18. Not sure about dsPIC or others.
Ok.

It's not in the datasheet. You need to look at the assembler documentation. Also, remember that labels are just numbers. You can apply math expressions (like +1) to a label.
Will have a look at the assembler documentation thanks!

They are equivalent. BANKSEL is easier to read/interpret, and comes in handy if you use the linker.
Ok.

movlf is just one of my macros that represents "movlw" followed by "movwf". Makes code cleaner, but you must remember that WREG is changed by this "instruction". movlb affects the BSR! Don't get confused. TBLPTR is an access bank register.
I understand all your macros very well! and Yes the code is much neater and smaller. Will write my set of macros for PIC16F too. But in terms of execution time, it takes the same amount of time as if it was written without macros, correct?

Actually, I consider them "general purpose" scratchpad registers, which may be used in multiple locations throughout the program. Think of them as having local scope in the C mindset. They are not really local in scope as they are defined globally. Just assume that they must be initialized prior to use, and their values are not persistent upon reentry to the routine in question. And, yes, I put them in Access RAM for quick access.
If you are using the same assembler as me, yes.
Ok.

I don't have time to guide you line by line at the moment, but get you simulator up and running and the operation will quickly become clear to you.
Hopefully will get the simulator running soon...but I can see clear when doing rotate to the right...anyway I know its working and need to move on as there's still much computation to do.

My idea in #119 to make a routine out of that code for the 7 filters is a good idea, right?

Thanks!
 
Top