Search:

So, what's your definition of "many times", and when you say "I only use a few bytes" how many bytes is that?

The "address" is just another one or two data bytes (depending on the data type used) sent before the actual "data".
Typically it's used for eeproms where you need to send an address parameter, or a...

Yes. Write to the LAT register. Read from the PORT register.

Jimbo,

The pic can transmit at that rate but you might run into trouble receiving.
921K is only 10us/byte, so you'll have to be able to handle incoming data at that rate.

I've run 460K baud...

That's probably not too bad, considering you have to send packet requests to get data.

Doing that's a good idea... I was worried you were just going to stream 256MB out the pic and expect the PC...

Most PC serial ports will run at 230400 baud.
The J53 will... just set:
BRG16=1
BRGH=0
SPBRGH=0
SPBRG=5

That might shave it down to under 4 hrs.
Make sure the MAX232 (or whatever you're...

The K83 has its SFR registers located at the top of ram, and the common ones are in bank 63 ($3F00).

The MOVFF instruction only uses 12-bits of addressing, so the highest address it can reach is...

At 115K it takes ~22ms to send 256 bytes assuming back to back transfers. At 9600 it's over 10x longer than that.

You could use background serial transfers while you do something to read that...

richard's code has some merits, but in almost all cases interrupts just add overhead... they rarely speed things up if that's what you're looking for.

Here's another version of the code I posted...

If you're looking for more efficient then drop the formatting entirely and just send the binary data.
If you format 256MB of data using HEX2 you end up with twice the number of bytes to transfer...

TRISB=%00000001 'Make RB0 input


For the 16F628A you're setting the RX input (RB1) to output mode.
The datasheet says to set both bits TRISB.2 (RB2/TX) and TRISB.1 (RB1/RX).

The simplest form of the mpasm 'include' directive has the form:


include p16f628a.inc

I think the angle brackets made part of the line drop out in richard's post, so if you try to copy that...

Yes they do, but since it's only for the PIC18F series it's a little easier for them.

I understand they'll be extending the existing MPASM to deal with new chips for a while, at least until mchip...

I don't think they give a ****.

All of this was brought to their attention a while back and the response was basically "sucks to be you".
It was "too hard" to convert mpasmx to 64-bit, and they...

Unfortunately there's more to it than just a name change.

Assembly code written for MPASM will not work with pic-as (which is part of the XC8 V2.20 package), and has to be re-written to be...

Microchip have dropped MPASM/MPASMX as of MPLABX 5.40. It's no longer included.
MPLABX is 64-bit only now, and MPASM is/was a 32-bit program.

They have a new 8-bit assembler, pic-as.exe and it's...

That's his problem... he DOES want to use a byte but as he adds or subtracts to the byte value it wraps and gives false operation.

The way I usually handle this sort of thing is to have a routine...

In your original code, change
IF Z<100 THEN I=I-5 to this
IF Z<100 AND I>=5 THEN I=I-5

If you have the pins available you could run the RX through the comparator to invert it.

To expand a little more on Henrick's last post, this gets it down to 3.51ms:


tLED VAR BYTE

FOR Row = 0 to 31 ' Cycle thru 32 rows

TempW = ROW * 32 ' Precalculate...

You should never manipulate the GIE bit inside the ISR. That is handled automatically when you get the intr, and then RETFIE restores it on exit.
Remove those two instructions.

That part is true. All GIE determines is if you'll wake up and go to the ISR vs just continuing on where you left off.

What wakes you up is the RCIF that occurs when the 00 "break byte" comes in....

One simple thing you can do is to combine commonly occurring sequences into a sub, for example


hl2:
pause x
high two
low one
return

16Fxx isn't the best choice

For comparison:
16Fxx @ 20MHz executes instructions at 5 MIPS,
16F1xxxx @ 32MHz -> 8 MIPS,
18F @ 64MHz -> 16 MIPS

Looking back at your original pseudo code with...

There is no way that's anywhere near as fast as a lookup table.

In your post on the MPELABS forum you had:


lookbyte=timebyte // 32
ampvar=SINB[lookbyte]

The killer there is the '//'.