The problem with CAN-PDB-ADC is circular. You're attempting to read the CAN bus with an ADC that is triggered by the CAN bus. Your ADC trigger won't start your ADC reads until your ADC sees a signal. The only thing I can think of is
have one of your ADC modules read continuously and trigger the second ADC module to read when it detects a signal.
So top level looks like this:
Inside action block is this:
ADC0 triggers the start of PDB1 which controls ADC1. I didn't try to run this, I just threw the blocks together for visual reference.
It seems more complex than it needs to be though. If you're already reading the CAN bus with ADC0 why not just use those values? Why the timing needs? You could start a timer anytime the ADC reads a high signal if you need timing. That would allow you to read both the high and low simultaneously. Also, why do you need to read both? Can't you just read one and assume the other is an inverted mirror of it? The reason Razvan asked what the task was is so that he could solve the correct problem. Solving the problem you have right now may turn out to be a dead end and a waste of time. There may be a better problem to solve.
Dylan
I think part of the problem is simply the meaning of the word synchronize, at least for me. When I see the word synchronize, I see "happens at the same time." If I'm using the term wrong, please correct me. The problem that I see with the synchronize approach (know that I am not an expert) is that there is no way to analyze the ADC and the CAN input at the same time.
In your second message you say you want:
"when the slave receive the three CAN messages, the leds turn on and simultaneously the ADC start the conversion."
This isn't possible because if you've already received the CAN message, there's nothing to read with the ADC.
I also see some problem with the term "receive" as you've used it above. The way the CAN system works is that once a CAN message is "received" it triggers the ISR. At this point, there is nothing on the bus to read.
To my knowledge, the only way to do something similar is you must store the ADC input and wait for the CAN Rx to complete so that you can then compare the two. Try reversing your process to look for ADC to go high (or low if you're on CAN L) first, then store your ADC inputs until the CAN message is complete. When the CAN system "receives" the message, the CAN ISR will trigger and you can then compare the two. This is not "synchronized" in the way I would use the term but it will allow you to compare the ADC to the CAN message, which I believe is what you're trying to accomplish.
I have used the adc_isr_s32k example and added to it below:
The if box waits until the ADC goes high (indicating a CAN message is on the bus) then stores it using an "if action" subsystem. That output goes to a compare subsystem that is triggered by the Rx Complete ISR block which also sends the CAN message over for the compare.
I have not attempted to test any of this, I'm just giving a visual reference to what I was saying above. Hopefully one of the more seasoned NXP employees will chime in if I'm incorrect.
