STM32 blinking 30 LED's!

[bjdhjy888]

I'm sure my STM32 min. system is working, as I have tested it before. My Keil 5 generated .hex file could be flashed to blink an LED.

Now, I've added 29 more LED's in total.

Group A: 10 LED's in blue
Group B: 10 LED's in red
Group C: 10 LED's in yellow

My goal is to display:
    - the letter I with the blue LED's
    - the shape heart with the red LED's
    - and the letter U with the yellow LED's. In other words, 30 LED's are used to visually show: I heart U.

Would this be possible to do in theory?

Do I simply modify my current codes from:
      GPIO_WriteBit(LEDPORT,LED1,(BitAction)(1)); 
      delay_us(50000); 
      GPIO_WriteBit(LEDPORT,LED1,(BitAction)(0)); 
      delay_us(50000); 
to:
29 more code blocks added to the above one?

I fear PA0~PC13 cannot be controlled to finish this task.

Is my logic right?

Please help. Thank you!

[Renate]

No, the type of code that you are showing is clearly demo code.

It's my personal prejudice, but I hate seeing the word "delay".

Here's some very fake code for how I would write it:

Code: [Select]

THIS IS NOT REAL CODE!

void main(void)
{
   init_timer(); // how about a 1 mSec timer?
   // enable interrupts
   for(;;)
      sleep();
}

uint8_t prescaler;
uint8_t state;

void timer_ISR()
{
   // I could check switches here or something

   prescaler++;
   if (prescaler<250) return;
   prescaler=0;

   switch(state)
   {
     // turn on some LEDs, turn off some LEDs depending on what state
   }
   state++;
   if (state<NSTATES) return;
   state=0;
}You could do this if you kept to one pin per LED.
If you multiplexed your LEDs you would save pins, but you would have to rotate through separate banks of LEDs every 1 mS (or whatever).

I don't do STM32, but aren't there better examples?

[james_s]

If you're trying to display things with 3 groups of LEDs do you even need each LED in a group to be individually controlled?

[OM222O]

if you need individual LED control with as few pins as possible, you should use charliplexing. Most MCUs don't support the tri-state mode but it should still give you a very reasonable pin count (15 rather than 30). the only downside is you can't have both LEDs on at the same time, so if you want to have both of them on at the same time, a trick is to control with PWM and use a smaller value resistor, so the brightness looks the same.

About coding, you can do a fake "real time timer" by creating variables. I haven't written code for STM32 but the general idea is the same. you create a variable which keeps the time and you use multiple if statements, here is an example from arduino:

Code: [Select]

unsigned long lastMillis;
int i=0;
void setup() {
  pinMode(2,INPUT);
  pinMode(3,OUTPUT);
  pinMode(4,OUTPUT);
  pinMode(LED_BUILTIN,OUTPUT);
  Serial.begin(9600);
  lastMillis=millis();
}

void loop() {
  if ((millis() -lastMillis) > 5000){
    i++;
    lastMillis=millis();
    if (i==1){
      digitalWrite(3,1);
      digitalWrite(4,0);
      Serial.println("3 is on");
    } else if(i==2) {
      digitalWrite(3,0);
      digitalWrite(4,1);
      Serial.println("4 is on");
    } else if(i==3) {
      digitalWrite(3,1);
      digitalWrite(4,1);
      Serial.println("3 and 4 are on");
    } else {
      digitalWrite(3,0);
      digitalWrite(4,0);
      i=0;
      Serial.println("reset");
    }
  }
  digitalWrite(LED_BUILTIN,digitalRead(2));
}

it's a psudo state machine, where "i" is the state and at each state the digital outputs change. this allows the line outside the "timer" (digitalWrite(LED_BUILTIN,digitalRead(2)) to be updated at maximum frequency (you can test it by connecting the digital pin 2, to a high or low state; that should update the LED status "instantly"), while the state update is "delayed" for 5 seconds. I'm sure you can convert it to work with STM32. A lot of details are missing from your project description, but I hope this helped 

The timing accuracy will be a bit off here, but I don't think you require precision timing for driving LEDs anyways.

[daqq]

Most MCUs don't support the tri-state mode however but it should still give you a very reasonable pin count (15 rather than 30).

Which current generation MCU does not support tri-state GPIOs?

[eliocor]

please take care of:
- maximum microcontroller permissible current
- different Vf of LEDs (different resistor values)
- different efficiency of LEDs

[OM222O]

Most MCUs don't support the tri-state mode however but it should still give you a very reasonable pin count (15 rather than 30).

Which current generation MCU does not support tri-state GPIOs?

pretty much none!  you can play around with tricks such as setting them to input to simulate a High-Z state, but it's not a real tri-state pin. Please let me know if there are ones that natively support tri-state output without hacks!

