Jawne rzutowanie w AVR GCC

[Krawi92]

Witam, mam taki problem. Stworzyłem tablice na potrzebę wyswietlacza multipleksowanego LED, żeby wygodnie wyświetlać cyfry. Tablica jest typu uint8_t. Wszystko było ok dopóki do tablicy nie dodałem kropki DP. Wtedy kompilator wywala warnign, że używam nie odpowiedniego typu. Gdy zmienie typ na uint16_t jest ok. Przeczytałem, że zamiast takiej operacji, żeby nie tracić dodatkowo pamięci zastosować jawne rzutowanie. Dostałem odpowiedz "Wszystkie stałe zdefiniowane za pomocą #define, albo stałe dosłowne czyli właśnie (1<<7) kompilator rzutuje sobie domyślnie ale niejawnie do typu int (2 bajty)". I tu problem mam ze zrozumieniem tego. Wrzucę kod 2 plików 

// d_led.c//
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include "d_led.h"

volatile uint8_t cy1;
volatile uint8_t cy2;
volatile uint8_t cy3;
volatile uint8_t cy4;

const uint8_t cyfry[] PROGMEM = {
		~(SEG_A|SEG_B|SEG_C|SEG_D|SEG_E|SEG_F), // 0
		~(SEG_B|SEG_C), // 1
		~(SEG_A|SEG_B|SEG_D|SEG_E|SEG_G), // 2
		~(SEG_A|SEG_B|SEG_C|SEG_D|SEG_G), //3
		~(SEG_B|SEG_C|SEG_F|SEG_G), // 4
		~(SEG_A|SEG_C|SEG_D|SEG_F|SEG_G), // 5
		~(SEG_A|SEG_C|SEG_D|SEG_E|SEG_F|SEG_G), // 6
		~(SEG_A|SEG_B|SEG_C|SEG_F), // 7
		~(SEG_A|SEG_B|SEG_C|SEG_D|SEG_E|SEG_F|SEG_G), // 8
		~(SEG_A|SEG_B|SEG_C|SEG_D|SEG_F|SEG_G), //9
		~(SEG_D|SEG_E|SEG_F), // litera L
		~(SEG_A|SEG_B|SEG_C|SEG_G|SEG_E|SEG_F), // litera A
		~(SEG_DP), // kropka
};

void d_led_init(void) { // inicjacja wyswietlacza i timera

	LED_DATA_DIR = 0xFF; // wszystkie piny portu D jako wyjscia segmentow
	LED_DATA = 0xFF; // wygaszenie segmentów
	ANODY_DIR |= CA1|CA2|CA3|CA4; // Anody jako wyjscia
	ANODY_PORT |= CA1|CA2|CA3|CA4; // wylaczenie anod - stan wysoki

	TCCR0A |= (1<<WGM01); // tryb ctc timer8bit
	TCCR0B |= (1<<CS00)|(1<<CS02); // prescaler 1024
	OCR0A = 38;
	TIMSK0 |= (1<<OCIE0A); // zezwolenie na przerwanie compare match
}
ISR(TIMER0_COMPA_vect) { // procedura obslugi przerwania
static uint8_t licznik = 1;

	ANODY_PORT = ( ANODY_PORT & 0xF0) | (~licznik & 0x0F); // zamaskowanie ANOD PC0-PC3
	if (licznik == 1 ) LED_DATA = pgm_read_byte(&cyfry[cy1]);
	else if (licznik == 2) LED_DATA = pgm_read_byte(&cyfry[cy2]);
	else if (licznik == 4) LED_DATA = pgm_read_byte(&cyfry[cy3]);
	else if (licznik == 8) LED_DATA = pgm_read_byte(&cyfry[cy4]);

	licznik <<= 1;
	if (licznik>8) licznik = 1;

}

/*
 * d_led.h
 *
 *  Created on: 10 wrz 2021
 *      Author: User
 */

#ifndef D_LED_H_
#define D_LED_H_

#define LED_DATA_DIR DDRD // kierunek wyjsciowy segmentow
#define LED_DATA PORTD // stan segmentow
#define ANODY_PORT PORTC // stan anod
#define ANODY_DIR DDRC // kierunek wyjsciowy anod

