Search:

By lowering the baud rate you're now allowing device B (and SERIN2) twice the time to receive the bits and assemble the byte.
That's probably what's helping a lot more than any line noise issue.
...

Just to correct myself in #9...

At 19200 baud each bit should be 52us +/-1.5us, give or take (about 3%).

I was thinking byte times, not bit times.

'Code at device A, PIC18F4550
SendData:
pause 5
SEROUT2 PORTB.7,32,[STR RFID_IN\7]
goto SendData


You're only allowing device B 5ms between transfers to receive the data and display...

Another thing that could be causing problems is that SEROUT2/SERIN2 are software bit-banged (no hdw UART involved),
so device B must be sitting waiting at the SERIN2 for the first start bit before...

serout2 PORTB.1, 84, ["This is my value:", dec MyValue, 13,10]

There's no "packet" created... bytes are streamed out the software UART as they are made ready.

There may be a small delay between...

Except that for the 8-bit chips Positron doesn't really support anything much newer that PBP does (see my previous posts).
They've been promising an update "Real Soon Now" since 2022...

There's...

With that many displays I assumed they would be multiplexed as in richard's post #17.
Surely a lot less supply current, and you wouldn't need nearly as many pic's to drive them... maybe get away...

Wouldn't it be simpler with common cathode? That way you only have a single sink transistor/fet for each set of digits, making it easy to PWM.

As Ioannis pointed out, PBP updates for new devices is pretty much over.
PBP uses the assembler (mpasmx v5.87) from MPLABX v5.35, and mchip has replaced mpasm with a new assembler PIC-AS, which is...

Support for the 16-bit pic24/dspic33 parts is one of the nice things about Positron.
But, if you thought SF was a bit quirky Positron is possibly worse in that regard.
As you say, each have there...

A lot of it really depends on what your ISR is doing.

Just like PBP you can choose to save just the pic registers or also include the BASIC system library variables.
SF has the additional...

No idea about that one... not familiar with HIDMaker, but if it produces code for PBP I would think its output could be massaged to work with SF.
All of the SF libraries are in source code so you...

Positron Basic has the same problem as PBP... no support for devices not included with MPASMX 5.87.
That rules out a number of newer 18FxxQxx and 16F1xxxx parts.

Not at all.

Swordfish supports ALL the 18F family of devices, including the newer Q family... Q10, Q40, Q41, Q43, Q83, and Q84.
Support for the Q20, Q24, and Q71 devices will be released shortly.

... or if you really want the latest PICs then checkout Mecanique's Swordfish BASIC, but that only supports PIC18F family.

To convert a 2's compliment negative value to a positive number, invert all the bits (NOT) and add 1.

For example 2's compliment -1 = FFFF
invert = 0000, add 1 = 0001

Keep reading. It's a 13-bit differential converter.

From the datasheet section 5.1:


So that's 12 bits of data + sign. See Section 6.1.

That's the wire speed... you'll never get the code to run anywhere near that fast except for a single byte transaction.
You won't get I2C to run that fast without active pullups, and getting the PIC...

+1

If you're trying to use an IO expander to do that good luck!

You shouldn't leave the inputs of the HC14 floating... the outputs will be unknown.

Also, an ST gate really won't debounce anything if that's what you're trying to do.

Turn off "case-sensitive".

If you have MPLABX 5.35, the version of mpasmx should be 5.87... that's the last released version.
You should find it in the MPLABX install directory under the mpasmx...

Because this thread will be followed with "how can I speed up my OLED display routines?".

The choice is obviously yours, but the 18F27Q43 has 128K of flash, 8K of ram, and runs at 64MHz.
The only...

In fast mode (with the upper two bits 00) you only need two bytes.
If you want to use the EEPROM function you need all three bytes.

Of course, both modes need the address byte too.

addr var byte
addr = $C0 ;$60 <<1

writedac4725:
I2CWRITE sda,scl,addr,[4000] '12 bit value
PAUSE 10 ' Wait 10ms for write to complete

That'll do a fast-mode write to the DAC register as long...

If you reduce the timebase of your analyzer so you can capture an entire set of the FOR-NEXT loop, you'll see that it's not jitter but the increased time when the FOR-NEXT loop exits and the GOTO...