Edit: changing the the pin mode also generally takes a few clock cycles (unless using direct register manipulation, which is not beginner friendly at all!) compared to just turning a pin on/off (although in arduino, even that takes a few cycles too for some reason! I ended up writing my own bit of code for that XD) so it's a slower operation.

[Yansi]

Changing to HiZ takes a few clocks you say?   And changing output to 1 or 0 doesn't taky any or what?

I think I shall not visit any arduino threads, or I'll get a stroke.

[langwadt]

Most MCUs don't support the tri-state mode however but it should still give you a very reasonable pin count (15 rather than 30).

Which current generation MCU does not support tri-state GPIOs?

pretty much none!  you can play around with tricks such as setting them to input to simulate a High-Z state, but it's not a real tri-state pin. Please let me know if there are ones that natively support tri-state output without hacks!

what 's not "real tri-state" about setting a pin to input?

[GeorgeOfTheJungle]

[..] you can play around with tricks such as setting them to input to simulate a High-Z state, but it's not a real tri-state pin [..]

States 1 and 2: ON and OFF, third state: not driven/floating.

[Renate]

If you need individual LED control with as few pins as possible, you should use charlieplexing.

But since we've got enough pins, some degree of multiplexing would be sensible without getting into the duty cycle or constant current driving problems of charlieplexing.

Code: [Select]

if ((millis() -lastMillis) > 5000)

Are we there yet?
Are we there yet?
Are we there yet?

You can play around with tricks such as setting them to input to simulate a High-Z state, but it's not a real tri-state pin.

The DDR registers are simply tri-state enables. They only affect the output enable. All port pins are always actively inputs.
From Atmega328P datasheet.

Independent of the setting of Data Direction bit DDxn, the port pin can be read through the PINxn Register bit.

I think I shall not visit any arduino threads, or I'll get a stroke.

I think that I'm with you on this one.

[OM222O]

Changing to HiZ takes a few clocks you say?   And changing output to 1 or 0 doesn't taky any or what?

I think I shall not visit any arduino threads, or I'll get a stroke.

