Próbuję zapakować luźno działający program do biblioteki i za cholerę nie przyjmuje mi takiego zapisu:


i pokazuje błąd przy kompilacji, natomiast taki zapis:

przechodzi bez problemu tylko, że ja nie chcę 2-bajtowego "int" tylko 1-bajtowy "int8_t".

I pewnie bym sobie odpuścił gdyby nie fakt, że zanim rozdzieliłem pliki do xxx.c i xxx.h to właśnie "int8_t enc_get(void)" w programie działało i nie wywalało żadnych błędów, a on teraz cały czas krzyczy na czerwono, że "unknown type name 'int8_t'" po najechaniu kursorem na linię, a w konsoli: error: conflicting types for 'enc_get'. Nic już z tego nie rozumiem. Oczywiście gdy zostawię "int" to biblioteka działa jak należy, ale chodzi o sam fakt takiej selekcji - tu działa, a tam się obraża... Czy może znowu coś przegapiłem...?

------------------------ [ Dodano po: 10 minutach ]

Aha, wstawiłem "signed char" i zatwierdziło bez problemu, tylko ta rozbieżność interpretacji mnie interesuje.

_________________
http://www.sylwekkuna.com

Niestety, to nie pomogło, nadal ten sam błąd dla "int8_t"
Co ciekawe w momencie napisania tego "typu" nic nie podświetla, a dopiero kompilacja powoduje error.

_________________
http://www.sylwekkuna.com

masz źle.... hmmm bardzo źle porobione #inkludy w plikach

pokaż szkielet plików *.c i *.h tzn tylko jak masz zrobione includy oraz definicje i deklaracje odnośnie tej funkcji

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Oto prawie kompletne pliki ze wszystkimi zmiennymi. Prawie, bo wycięta tylko główna funkcja. Całość oczywiście prawidłowo działa o ile spełnione są warunki, o których pisałem wyżej.







Najprawdopodobniej to wina mojego małego doświadczenia w tworzeniu bibliotek, bo zrobiłem ich bardzo niewiele, a przy tym nie miałem potrzeby wykorzystywać akurat takiej funkcji z int8_t i pewnie dlatego problem dopiero teraz wyszedł. O wiele częściej modyfikowałem (nawet dość drastycznie) inne gotowe biblioteki do własnych potrzeb i tam problemu nie było. Właściwie to się zawsze bardziej na algorytmach skupiam niż na całej otoczce

_________________
http://www.sylwekkuna.com

Taka drobna uwaga z mojej strony. Zawsze dołączamy biblioteki "systemowe" _przed_ includami swoich bibliotek.

_________________
Pozdrawiam
PP

a kolega niby ma Bluebooka ... a tam już wyraźnie pisałem , nie mówiąc o wszystkich poradnikach i forum itp itd

ale za to - no teraz to już Sylwek zapamiętasz na całe życie - że

1. NAJPIERW inkludujemy pliki systemowe

2. PÓŹNIEJ inkludujemy własne pliki nagłówkowe

to jest prosta ale jakże ważna zasada

tzn pewnie może nie pomyślałeś jak działa inkludowanie i stąd takie pomysły może że kolejność jest nie ważna.

Tymczasem inkludowanie to nic innego jak (hmmm włączanie innych plików do tego pliku gdzie jest #include)

i teraz sobie pomyśl jak to wygląda




to skąd niby ma być znany typ int8_t na samej górze - skoro kompilator leci po kolei linia po linii ?

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Kurcze no i jak zwykle pogotowie błyskawicznie działa Dzięki panowie, mieliście rację. Teraz bez problemu przeszła kompilacja.
Co ciekawe moje myśli krążyły wokół tych inkludów i nawet w desperacji zacząłem zaglądać wczoraj do avr/io.h i szukać jakichś ograniczeń... a tu jak zwykle banał. Fakt teraz sobie przypominam, że była o tym mowa. Jak już wspomniałem wychodzi brak doświadczenia w czymś co robi się od święta czyli własne biblioteki

_________________
http://www.sylwekkuna.com

To że zapomniałeś o kolejności inkludów to banał ... każdemu może się zdarzyć

ale jak ty masz brak doświadczenia w programowaniu to ja jestem księdzem

Jak dla mnie "to jedno z najpiękniejszych przejść z Bascoma na C" na tym forum w twoim wykonaniu ... a że w samym Bascomie śmigałeś że aż strach (w pozytywnym tego słowa znaczeniu oczywiście!) to nie ma się dziwić, że w luźniejszym płaszczu jakim jest C - możesz się jeszcze bardziej "rozszaleć"! Tak trzymaj

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No właśnie w takich sytuacjach wychodzi brak doświadczenia
A chciałem przed publikacją mojej obsługi enkodera umieścić go w jakiejś zgrabnej w miarę wygodnej bibliotece tak dla wyprawki. Jak się okazuje warto było sobie przypomnieć zasady

_________________
http://www.sylwekkuna.com

Wcale nie trzeba włączać <stdint.h>. Jest on pośrednio włączany do projektu poprzez <avr/io.h>.

Nie to żebym się czepiał, bo moja wiedza na temat bibliotek jest średnia mówiąc szczerze, ale tworząc ją w zasadzie nie widzę jej zastosowania gdzieś gdzie by brakowało <avr/io.h>... Jeśli ktoś by już był na tyle zdesperowany, że na inny sprzęt by ją adoptował to pewnie upora się też z brakującym <stdint.h>. Tym bardziej dziwi mnie (a może po prostu nie rozumiem zagadnienia tak do końca) to co proponujesz, bo <avr/io.h> jest przecież w pliku biblioteki .c to jaki sens jest ją dublować? To takie moje skromne zdanie

_________________
http://www.sylwekkuna.com