RS485 With MAX3085 & PIC16F15356

[temtronic]

9 bit vs 8 bit..
I asked cause 99.99% of all 'PC' computers ,serial data is 8 bits...unless they have special hardware and programs in them.

I suggest you changing to "bits=8.....".

[Humberto]

You are doing your first tests, I suggest to use simplest and short code.
With those signals on 'A' and 'B' you should have no problem receiving
data with this transceiver.
We don't see your whole code, apart from the code proposed as a handler on INT_RDA.
It is not a good idea to use a printf inside an interrupt routine.

[Backfire]

Hi all,
thanks for peoples input so far. Through my troubleshooting, and having reviewed most suggestions and tested them, I still see no output (at RO, (pin1)) from the MAX3085 mounted on the board.

HOWEVER...

The PIC port pins I actually have wired to the RE & DE control pins of the MAX3085, are pins A6, and A7. Which just so happen to share most of the oscillator functionality!

I am actually running an internal oscillator, so I'm thinking I'm missing some #FUSE directives, or some other element of PIC configuration to make these pins function how I am intending, indeed even though driving them high is only for use in RS485 transmit functions, I am issuing output_high() function calls, and not seeing A6 or A7 change.

I have tried adding both the #FUSES NOEXTOSC & #FUSES NOCLKOUT

[temtronic]

I do not have that PIC or a new compiler, but check the processor header file( PICxxxx.h ) for the list of available fuses !

but something like

#fuse INTRC_IO

may be the choice ?

it says use the INTernal RC oscillator AND allow Input Output , on the pins normally used for the external clock

Others who use that PIC (or a newer compiler than me ) will have access to the header

[Backfire]

I'm happy to post just the FUSES from the .h file that seem related to the OSC pins, if that's forum permitted? It'd just be the three FUSE lines that reference the oscillator.

[temtronic]

post them...
I think they're in the 'comment section' at the top of the header file.

While technically not permitted, it could clear up your problem PDQ.

Maybe that PIC has new fuses, unknown to us with old compilers...
though the intrc_io has been around 'forever'....

Also post compiler version, maybe that version has a 'bug' in it and won't configure the fuses as needed ?


I've seen LOTS of 'code' displayed here...

Worst thing... a reprimand and the 3 lines get deleted.

OK, I'll take the 'hit' for suggesting he posts them....

[Backfire]

Hi temtronic,
I've DM'ed you them... I think! phpBB and it's quirky 'outbox' and 'sentbox' implementation.

[temtronic]

I'd try ...

RSTOSC_HFINTRC_32MHZ,NOCLKOUT

RST means 'restart' (which clock when PIC 'restarts'....)
in this case the HF internal RC clock, at 32MHz


NOCLKOUT, should allow that pin to be I/O.


Someone must have used a similar PIC......

I still have some with quartz windows on them.....

[Humberto]

Backfire wrote:

[Ttelmah]

I have to say though, stop worrying about fiddling with fuses!....

The easiest way to setup the clock is with the #use delay statement.
Don't set any clock fuse, use the delay statement to do this for you.
It is so good on recent compilers that setting clock fuses is no longer
either necessary or wanted.

#USE DELAY(INTERNAL=32MHz)

Is all that is needed. This by default sets the oscillator pins for normal I/O.

To use the external 20MHz crystal, just:

#USE DELAY(CRYSTAL=20MHz).

If you want a clock output on the former, just add CLOCK_OUT to the
#use statement.

On some chips now the permutations of the fuses are so complex, that
letting delay do it, is the only way to set this up safely.

[Backfire]

Good morning (where I am) everyone...

Once again many thanks for everybody’s advice, this forum is genuinely filled with some very knowledgeable people!

In the end, it was a configuration issue of kinds... though nothing to do with the oscillator...

@Ttelmah, I always try and start code files using the #USE DELAY(INTERNAL...) directive, my designs are rarely super-dependant on tight timing, so typically no need for crystals, and I am vaguely aware that the #USE DELAY does indeed do loads of configuration, so is a quick and clean way to get up and running.

@temtronic, I think I am going to be adding the RSTOSC_HFINTRC_32MHZ fuse also, seems like a smart idea to set an absolutely defined start-up oscillator configuration, just in case.

@Humberto, many issues indeed, doubtless many more to come! All part of the "joy" of development I suppose.


So... what was wrong? At a point later in code I have made a call to input_a(), without previously using a #use fixed_io(... ) directive, and without doing so my call to the input function obviously overwrote the TRIS values... Because, of course that’s exactly what I told the compiler to do, so it did it. Having now told the compiler I would like A6 & A7 to always be outputs, everything is running how it should.

Many thanks again to all!

[temtronic]

glad it's 'up and running'...

It'd be interesting to dump the listing and SEE exactly which fuse got set !

As Mr. T points out, modern PICs are COMPLICATED so yeah,maybe having the compiler 'figure it all out' is good....but I kinda want to SEE code, not just have blind faith in a machine doing it for me.

[Ttelmah]

I felt the signal had to be being held high.
It was, but by your software...
Unfortunately nothing you posted showed this being done to the registers.

This is why we advise building a small test program, and then once this
is working 'building upwards'.....

Anyway, the good news is it is working.

Unfortunately Jay, on a lot of the newer chips (particularly the DsPIC's,
but some of the newer PIC 16's and 18's as well), the clock now has to
be setup 'after' the actual boot, and is not therefore controlled by the
fuses. Hence you have to rely on the compiler to setup the PLL on these.

[temtronic]

Thanks for the info Mr. T.

maybe I'll stick with PICs that I can see INSIDE......
life was a lot simpler with PCM 2.534 !!!

cheers
Jay

[Backfire]

I love that the CCS compiler can do so much "auto configuration", for wont of a better phrase. But with so many PICs in existence now, so many 'caveats' and 'device quirks' must also exist.

I remember in a previous project where I had, as per usual, set the oscillator with the #use delay(intern...) directive and was having issues with oscillator-dedicated pin IO also (I should've looked at the port pins more carefully in this project earlier, I admit!) and in this case specifically adding a NOCLKOUT fuse sorted the problem right away. Each chip has their 'personality' I sometimes feel!

I quite literally always start my programming / code development with a blinking LED routine, if you can't make a LED blink, it'll never do anything more fancy!

Cheers once again all.