It takes only 1 cycle via direct register manipulation, you can test it with an oscilloscope. just write pin change statements one after another and see how the frequency is 16MHz for something like arduino nano, uno, etc (which is the system clock). (make sure to write them back to back, and not just two inside a loop, the loop itself takes something like 8 or 10 cycles as far as I can remember). then repeat the same experiment: write the pin to output high, set it to input, back to output high and repeat a few times. even with direct register control, it takes more than 1 cycle to do it (I'm not sure exactly how many since I did this a long time ago! might be worth repeating to take some pictures this time).

Are we there yet?
Are we there yet?
Are we there yet?

Going into actual interrupt timers would be opening a whole new can of worms, but it would be a better and more accurate method, I agree! this was just a quick and dirty workaround 

what 's not "real tri-state" about setting a pin to input?

I really don't want to get into nitty-gritty details, but that creates a quasi tri state logic device. You can refer to arduino forums / Wikipedia for low level details 

Edit: regarding speed testing of arduino, julian ilett has done a video on it that you can watch here if you don't wanna go through the trouble of actually doing it yourself  :

[langwadt]

what 's not "real tri-state" about setting a pin to input?

I really don't want to get into nitty-gritty details, but that creates a quasi tri state logic device. You can refer to arduino forums / Wikipedia for low level details 

so it is tri-state but "quasi tri state logic device" sounds more fancy?

[OM222O]

so it is tri-state but "quasi tri state logic device" sounds more fancy?

not quite!
To put it in very basic terms: High Z mode is basically like an open circuit (think of it as a switch that disconnects the pin from the circuit). In most micro controllers they don't implement a Tri-State buffer, rather an "Output Enable" for the output driver and leave the pin connected to the input like others mentioned:

The DDR registers are simply tri-state enables. They only affect the output enable. All port pins are always actively inputs.
From Atmega328P datasheet.

Independent of the setting of Data Direction bit DDxn, the port pin can be read through the PINxn Register bit.

That means by de-activating the output enable, you're not driving the pin anymore, but it's also not in the high impedance mode (it's not actually disconnected), hence the name: "quasi tri-state"

You can read more here: https://en.wikipedia.org/wiki/Three-state_logic
There's just a subtle difference in terminology and low level technical details, but you can think of the two as functionally equal.

I have to apologize to the OP since this topic has gone off on a huge tangent, please focus on the main question that the OP asked. Thanks 

[Renate]

Julian Ilett has done a video on it...

That video should really be entitled, "How slow can you make an ATmel processor if you are silly enough to use digitalWrite()?"
And no, I didn't watch all 15 minutes.

[langwadt]

so it is tri-state but "quasi tri state logic device" sounds more fancy?

not quite!
To put it in very basic terms: High Z mode is basically like an open circuit (think of it as a switch that disconnects the pin from the circuit). In most micro controllers they don't implement a Tri-State buffer, rather an "Output Enable" for the output driver and leave the pin connected to the input like others mentioned:

The DDR registers are simply tri-state enables. They only affect the output enable. All port pins are always actively inputs.
From Atmega328P datasheet.

Independent of the setting of Data Direction bit DDxn, the port pin can be read through the PINxn Register bit.

That means by de-activating the output enable, you're not driving the pin anymore, but it's also not in the high impedance mode (it's not actually disconnected), hence the name: "quasi tri-state"

You can read more here: https://en.wikipedia.org/wiki/Three-state_logic
There's just a subtle difference in terminology and low level technical details, but you can think of the two as functionally equal.

I have to apologize to the OP since this topic has gone off on a huge tangent, please focus on the main question that the OP asked. Thanks 

a sketch on wikipedia, really? and how is an input not high impedance mode?

https://patents.google.com/patent/US3845328

[Renate]

Yeah, @langwadt, it's just like Heisenberg's Uncertainty Principle.
An output can be a real three-state output, but once you look at it, it can only be a semi-pseudo-fake-three-state-impersonator output.
So, no peeking!

[Dave]

To put it in very basic terms: High Z mode is basically like an open circuit (think of it as a switch that disconnects the pin from the circuit). In most micro controllers they don't implement a Tri-State buffer, rather an "Output Enable" for the output driver and leave the pin connected to the input like others mentioned:
<...>
That means by de-activating the output enable, you're not driving the pin anymore, but it's also not in the high impedance mode (it's not actually disconnected), hence the name: "quasi tri-state"

Absolute nonsense.

Tri-state just means that both N and P channel transistors that are driving the pin are turned off. Not "tugging" on the pin in either direction, leaving the pin to go to any potential within the power rails.
No pin in any logic chip is EVER really disconnected the way you think they are. You need a physical relay to do that.

[OM222O]

Absolute nonsense.

Tri-state just means that both N and P channel transistors that are driving the pin are turned off. Not "tugging" on the pin in either direction, leaving the pin to go to any potential within the power rails.
No pin in any logic chip is EVER really disconnected the way you think they are. You need a physical relay to do that.

I didn't mean physically disconnected like relay? 
To just finish this argument, try this:
1) Set the pin mode to input
2) Write a logic high or low to the input
3) See how it "drives" the input pin with internal pullups
4) Realize a true tri-state buffer doesn't do that without additional circuitry

example code for arduino:

Code: [Select]

pinMode(2,INPUT);
digitalWrite(2,HIGH):
Or the alternative:

Code: [Select]

pinMode(2,INPUT_PULLUP);

that's just one of the side effects of simulating a tri-state buffer rather than having an actual one. also look up the equivalent circuits of any MCU and see how they work. none of them have a tri-state buffer inside them 

P.S: I won't comment / correct any further arguments, since this thread has gone way off the rails already and nobody is trying to help OP, rather trying to prove me wrong 

[GeorgeOfTheJungle]

If you do an INPUT_PULLUP it's being driven. Very weakly, but driven. So... don't do that! In INPUT mode it's not being driven, and that's what "tri-stated" means: "not driven, floating".

[Jeroen3]

Technically it still leaks into the input schmitt trigger. It should be possible to disable this as well by setting it to analog. But what are you even doing when this is relevant!?

Anyway, this circuit definitely violates the 150mA Vdd absolute maximum.

[Berni]

MCUs don't have a true tristate?

I really don't get it. On pretty much any MCU when you put a pin into tristate mode and then write anything you want to it you can't see the pin do anything on the outside, it just floats freely. As for pullups or pulldowns, they can be turned on or off at will.

So how about open collector output mode then? Are they also fake open collector outputs, because the transistor for pulling it up still exists inside the chip but is never turned on?

[Yansi]

Technically it still leaks into the input schmitt trigger. It should be possible to disable this as well by setting it to analog. But what are you even doing when this is relevant!?

Anyway, this circuit definitely violates the 150mA Vdd absolute maximum.

And then i will leak to the analog interface circuitry. 

It violates more than that. But in a thread, where there is lack of basic understanding, what a Hi-Z state is and how it is achieved, this probably does not matter much.

[Yansi]

[Jeroen3]

Maximum 1 uA leakage current (in or out) is pretty close to Tri-State if you ask me.
Even though it may or may not be the textbook Tri-State in the silicon.