My question is directly related to a post by Noter on thread. I did not want to change the general topic in that thread so I have started this thread. My question is the related to the lack of any oscillator crystal on the slave chip in the photo and the schematic. How is the salve chip clocked?

I was under the impression that the SCK clock single was only used to synchronize the SPI data flow not to clock the MCU itself. I have set up a few SPI communications in the past I have always used an oscillator crystal on each of the slaves and the master. Can I remove the crystals from the slave chips? If I do what frequency will that chip run at? Since the SCK to oscillator frequency ratio is selected in master with the SPR1 and SPR2 bits this ratio is not known at the slave. The SCK frequency will be lower then the master osillator frequency by a factor of at least 2 possibly as high as 128. After thinking about it, I am wandering how the slave chip could possibly be clocked on a separate oscillator crystal and use the SCK to synchronize with the master.

There is something I am missing here.

Noter sometimes uses the internal oscillator to clock his chips. This is most likely what he is doing there. The internal oscillator can run at 8MHz or 1MHz if the div by 8 fuse is set. This requires an ISP programmer to change the fuses if you are using a NK configured microcontroller. Blank microcontrollers that have never been "setup" for NK or Arduino, will come standard configured for the internal oscillator at 1MHz.

Rick

Thanks Rick, that makes sense.

Since I am clearing up my understanding of SPI connections, I have another question. What is the reasoning for having capability to reset (pin 1) the slave chips from the master?

I know that in at least some cases it is not required. I have good two way SPI communication working on a prototype setup with no provision to reset any of the three slaves. My prototype seams to be working as expected, I am getting reading back to the PC from all four of the digital callipers. I also can read the status of the Toshiba motor controler output pins, as well as control the input pins on the Toshiba chips from the PC.

At this time I have only one Toshiba chip connected to one of the slaves but I don’t see why the other two would not work just as well. I am attempting to improve the uart communication with between the master and the PC and make better use of the master mirco by rewriting the code on the master using uart interrupts. I am also changing the PC side of things over from VBA Excel to c#.

What am I risking or what would be the possible advantages or circumstances where a slave reset would be require? I do not have any unused pins on the master to use to control a slave reset. In fact there are so many connections between the slave chips and the respective motor controller chips I only have three unused pins available on the three slave chips and the master combined. So I am using dip switches to preset a couple of motor parameters that are will not likely ever be changed for my project.

Darryl

Yep, I'm using the internal oscillator at 8MHz on the slave chip. Had to drop below 12MHz to run the chip at 3.3v anyway and by using the internal oscillator I didn't have to find a slower crystal.

I've been buying ATmega's from Mouser and like Rick says they come configured to use the internal oscillator at 1MHz so the first thing that needs to be done is to set the fuses for how you will use it. I used my latest ISP programmer, NANOISP, to do this and load the programs too. For test programs, I modified the Master/Slave SPI programs to remove the lcd and instead blink the led when spi communication is good. Didn't bother putting the bootloader on either of these mcu's since their use is just temporary for this test. To arrive at the fuse values I like to use the site Engbedded Atmel AVR® Fuse Calculator because it's a lot easier than looking it up in the spec and figuring it out one bit at a time. The fuse values I used for each of these mcu's are:

Master
    LFUSE = F7
    HFUSE = D4
    EFUSE = FF
    LOCK = EF

Slave
    LFUSE = E2
    HFUSE = D4
    EFUSE = FF
    LOCK = EF

Resetting the slave is not always necessary depending on the communication stream. If your protocol is simple single byte commands and responses you will probably never have a problem. However if you have multi-byte streams and the master crashes or gets a program load (resets) in the middle and the slave doesn't then the communication can be out of sync. As a matter of practice I always reset slaves during master initialization to be sure everything is starting from a known state. And not just SPI, I do the same initialization reset for I2c slaves.

By the way, if you can get by with 8MHz using the internal oscillator you gain two I/O pins on each mpu.

Interesting! There are a number of things I will consider in your last post Notor.

In my SPI data stream from the master to slave data I have reduced the content to eight bits. After the master receives a two byte control code from the PC on the uart it sends a one byte control code to the appropriate slave. Therefore each bit that is received by a slave can be interpreted in the same way. Ie bit 0 is the CLK pin state to be set on the motor controller chip , Bit 1 is the CW/CCW pin state on the motor controller and so no. For that reason there is no possibility of the slave and the master getting out of sync on the master to slave communication.

The slave to master communications is more involved. There are 24 possible data bits that are communicated from the slave to the master. Each digital calliper reading requires 18 bits. Each set of motor controller chip output pin states and position limit switches states require 6 bits. I have set up a system to commutate the 24 bit using 4 possible slave to master bytes. 6 bits of each of those bytes are used for data, 2 bits are used to identify the byte. I have tagged each outgoing bytes sent from the slave with a two bit ID in bit positions 0 and 1. The master can identify what the incoming SPI byte is from the value of bit 0 and bit 1. The master will recognize each byte as a motor controller pin state byte or a MSB byte from the calliper position and so on. The master can deal with each byte in the appropriate manner.

The slaves only communicate the digital calliper readout to the master if the value has changed; as long as the calliper remains in one position the slave does not report that position. Most of the time the slaves do not send the three byte calliper readout, only the motor controller pin state byte is transited on the SPI to the master and then on the uart to the PC. I did this to reduce the flow of redundant data on both the SPI and uart data streams. Using this data stream the slave to master communication can’t really get out of sync either.

For these reasons I don’t think I will worry about no capability to reset the slaves in this project. The two extra output pins per chip when using internal oscillator is interesting I will be looking into that idea.

Thanks again Darryl

Darryl, of course if you got critically short on pins you could use I2C instead of SPI and save a ton of pins.

Of course you do not want to make that switch but just thought it should be mentioned for others that will be following you.

I believe SPI has a faster baud and that might be an issue also.

This is such a great project I can not wait to see the utube videos in action.

Ralph