I'm fairly sure there was an article in nuts & volts describing the interfacing of a BSII to a DS1307 a while back using shiftin/shiftout
I'm fairly sure there was an article in nuts & volts describing the interfacing of a BSII to a DS1307 a while back using shiftin/shiftout
This is my code, please be aware that it drives a graphic lcd, has eeproms and also drives a touchscreen, it is still full of bugs.
But the Readtime, and Writetime commands work, please be aware that there isnt many comments because of the size of the program.
Please refer to the datasheet for reading and writing to the current addresses to the DS1307.
I have not checked the whole program, but as a start I recommend to change every command that access port pins from pinXXX=1 to HIGH pinXXX and respectively for the =0 to LOW pinXXX.
I used to reserve some bytes the way you did it but this method does not take into account the memory page issues of the PIC. So if you are sure the program is just short enough to fit in the first page do it. Otherwise, let the compiler take care of the issue.
Ioannis
Last edited by Ioannis; - 19th July 2007 at 08:20.
PBP uses macros to set the correct register bank when you use pinxx=0,
pinxx=1, etc, so bank switching shouldn't be an issue, but read-modify-write
can cause you a lot of headaches.
If you have pinxx=0, pinxx=1, etc, in a row, then you'll have problems with
read-modify-write. Especially running at higher oscillator speeds like 40MHz.
If you change pin aliases from say pinCS var PORTC.4 to pinCS var LATC.4
that will help eliminate r-m-w glitches for the 18F series.
Example from your code;
Pin aliases
ctrlA VAR PORTC.0
ctrlB VAR PORTC.1
ctrlC VAR PORTC.2
ctrlD VAR PORTC.3
Then farther down you set/clear portc pins in succession;
ctrlA = 1
ctrlB = 0
ctrlC = 1
ctrlD = 0
This uses bsf and bcf on port pins, and can definitely cause you grief with
read-modify-write.
If you change your pin aliases to point to LAT registers, you should never
have problems with read-modify-write.
ctrlA VAR LATC.0
ctrlB VAR LATC.1
ctrlC VAR LATC.2
ctrlD VAR LATC.3
Then it will set/clear portc LAT pins, and not read the port first, modify the
value, and write it back. This writes to port latch registers VS directly to the
port pins. Just be sure you setup TRIS registers first.
So this is now OK to do without read-modify-write issues;
ctrlA = 1
ctrlB = 0
ctrlC = 1
ctrlD = 0
If you use HIGH & LOW commands, PBP inserts a ton of extra code, so this
can definitely save on code space. If you do use HIGH & LOW, then do NOT
use HIGH or LOW commands with LAT registers.
PBP uses an offset (from the port register physical address) to figure out
where the TRIS register is, and it doesn't point to the TRIS reg if you use
HIGH & LOW commands with LAT registers.
So stuff like HIGH LATC.4 or HIGH pinCS (if it's aliased pinCS var LATC.4) is
not a good idea. It's not going to automatically make the pin an output by
clearing TRISC.4, and it's going to clear some other register bit at the wrong
offset address.
Places where you have stuff like this;
PORTG.0 = 0
PORTG.1 = 0
PORTG.2 = 0, etc, I would also change to LATG.0=0, LATG.1=0, etc, but only
if I couldn't just write directly to the whole port at once with PORTG = ?.
On 14-bit core, if you need to write to port pins in succession, you're almost
always better off using HIGH pin.x, LOW pin.x, etc, since you don't have LAT
registers on these, and the additional code inserted helps eliminate r-m-w
glitches.
Sorry, I did not see that this was about 18F series.
I just expressed my experience on 16F PIC's using directly pin control.
Well descibed Bruce!
Ioannis
Bookmarks