#define CA1 (1<<PC3) // anoda 1
#define CA2 (1<<PC2) // anoda 2
#define CA3 (1<<PC1) // anoda 3
#define CA4 (1<<PC0) // anoda 4

// ========Makra segmentow ============ //
#define SEG_A (1<<0)
#define SEG_B (1<<1)
#define SEG_C (1<<2)
#define SEG_D (1<<3)
#define SEG_E (1<<4)
#define SEG_F (1<<5)
#define SEG_G (1<<6)
#define SEG_DP (1<<7)


extern volatile uint8_t cy1; // zmienne dostepne w innych plikach projektu
extern volatile uint8_t cy2;
extern volatile uint8_t cy3;
extern volatile uint8_t cy4;

void d_led_init(void); // deklaracja funkcji

#endif /* D_LED_H_ */

Nie mogę zrozumieć, czemu gdy korzystam z makr od (1<<0) do (1<<6) to nie mam warningów, a gdy użyje w tablicy (1<<7) to już jest. Nie bardzo też wiem, jak w tym kodzie zastosować to jawne rzutowanie. 

[farmaceuta]

Moge sie mylic, bo szczerze to strzelam, ale jawne rzutowanie wyglada tak..

(uint8_t)~(SEG_DP),

Choc dziwne by bylo ze reszta bez rzutowania dziala a to akurat nie, wiec nie wiem czy to rozwiaze twoj problem...cza na mondzejszych poczekac..😅

[Krawi92]

Oo, problem rozwiązało. Próbowałem w różnych miejscach robić to rzutowanie, a nie wpadłem, że trzeba zrobić to przed.. Tylko właśnie teraz chodzi o zrozumienie tego, czemu akurat przy operacji bitowej 1<<7 wywala błąd. 😕

[farmaceuta]

3 minuty temu, Krawi92 napisał:

Tylko właśnie teraz chodzi o zrozumienie tego, czemu akurat przy operacji bitowej 1<<7 wywala błąd. 😕

Nie pomoge bo nie wiem...😢 ale...rzutowanie to bardzo wazna kwestia i radze Ci sie za nia wziasc, bo szybko zderzysz sie z problemem poprawnego rownania ktore daje "zly" wynik...w skrocie wynik zostaje niejawnie rzutowany do typu int, chyba ze w rownaniu wystepuje wiekszy typ...poprostu rzutuje do najwiekszego typu...np. takie cos...

int a = 50000
int b = 50000
uint32_t x
  
x = a + b

bedzie zawierac blad...bo obie zmienne sa typu int i na taki typ zostanie wykonane rzutowanie, a liczba 100tys. juz sie nie miesci w 16bitach i bedziesz mial blad...poprostu otrzymasz tylko 16 bitow zamiast pelnej liczby...to samo jesli chodzi o floaty czy dlugie rownania ktore sa "podzielone" nawiasami...tam tez czesto trzeba zwracac uwage na rzutowanie zeby wszystko bylo ok...

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[farmaceuta]

Pozatym ta tablice moglbys zapisac w postaci szesnastkowej...jakos tak lepiej by wygladalo...😉

[H1M4W4R1]

20 godzin temu, Krawi92 napisał:

Oo, problem rozwiązało. Próbowałem w różnych miejscach robić to rzutowanie, a nie wpadłem, że trzeba zrobić to przed.. Tylko właśnie teraz chodzi o zrozumienie tego, czemu akurat przy operacji bitowej 1<<7 wywala błąd. 😕

Kompilator uznaje twój #define jako liczbę ze znakiem, a ~(1 << 7) w "trybie znakowym" to -129, czyli wypadasz poza zakres liczb 8-bitowych, stąd kompilator ma problemy z konwersją, bo musi wykonać overflow przez zakres by tę liczbę skonwertować do 8-bitowej, czego zazwyczaj się unika, bo jak się człowiek zapomni to może tworzyć dziwne artefakty po zmianie platformy na np. 64-bitową.

Edytowano Wrzesień 13, 2021 przez H1M4W4R1

[Krawi92]

Teraz pytanie skąd wzięło się to - 129.. Rysowałem na kartce sobie binarnie to, sumowalem wagi po zanegowaniu i no coś innego mi wychodzi 

