SPI in Flowcode 5

[mervinm]

Hi,

I want to use the SPI_Legacy() component macro to program a DS1305 RTC. The chip requires an active high on the chip enable (CE) pin to enable the chip for read or write operations. The issue I have is, SPI_Legacy() is designed around the EB013 board, which has two enable outputs, i.e. NVM and DAC, both of which are active low.

What exactly does SPI_Init do? Does it assert NVM and DAC to active low as part of the initialization procedure? Do I have to use one of the port C pins other than pin 7 and pin 6 as my chip enable, since pin 7 and 6 are assigned to NVM and DAC, both of which will be switched to active low during initialization.

Do I have to:
1) Call the SPI_Init, to initialize Port C (I am using a 16F877A) - not exactly sure what this does, other than assert NVM and DAC to active low.
2) Assign DS1305 chip enable to RC0 and switch it to 1 to enable the chip, then perform the write operations.

OR

1) Switch RC0 to 1
2) Call SPI_Init, and perform the write operation to the DS1305.

Any other suggestions will be appreciated.

Thanks.

[Mantas]

Hello Mervinm,

SPI_init initializes all SPI configuration settings for you SPI component, and setts the micro controller register for proper operation. It is not absolutely mandatory to use those DAC and NVM select pins, you can choose a port for them but leave them unconnected (I do this), and use general I/O pins to perform the logic high or low functions. Or you can use some logic inverter to invert your logic high from your DAC and NVM lines to logic low and vice versa.

BR,
Mantas

[mervinm]

Hi Mantas,

Thanks for the response and for providing clarity on SPI.

I noticed there are NVM Enable and NVM disable routines. I am assuming NVM enable drives the line low and NVM disable drives the line high. I can use the NVM line as the CE for the DS1305

Then I can:
Call SPI_Init
then
Call NVM_disable (which will enable the DS1305).

Do you see any problems with the above?

I am trying to avoid a hardware solution, but maybe it would be best to use a logic gate.

Cheers

[Mantas]

Hello Mervin,

You can always try it, I think there shouldn't be any problems to use it in reverse order Those NVM bits. If it fails, you can always use General I/O pins in FC by manually setting or clearing bits, to enable and disable the chip you are using. I attached a sample macro from my software, to give you an example how I do it. Let me know how it goes.

BR,
Mantas

getdata.fcm

(9.21 KiB) Downloaded 304 times

[mervinm]

Thanks Mantas.

I have downloaded code from Sean for the DS1305 RTC [http://www.matrixmultimedia.com/mmforum ... 305#p15993] and modified it a little with code from JohnCrow [http://www.matrixmultimedia.com/mmforum ... ial#p46544], to display the time correctly after a read from the RTC. Basically the sequence of reads and writes to and from the RTC, as specified by Sean matches the datasheet for the RTC perfectly. Therefore, in theory it should work. However, when I run the simulation I get "45:85:85" displayed for the time on the LCD. When I download the code to the 16F887A, I get the same numbers displayed on the LCD.

I have checked the circuit 100's of times and the code more times than I have checked the circuit. Yet, I just cannot get the RTC to do anything. I have read the spec for the DS1305 and almost memorized it . Any help will be appreciated. I have attached the flowcode file. Shouldn't I see data appearing on the CHARACTERS RECEIVED window of the SPI component when I run the simulation?

Unfortunately I cannot attach the DS1305 datasheet due to the file size.

Thanks
Mervin

[kersing]

To 'receive' data in simulation you need to:
- In the SPI component Ext properties set "Send Characters or Bytes" to Bytes. Also check 'Show as hexadecimal'. (Close with OK)
- Now in the component use the "+" sign next to the "bytes in queue" and input at least three hexadecimal values.
If you run the simulation you will see the bytes sent in the upper window and the bytes 'read' in the middle one. The bottom one will show the bytes left in the input queue.

Regarding the value you are seeing, it is the result of reading 0xff for every byte. (Your calculations result in the values on the display being 45:85:85. [0xf & 0x3 = 3, 0xf & 0xf = 15, 3 * 10 + 15 = 45])
So somehow you are not getting the data you are expecting.

Is the DS1305 pin SERMODE connected to Vcc? Are DS1305 SCLK, SDI and SDO connected to respectively (16f877a) RC3 (SCK), RC5 (SDO) and RC4 (SDI)?

[Mantas]

To be honest, it's one of the worst manuals that I have read. But from what I understood, I would suggest changing the sample bit settings to sample at the end of data output time. And also set the clock to Focs/64, to make sure the clock speed isn't too high for the chip. The clock polarity is not important according to manual. Maybe these settings are causing some issues...Also I think it would be better to start read time from the first register, which is 'seconds', and you start from hour. By the way, it is not necessary to un-initialize SPI at the end of your program. If you will be looping you should initialize it once and that's it, unless you are planning to use the same pins for some other purpose in your project. Also change the hour calc to:

Code: Select all

Var2 = (Reg_Hour >> 4) AND 0x01

as the 10 hour bit is only one bit, not two, as I understand you are running in 24 hour format. I have no idea why minutes and seconds appear as 85...I don't see any issues in the calculations.

BR,
Mantas

[mervinm]

Guys, thanks for the reply.

I checked the connections and all are correct. SERMODE is connected to Vcc I have changed the settings as suggested by Mantas, but still no luck.

How can I check if the microcontroller is actually initializing SPI mode?

Maybe I should replace the RTC chip.

[Mantas]

Mervin try writing and reading to one of the registers, like control register or some other static user register, to see if you get the same value back, which you wrote previously. If you get the same value back that means SPI is working correctly. Other only way to troubleshoot SPI communications is to use a logic analyzer, which is not a cheap option. But from Kersings example, it is obvious that you always get 111111111 for every bit you read which means either SDA pin is malfunctioning, or the clock pin is not working. Anyways, I would suggest playing with different combinations of SPI settings, the problem from the look of it is there.

BR,
Mantas