Exact match. Not showing close matches.
'[PIC] Project working only if at least 1 second sp'
This project receives midi note-ons to turn on a specific output line,
and midi note-off to turn it off.
Project receives midi data through USART and works great if there is at
least a 1 second delay between sending a midi note-on or a note-off.
Any event sent with less than a 1 second delay from the previous event
WDT is not enabled.
Source code is here:
My assembly language skills are rusty so any help would be greatly
Urk, I'm not about to slog through all that code, but could it simply
be a CPU loading problem? How big are your ISRs etc.? If you're
polling, maybe you're getting stuck elsewhere, so you miss the event?
On 10/12/07, Rob Blanchard <hollandc.pe.ca> wrote: RBlanchard
On Fri, 12 Oct 2007 16:32:45 -0300, Rob Blanchard wrote:
There's far too much going on to expect it to be debugged by others in its current state, but to start with you don't initialise your variables - the very first
instruction in "Main" is setting a single bit in "none_eq" when the rest of it could be any random value.
In the first-called routine (write_ram) there's this mess [comments in square brackets are mine]:
movf FSR,W ; Save original FSR [ - which is random, as it's never been initialised ]
bcf STATUS,7 ; RAM Block 0 (00) [ this bit really ought to be given a name, rather than expect the reader to know the layout of STATUS ]
bcf FSR,7 ; [ setting a single bit, when the rest is unknown - is clearing the high bit the right thing to do anyway? ]
I can't work out what it's trying to do, even if FSR had been initialised. Then:
movlw 00h ; [ Set W to 00 ]
movf base_addr,W; start addr. EEPROM ; [ Set W to an unknown value - base_addr hasn't been initialised ]
movlw 040h ; Load start of table ; [ Set W to 40h ]
movwf FSR ; in ram ; [ store the 40 into FSR ]
So effectively the first 2 instructions accomplish nothing because the first is negated by the second, which is then negated by the third.
And this all happens in the first dozen instructions after initialising - I gave up at that point! :-)
Start with initialising all the variables, run through the code and tidy up the sort of thing above, and see where it gets you.
> On Fri, 12 Oct 2007 16:32:45 -0300, Rob Blanchard wrote:
> bcf STATUS,7 ; RAM Block 0 (00)
What is a "RAM block" ?
*IF* this is to change RAM *bank*, use BANSKSEL instead...
Jan-Erik Soderholm wrote:
>> On Fri, 12 Oct 2007 16:32:45 -0300, Rob Blanchard wrote:
>> bcf STATUS,7 ; RAM Block 0 (00)
> What is a "RAM block" ?
> *IF* this is to change RAM *bank*, use BANSKSEL instead...
He he, and what is "BANSKSEL" one might ask.
Hm, well, try with BANKSEL...
More... (looser matching)
- Last day of these posts
- In 2007
, 2008 only
- New search...