Is it possible to add something, such as a microcontroller, to act as a new node that will integrate into the CAN bus system and be dominant over other nodes or at least speak on the bus to work what you're trying to work other than reverse engineer the whole CAN bus?
Electronic – CAN bus possibilities
canmicrocontrollersensor-node
Related Solutions
For a 0.25Hz sample rate, I think either bus should be fine. CAN has more "built in" features of message prioritization and arbitration and so on than RS-485. So you'd have a somewhat more complex but somewhat higher level protocol with CAN. The electrical signal and power supply requirements for wiring would be virtually identical for either case. You say "synchronized" sampling is required, but do not define what precision and accuracy and latency of "synchronization" is required.
If you had to have the sampling "simultaneous" within nanoseconds then you'd have some significant additional concerns relating to communications latency, wiring delays, etc. But I suspect that since you didn't define the requirement and are considering "relatively" low performance buses without mentioning any kind of triggering / clocking strobe for the sampling trigger, you may be happy enough with synchronization down to the level of several microseconds or longer. If that is the case either bus is probably potentially workable for you depending on the architecture of your system.
Do the nodes sample autonomously at the predetermined rate and sampling times? If so, that makes it easier so long as the sampling clocks on the nodes are maintained in sufficient synchronism. If the nodes each wait for a "sample now" command on the communications bus then you may want to consider what happens if the message reception is occasionally delayed or lost by one or more nodes. In such a case the synchronization of the sampling may be lost or the sampling point delayed.
How about the transmission order of the sampled data to the controller? If the nodes are sharing a common serial bus, one must send its result before the others, so there will be a chance for bus arbitration conflicts. Unless there are parallel independent buses going to each node, some nodes' data transmissions will be delayed by by virtue of being transmitted later than other nodes. How will the bus arbitration work? Will each node be polled in turn or speak in turn? How about message retransmission if acknowledgement is not received due to bus contention or transmission errors or other circumstances?
If the nodes have local clocks used to timestamp the sampling data and possibly determine the sampling times, how will the clock synchronization be maintained? So, you see, you end up with the same kinds of potential problems and potential solutions / architectures whatever bus you use. CAN provides some higher level protocol features to assist with structuring some aspects of bus contention, arbitration, prioritization, retransmission, error detection, etc. You can implement similar things in RS-485 with your own protocol. In the end the most important aspects of the communication network are the architectural decisions and requirements relating to things like fault tolerance, timing, synchronization, error detection, error handling, network design & wiring, etc.
One possibility you didn't mention is Ethernet which has been augmented in some embedded applications with PTP that helps to synchronize and timestamp events between distributed nodes. Typically the ICs and components are somewhat more expensive to implement Ethernet vs. CAN or RS-485, though that depends on your implementation choices, need for things like high levels of electrical isolation between the wiring and the nodes (possible with added circuitry in CAN, RS-485, or Ethernet, but only really expected as a baseline implementation approach in Ethernet). Ethernet gives you a possible standardized means to provide power to the nodes, though power is often run along with CAN or RS-485 too.
The issue with the AMIS42700 chip is that when trying to broadcast a message to all nodes, it seems to keep sending the same message repeatedly
This implies that the problem could as well be on the CAN controller level. There must be at least one CAN controller present who will acknowledge the reception of the message, or otherwise the controller will keep trying 128 times. Some troubleshooting to check:
Check for error or bus off flags from the transmitting CAN controller. Ensure that no CAN controllers are set to filter out certain identifiers. Ensure that they aren't in "listen-only" mode where they won't ack received frames. Ensure that no controller is in loopback mode (only talking with itself).
Do you get error frames on the bus or actual data? If you look for error frames with a plain oscilloscope, they look like small, single pulses. While data frames look like a train of binary ones and zeroes.
(For an error frame, it should start with 6 bits, which are either dominant or recessive depending on what error state the sending node is in: active error state=dominant bits, passive error state=recessive bits. A node is in active error state until after 128 attempts, when it reverts to passive and can no longer mess up bus arbitration. No matter if active or passive, this part of the frame violates the "bit stuffing" rule on purpose. CAN usually only tolerates up to 5 bits of equal level before using bit stuffing. So the only time when you should encounter 6 bits with same level in a row is during the error frame.)
What does the enable signals EN1 and EN2 look like on the master? Are they stable?
Same problem when you disconnect the second "slave" AMIS from the bus?
I will always suspect the most classic serial bus problem: what is tx and what is rx? (As a rule of thumb/Murphy, you always get these wrong no matter what you do :) ) It would seem that the AMIS circuit will act as a data communication "modem" in this case, or if you will just as any other plain CAN tranceiver. In that case you'll have to ensure that CAN controller Tx goes to AMIS Tx. Your schematic looks correct, but I would always double-check this.
I doubt the terminator resistors have much to do with the problem, since termination-related problems either have no notable effect on the communication (the bus may work fine without proper termination, especially on lower baudrates) or they cause the whole bus to go down, ie they work or they don't. In case they don't, no slave would be able to send anything either.
However, in the datasheet application example of AMIS-42700 (p4), they seem to prefer 60 Ohm, which implies that each of the individual buses should have the normal 120 Ohm termination in each end. As in: add two more 120 terminators on each bus and treat them as two buses not one.
Probably needless to say, but signal grounds need to be the same for both buses. So if they are located on physically different locations, it is not enough to just connect the Text and Rint signals, you must also connect signal grounds.
Strangely, when disconnecting one of the CAN lines (CANH or CANL) at a time, the communication could be established between nodes. In that case though I did not check CANH and CANL at the oscilloscope.
CAN is very rugged, so even when you do such evil things to it, it may still be able to "limp home" if you are lucky.
Best Answer
Yes, of course you can use a microcontroller as a node. I had used the CAN bus recently connected to three other microcontrollers (nodes). The biggest advantage of using CAN is that the CAN controller hardware present takes care of data collision and timing and so on which makes programming a CAN oriented system much easier.
If you had to work a bus topology using UART then it would have been much more difficult, but CAN is very convenient. And there is no dominant node on the bus; all nodes in CAN listen to whatever each node is sending, but by setting the acceptance filter value you can filter the contents. Every message has an ID and using the ID we get to know what the content of the data is about. A good basic framework of CAN is provided in the following link which you could check out. https://www.kvaser.com/about-can/the-can-protocol/
And the priority of the message being sent in the node depends on the identifier value of the message. A smaller identifier corresponds to a higher priority and there are also priority configuration where a particular node can send a message as soon as the current transaction is completed. Since all nodes listen to what you are sending the node that you want to act like a master could be close to a master.