Interrupt on end of sequence and read both ADCs. I predict that there is a way to sample all channels simultaneously and then this will sequentially convert them.
Not sure. Using the while loop isn't absolutely required. Interrupts are called on stimulus regardless of the while loop. Chips may handle interrupts differently. Check out the datasheet for more in-depth information on how interrupts are called and what triggers them using the block level diagrams.
@@PatrickHoodDaniel i think the whole point of an interrupt is that it interrupts any other code. So the ADC interrupt should interrupt the while loop. The questions is, will the ADC interrupt wait until the currently-running line of code finished executing? Or will the ADC interrupt flush all registers and start executing instantly? If it waits for the current line, there will latency.
8:27 I believe that, if you want channel-number var to equal the actual ADC channel should be alternate between 1 and 4. Incrementing the channel number by 1 when you're using ch's 1 and 4 means your channel-number var ISN'T the actual channel number. That's poor form. A named var should contain what it actually is. This device supports up to 16 channels. What if you're using ch's 1, 2, 4, 6, 10, 11? Incrementing the channel-number var makes even less sense. In that case, i think you might want an array containing used_channels {1, 2, 4, 6, 10, 11}. Then, have a global var called active_channel_index, which walks through that array. Yes, those are long variable names -- long, meaningful, accurate, and understandable.
As it's currently written, the while loop will repeatedly write values to the display, even there haven't been any interrupts, meaning even if the value hasn't changed. That seems very inefficient and redundant. There's no synchronization between the ADC and the display. We should logically only write to the display when then ADC grabs a value. i understand that we want to free up the ADC interrupt so that display-writes don't block the ADC. So that's why you keep the ADC interrupt fx as short as possible. However, if the ADC interrupts are coming that often, then how will the while-loop ever have enough time to execute? If your while loop has enough time to execute, then wouldn't a display-write inside the ADC interrupt also have time to execute?
Programming the ADC's is what I am truly interested in. I am planning to build my own Li-Ion (DIY Telsa-style Powerwall's) charge controller with built in balancing capabilities. I think this chip can do everything I need for the project. I am excited. I was not able to purchase the kit ( like i said I would few weeks back), because I needed to raise some cash for the project, but I just ordered the advanced kit with an extra STM32 breakout. I hope people continue to buy direct from NewbieHack and help support these great instructional series
I have got a long way to go to get to my end result, but Ill start by rebuilding each project you have done and learn my way around the chip. May I ask, with the chip being a couple years old now, do you regularly spin new boards as they update the ARM chip series?
The Combat Engineer I may, but chips are always chosen by their minimal capabilities for a particular application. The instruction set rarely differs from a chip like this and a more advanced chip. The differences are typically speed, memory and the number of features. I cover all of the features, so all you will need to do is for find the chip that meets your needs for your end goal.
Very intuitive method to perform "simultaneous" conversions. By the way, I appreciate the time you take to resolve doubts in the comments (especially the response time), thank you.
Program flow is all sequential. It all just happens very fast and appears simultaneous. If you remember that the operations happen within a microcontroller (or computer), in a sequential manner, programming becomes quite simple.
If I use multiple channels for the same ADC then the channels will use the same dataregister (DR) (at least for STM32f4). If I have the ADCs in scan mode (i.e will do A/D conversion for each channel directly after one another) the DR will be overwritten I think, unless I store the data somewhere else after each conversion. DMA is Direct Memory Access and it seems that it's used often for this purpose.
Thanks for the clarification. If you are using interrupts, you should be able to capture the data before it is overwritten as the program cycles is probably faster than the A/D conversion, but I'm guessing here. I will need to do some digging to give you a proper answer. I haven't delved into the DMA realm yet.
Interrupt on end of sequence and read both ADCs. I predict that there is a way to sample all channels simultaneously and then this will sequentially convert them.
Awesome man. I absolutely love the stop-frame photography as well!
Ha! Thanks!! It's better than looking at my gnarly fingernails!!
Interrupt on end of sequence and read both ADCs. I predict that there is a way to sample all channels simultaneously and then this will sequentially convert them.
One of the Best explanation I had ever seen!! thanks a lot. truly appreciative
Ren Surya Thanks!!
channel ^= 1; // if only 2 channels are monitored.
Why is the while loop even needed inside main? Won't it just introduce latency into the interrupts?
Not sure. Using the while loop isn't absolutely required. Interrupts are called on stimulus regardless of the while loop. Chips may handle interrupts differently. Check out the datasheet for more in-depth information on how interrupts are called and what triggers them using the block level diagrams.
@@PatrickHoodDaniel i think the whole point of an interrupt is that it interrupts any other code. So the ADC interrupt should interrupt the while loop. The questions is, will the ADC interrupt wait until the currently-running line of code finished executing? Or will the ADC interrupt flush all registers and start executing instantly? If it waits for the current line, there will latency.
@@johnaweiss Yeah, I've got no idea.
8:27 I believe that, if you want channel-number var to equal the actual ADC channel should be alternate between 1 and 4. Incrementing the channel number by 1 when you're using ch's 1 and 4 means your channel-number var ISN'T the actual channel number. That's poor form. A named var should contain what it actually is.
This device supports up to 16 channels. What if you're using ch's 1, 2, 4, 6, 10, 11? Incrementing the channel-number var makes even less sense. In that case, i think you might want an array containing used_channels {1, 2, 4, 6, 10, 11}. Then, have a global var called active_channel_index, which walks through that array. Yes, those are long variable names -- long, meaningful, accurate, and understandable.
As it's currently written, the while loop will repeatedly write values to the display, even there haven't been any interrupts, meaning even if the value hasn't changed.
That seems very inefficient and redundant. There's no synchronization between the ADC and the display. We should logically only write to the display when then ADC grabs a value.
i understand that we want to free up the ADC interrupt so that display-writes don't block the ADC. So that's why you keep the ADC interrupt fx as short as possible.
However, if the ADC interrupts are coming that often, then how will the while-loop ever have enough time to execute? If your while loop has enough time to execute, then wouldn't a display-write inside the ADC interrupt also have time to execute?
Programming the ADC's is what I am truly interested in. I am planning to build my own Li-Ion (DIY Telsa-style Powerwall's) charge controller with built in balancing capabilities. I think this chip can do everything I need for the project. I am excited. I was not able to purchase the kit ( like i said I would few weeks back), because I needed to raise some cash for the project, but I just ordered the advanced kit with an extra STM32 breakout. I hope people continue to buy direct from NewbieHack and help support these great instructional series
Thank you kindly! That helps.
Oh yeah, good luck on your project and please keep me posted on your results.
I have got a long way to go to get to my end result, but Ill start by rebuilding each project you have done and learn my way around the chip. May I ask, with the chip being a couple years old now, do you regularly spin new boards as they update the ARM chip series?
The Combat Engineer I may, but chips are always chosen by their minimal capabilities for a particular application. The instruction set rarely differs from a chip like this and a more advanced chip. The differences are typically speed, memory and the number of features. I cover all of the features, so all you will need to do is for find the chip that meets your needs for your end goal.
I sent an email about the order but got an auto-reply. Trying to see if it went through and get the tracking info.
So that menas, the 15 available channels can be displayed simultaneously?
Yes. All you are doing is converting them one at a time.
Very intuitive method to perform "simultaneous" conversions. By the way, I appreciate the time you take to resolve doubts in the comments (especially the response time), thank you.
Program flow is all sequential. It all just happens very fast and appears simultaneous. If you remember that the operations happen within a microcontroller (or computer), in a sequential manner, programming becomes quite simple.
Is it correct that I must use DMA if I want to use the same ADC (e.g. ADC1) for multiple inputs, since they will share the same DR?
Can you clarify what DMA is and what DR is? Thanks.
If I use multiple channels for the same ADC then the channels will use the same dataregister (DR) (at least for STM32f4). If I have the ADCs in scan mode (i.e will do A/D conversion for each channel directly after one another) the DR will be overwritten I think, unless I store the data somewhere else after each conversion. DMA is Direct Memory Access and it seems that it's used often for this purpose.
Thanks for the clarification. If you are using interrupts, you should be able to capture the data before it is overwritten as the program cycles is probably faster than the A/D conversion, but I'm guessing here. I will need to do some digging to give you a proper answer. I haven't delved into the DMA realm yet.
Great
Interrupt on end of sequence and read both ADCs. I predict that there is a way to sample all channels simultaneously and then this will sequentially convert them.
would love to see that
End of sequence interrupt enable bit in the interrupt enable register.
channel ^= 1; // if only 2 channels are monitored.