[farmaceuta]

58 minut temu, H1M4W4R1 napisał:

 a ~(1 << 7) w "trybie znakowym" to -129

No jak? Mi wychodzi 127...czyli przesuniecie..

0b10000000

a po negacji...

0b01111111

Czyli 127...🤔 (odrazu mowie ze sie nie wymadrzam tylko probuje zrozumiec, bo byc moze czegos nie kumam...)

Edytowano Wrzesień 13, 2021 przez farmaceuta

[H1M4W4R1]

Nie ważne co wychodzi na kartce, ważne co liczy kompilator 😛 Przyzwyczaj się, bo to często spotykane błędy są.

A tutaj skąd:

(1 << 7) =  0b010000000 // (128)
~(1 << 7) = 0b101111111 // (-129)

Matematyka w programowaniu to trudny temat... Mnie nawet kiedyś się zdarzyło, że kompilator twierdził, że 1 > 12.

Edytowano Wrzesień 13, 2021 przez H1M4W4R1

[farmaceuta]

nie moge gdzies zalapac...bitem znaku jest najstarszy bit tak? A skoro wyniki sa nie jawnie rzutowane do int to we wszystkich makrach powinien byc blad...🤔(?) bez znaczenia ile bitow przesunal...

edit...faktycznie to jeszcze troszke inaczej idzie i tylko w tym makrze bedzie blad...trzeba sie wczytac w ten temat, bo juz mi sie to chyba o oczy obilo, ale guzik pamietam...

Edytowano Wrzesień 13, 2021 przez farmaceuta

[Krawi92]

Zakres np 8bitowej zmiennej char ma zakres - 128 do 127,zatem no 1<<7 by się jeszcze mieściło ale ~1<<7 już nie. Ale narazie to trochę dla mnie pomieszane 

[H1M4W4R1]

2 godziny temu, farmaceuta napisał:

nie moge gdzies zalapac...bitem znaku jest najstarszy bit tak? A skoro wyniki sa nie jawnie rzutowane do int to we wszystkich makrach powinien byc blad...🤔(?) bez znaczenia ile bitow przesunal...

Ja to trochę uprościłem 😛 Tak dość mocno...

Powiedzmy, że matematykę zostawiamy w spokoju. Po prostu w jednym z momentów obliczenia wychodzi poza oczekiwany zakres, co kompilatorowi się nie podoba. 😉 

Pamiętaj, że każda liczba "signed" ma na początku "znak" (dobra, trochę źle się wysławiam... to -2^n, które przesuwa nam zakres liczb, stąd też bierze się szerszy zakres na minusach niż na plusach). Wynika to z metody zapisu (pierwszy bit to -2^n, a reszta to 2^n). Nawet jeżeli masz liczbę dodatnią, to na początku jest bit 0, który też jest uwzględniany przy negacji. A reszta to magia kompilatora, nad którą lepiej się nie rozwodzić, bo można by o tym stworzyć cały kierunek studiów.

P.S.

128(signed) = 0b010000000

Edytowano Wrzesień 13, 2021 przez H1M4W4R1

[ethanak]

Ja tylko tak...

const uint8_t zmienna = (cośtam) & 0xff;

To raczej poza 8 bitów nie wylezie 🙂

Można np. tak:
 

#define B8(a) ((a) & 0xff)
#define N8(a) ((~(a)) & 0xff)

 

i dalej w stylu:

const uint8_t zmienna = N8((1<<7) | (1<<6));

Można i tak...

 

 

 

[Krawi92]

Ja jak narazie średnio rozumiem o co tu chodzi. Myślę że narazie dobrze będzie, jak będę umiał zareagowac na ew warning i zrobić jawne rzutowanie 

[farmaceuta]

Chodzi o to ze twoj wynik zostaje skrocony/uciety do 8-bitow

#define N8(a) ((~(a)) & 0xff)

zapis 0xff oznacza binarnie 0b11111111...i teraz cala reszta poza tymi osmioma jedynkami zostaje jaky usunieta i zostaje tylko liczba 8- bitowa, czyli taka jaka Cie interesuje..