| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
 Posted: Mon Apr 09, 2007 3:00 pm |
 |
|
| Quote: | | I'm aware that the EEPROM has a page read feature, but if I read a whole page at a time, do I not need a large array to store it in? |
The EEPROM has a page write and a sequential read feature. For the sequential read it is not required to have a large buffer in the PIC, you can just sequentially read a byte at a time when you need it. |
|
|
andyd
Joined: 08 Mar 2007
Posts: 30
|
|
| Posted: Sun Apr 15, 2007 10:02 am |
|
|
Ah, ok. Well I've now implemented a sequential read and am now only outputting 8 bits to the PWM (removes a couple of extra bitshifts and AND functions), but it's still not quite fast enough. If I give it a file which contains a 1 kHz sine wave and look at the output of the filter on a scope, I see a 615-ish Hz sine.
Any other ideas on making it faster? I did think about pre-buffering part of the compressed audio (as I assume reading from the PIC's RAM will be faster than an external EEPROM), but the files are in the order of a couple of kB each, which is too big for the PIC's RAM, so I'd still have to be reading data from the EEPROM into the buffer while the decode routine was happening and so don't think it'd help?
Any other suggestions on making it faster or am I just stuck with slow audio unless I use a faster clock frequency? |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| Inline this |
| Posted: Sun Apr 15, 2007 11:36 am |
|
|
If you have code space then inline
Write10bitPWM(sample);
This avoids pushing and popping the stack.
I have similar code that ticks at 15uS but running at 40MHz on a PIC18 !
Not only will the PIC18 give you a faster clock in lots of chips there is more
RAM is you need it.
You may find a pin for pin compatible PIC18 to replace the PIC16 |
|
|
andyd
Joined: 08 Mar 2007
Posts: 30
|
|
| Posted: Sun Apr 15, 2007 11:46 am |
|
|
Could you explain what you mean by inline?  |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sun Apr 15, 2007 2:30 pm |
|
|
| andyd wrote: | | Could you explain what you mean by inline? |
Check your C-manual for the #inline statement. On compiling code the compiler often has to decide to optimize for speed or for code size, using the #inline directive you tell the compiler that for the indicated function speed is important. An inline function can be executed faster because it is located directly at every program location where it is called, this saves storing variables at the stack, a goto and a return instruction. Disadvantage is the increased code space required as the function has to be copied 'in line' at every location where it is called.
The opposite of #inline is the #separate directive, this is the default compiler setting.
| Quote: | | Any other suggestions on making it faster or am I just stuck with slow audio unless I use a faster clock frequency? |
In your main loop you are setting wait=1 twice, this is dangerous as this variable might already have been cleared in the interrupt routine.
Decoding 8000 samples with a PIC16 processor running at 8MHz leaves you with only 250 instruction times per sample. This is tight but should be possible.
Giving you some general advice is like shooting from the hip. Much better is when you do some measurements on your code in order to _know_ where the problems are. For example in MPLAB you can execute your program in the simulator and then use MPLAB's stopwatch function to meassure the time used by each function. I don't think it is possible to simulate the eeprom, but you can use an oscilloscope to meassure the real hardware and than replace the eeprom_read() by a stub function with an equal delay_us(). |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
