Search found 1473 matches
- Mon Mar 28, 2011 7:54 pm
- Forum: User Modules
- Topic: How to generate 10KHz to 200KHz with 18F87J50 ?
- Replies: 3
- Views: 2834
- Mon Mar 28, 2011 7:41 pm
- Forum: User Modules
- Topic: Im using SetBaudrate(br2400) but getting 9600?
- Replies: 5
- Views: 3627
Keep in mind that the "clock = " statement doesn't actually setup anything hardware-wise... it's purely so the compiler can know what speed you're running at so it can adjust software delays, timers, etc. You have to setup the CONFIG and OSCONx/OSCTUNE registers yourself, however, to actually get th...
- Sun Mar 27, 2011 10:30 am
- Forum: Compiler
- Topic: K22 ASM errors
- Replies: 13
- Views: 7914
The release notes say that it is bundled with MPASM V5.38. The release notes lie. It's not the first time... you can't trust them. MPLAB 8.66 includes MPASM V5.40. At least you've got the right stuff. You have two choices: - copy the required files from the Microchip/MPASM Suite directory into the ...
- Sun Mar 27, 2011 8:58 am
- Forum: Compiler
- Topic: K22 ASM errors
- Replies: 13
- Views: 7914
- Sat Mar 26, 2011 9:18 pm
- Forum: Compiler
- Topic: K22 ASM errors
- Replies: 13
- Views: 7914
- Sat Mar 26, 2011 6:26 pm
- Forum: Compiler
- Topic: K22 ASM errors
- Replies: 13
- Views: 7914
- Sat Mar 26, 2011 10:44 am
- Forum: Compiler
- Topic: USART strange results
- Replies: 9
- Views: 4960
- Sat Mar 26, 2011 9:39 am
- Forum: Compiler
- Topic: USART strange results
- Replies: 9
- Views: 4960
Keep in mind that the "clock = " statement doesn't actually setup anything hardware-wise... it's purely so the compiler can know what speed you're running at so it can adjust software delays, timers, etc. It should be set to whatever freq you're actually running at, so if using the 4xPLL it'd be 64,...
- Thu Mar 24, 2011 5:07 pm
- Forum: User Modules
- Topic: ISRRX Goes Away
- Replies: 8
- Views: 4430
4800 baud is ~2ms/byte, so a 14 byte message takes 28ms to transfer. Even at 8MHz (500ns/instruction), that's a boatload of time before you have to worry about things overrunning/overflowing unless you have added something to the ISRRX OnDataEvent that takes a long time (>2ms) to execute. As long as...
- Thu Mar 24, 2011 2:50 pm
- Forum: User Modules
- Topic: ISRRX Goes Away
- Replies: 8
- Views: 4430
If that's the case then I doubt what I said is the issue. As soon as the interrupt handler in ISRRX sees one too many characters, it sets the BufferOverrun flag and that should be caught by the ISRRX.Overrun() routine. If you wanted to flush the buffer, you can enable the commented out ISRRX.Reset y...
- Thu Mar 24, 2011 2:30 pm
- Forum: User Modules
- Topic: ISRRX Goes Away
- Replies: 8
- Views: 4430
I don't know if you're running into the situation I described or not, but it would only happen under some very specific circumstances, like you get exactly RX_BUFFER_SIZE number of characters come in without reading anything. Couple that with the fact that a lot of folks don't even seem to use ISRRX...
- Thu Mar 24, 2011 2:02 pm
- Forum: Compiler
- Topic: SystemConvert and _maxram
- Replies: 4
- Views: 2545
I've been playing around with the USB library, and since you originally wrote that a number of things have changed. It seems every time Mchip introduces a new USB chip, they change the way it works, and the various "hacks" are getting hard to consolidate. With the advent of the "J" and "K" series, t...
- Thu Mar 24, 2011 1:38 pm
- Forum: Compiler
- Topic: SystemConvert and _maxram
- Replies: 4
- Views: 2545
- Thu Mar 24, 2011 1:21 pm
- Forum: User Modules
- Topic: ISRRX Goes Away
- Replies: 8
- Views: 4430
It looks like there may be a flaw in the buffer index handling. If you get exactly RX_BUFFER_SIZE number of characters come in without reading any of them, you're left with the situation FIndexIn = FIndexOut and the FMaybeOverrun flag set. In this condition, the buffer is full (but hasn't overflowed...
- Thu Mar 24, 2011 11:41 am
- Forum: Compiler
- Topic: SystemConvert and _maxram
- Replies: 4
- Views: 2545
SystemConvert and _maxram
I'm curious. How does SystemConvert determine the '#variable _maxram' setting? Or even the '_ram_banks'? I always thought that you used the *.dev and asm *.inc files to gather up the info, but I don't see any way to tell from those files. Are you parsing the .PIC files? One of the reasons I'm asking...