Witam,
Napisałem funkcję, która formatuje (w buforze) liczby, wstawia przecinek i wyrównuje do prawej strony.
W argumentach podajemy bufor, max długość wyświetlanej liczby i pozycję przecinka.
Np. Mając liczbę 123456789 i podając argumenty length=12, point_pos=3 otrzymamy wynik (w buforze) __123456.789
Wszystko fajnie działa, jednak mam problem z liczbami ujemnymi (poniżej jedności).
Zamiast otrzymać np. -0.088 otrzymuję 0.-88


Przykładowe zastosowanie do wyświetlenia liczby z przecinkiem


Może kogoś z kolegów oświeci i naprowadzi mnie na jakieś proste rozwiązanie tego problemu?

_________________
Gordon

To ja podpowiem - masz tą funkcje ładnie napisaną niezależnie od platformy - uruchom ją sobie na PC i prześledź debuggerem

Dzięki:) Tylko qrcze z debuggerami nie miałem za bardzo do czynienia. Jak na razie udawało mi się obchodzić bez tych dobrodziejstw. Jednak ambicje rosną, więc i trzeba będzie się nauczyć działać z tymi narzędziami.

_________________
Gordon

Możliwe rozwiązania:
1.
W pierwszej kolejności przed wywołaniem result convert sprawdź czy liczba jest ujemną,
Jeżeli tak to pomnóż ją przez -1. Zrobi ci się dodatnia i nie będzie problemu z "-" po przecinku.
Na końcu wstaw znak - jeżeli potrzebny przed cały otrzymany już string z przecinkiem.

2.
W funkcji result convert sprawdzasz czy pierwszy znak to "-".
Usuwasz go.
Dodajesz zera i przecinki.
W ostatniej kolejności dodajesz usunięty "-".

I dasz radę bez debuggera.

Pewnie, że dam radę bez debuggera.
Raczej pochylę się nad drugim rozwiązaniem, bo będzie bardziej kompaktowe. Pewnie najpierw skoczę na rower co by przewietrzyć mózgownicę i coś wtedy wymyślę:)

_________________
Gordon

Może to pomoże:
https://www.onlinegdb.com/online_c_compiler

Po chwili zabawy można debugować, przycisk Debug u góry okna, potem na dole pojawi się zielony przycisk start, na dole okienka.
Klikając w numer linii można ustawiać breakpointa.
Banalna sprawa.
Jeżeli debug nadal będzie przerażał to można "debugować" za pomocą funkcji printf(), jest konsola na podorędziu stronki.

No nie, wiem czy taka banalna.
Przeportowanie programów z mikroprocesorów na kod pod PC, może zająć więcej czasu niż rozwiązanie problemu.
Nie mam nic przeciw debuggerom, ale pod warunkiem, że się działa na docelowej platformie lub debuggerze sprzętowym (tylko kto taki posiada).
W przypadku programów na AVR'y moim zdaniem szkoda czasu na zabawy w debuggery online (chyba że w celach dydaktycznych).
Tam gdzie dioda LED nie daje rady, można sobie dopisać "linijkę" kodu i wyrzucić to co nas interesuje na wyświetlacz lub Uart, tak jak z funkcją printf().
Jak program przemiata za szybko można dopisać "pułapkę" na konkretny warunek i dać delay'e, aby program przymrozić.
W przypadku programów na AVR'ów można się obyć bez debuggera, natomiast czasami trzeba trochę więcej pokombinować.

Dzięki. Pewnie pomoże do jakichś fragmentów kodów. Trzeba to trochę ujarzmić bo już na wstępie trzeba się pobawić typami (error: unknown type name ‘uint8_t’)

_________________
Gordon

Zatem przeportować należy tylko kluczowe elementy kodu.
Spotykałem się z takimi opiniami u bardziej doświadczonych programistów i mogę potwierdzić, ze często łatwiej coś testować "na PC" niż na uK. Wszystkie wyższe warstwy niż te sprzętowe, co chyba jest oczywiste.
Zresztą podałem druga możliwość, konsola oraz funkcja printf(), to taki bardziej rozbudowany debugger niż dioda na porcie. Od wyboru do koloru. Należy próbować, testować, i nie załamywać rąk, jeśli w tym projekcie nie będzie spektakularnych efektów to pewnie w następnych


Ten nagłówek powinien pomóc.

Bożesz ty mój! Panowie litości z tymi debugerami naprawdę litości

to może tak - da się to poprawić, naprawić, albo przerobić tak żeby działało bez żadnego kociego debugera ? No aż nie wytrzymałem i walnąłem mini filmik

_________________
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 ]

Ja trochę kombinowałem jak przysłowiowy "koń pod górkę" (co by załatwić wszystko jedną linijką kodu), a Mirek jak zwykle rozwalił problem na łopatki
Pozostaje mi podziękować, przede wszystkim za cierpliwe podejście i skierowanie myślenia na odpowiednie tory.
Teraz mogę wyświetlić dowolną liczbę na dowolnym wyświetlaczu z wyrównaniem do prawej - super!

_________________
Gordon

Weneralnie w wątku było poruszonych kilka kwestii:
- użycie debugera
- możliwość uruchomienia tego na komputerze
- czyli ogólnie o możliwości przenoszenia napisanego kodu - uniezależnienie go od AVR (kolega auers słusznie zauważył, że to nie jest ogólnie takie proste)
- czyli idąc dalej, że takie rzeczy jak manipulacja textami tablicami itp można sobie przećwiczyć na komputerze

Filmik pokazuje, że da radę to zrobić bez debuggera - ktoś pisał, że nie można? Dokładnie takie samo flow poprawek byłoby w przypadku debugera, czy IDEALNIE to samo w przypadku uruchomienia tego na PC i wyprintowania - a tu nawet bym obstawiał, że przeklejenie tej funkcji do pustego main.c i skompilowanie przez "gcc main.c" byłoby o wiele szybsze niż zasetupowanie sobie tego w AVRze. W filmiku kwestie przenoszenia tego na inne platformy są całkiem pominięte i narracja mówi jakby padł stwierdzenie, że bez debugera NIC nie da się zrobić <facepalm>.

Nikt nie twierdził, że diodą się nie da itp i padło kilka innych propozycji w tym z printowaniem na terminal co dokładnie potem było pokazane w filmiku - zrobiło się trochę "uderz w stół" z ikonkami z przeklejonym debugerem, bo przecież on jest niepotrzebny.

Czy te podpowiedzi były błędne? Wydaje mi się, że nie. Chyba po to jest forum, żeby wymieniać różne opinie, czy nie?

Zaraz tam błędne ... no błędne nie - ale może sprowadzające na "złe tory" tak bym to pół żartem pół serio określił.


Oczywiście tylko nie ma co strzelać z armaty do komara to po pierwsze, a po drugie wytaczanie takich dział, że tak powiem w przypadku tak błahych problemów i dla początkujących to po prostu moim zdaniem .... niech będzie, że delikatny przerost formy nad treścią.

Bo jeszcze raz powtórzę - lepiej na początku nauczyć się działać bez debugera żeby lepiej zrozumieć logikę działania kodów i nauczyć się samemu szukać najprostszych metod debugowania, odpowiedniego dzielenia problemu na dwa i na dwa i na dwa ... porządnego izolowania problemu, programów testowych, czy wreszcie takich podstaw jak używanie UART'a jako podstawowego narzędzia do debugowania - bo to dopiero daje lepsze podstawy do dalszej nauki.....

To jest właśnie forum dla początkujących - rzadko tu specjaliści zadają pytania a jak już to dużo cięższe. Tymczasem polecanie do rozwiązywania takich problemów - debugera zaraz, odnosi skutek jakby jakiś cudowny debuger miał za nas załatwić kupę rzeczy.

Dlatego zrozum mnie - że ja ZAWSZE patrzę przez pryzmat dydaktyki - a to, że tobie jako specjaliście w tej dziedzinie łatwiej sięgnąć po debuger - to cóż ja mogę mieć do tego ? Tak czy inaczej KAŻDY na końcu zrobi tak jak uważa - a ja zawsze będę podkreślał że przy 8-bitowcach warto używać jak najprostszych narzędzi do tego celu i wyjdzie to tylko na dobre szczególnie osobie która uczy się tego wszystkiego dopiero. Tu po pierwszym pytaniu było od razu widać, że po prostu ZABRAKŁO - ZABRAKŁO obsługi znaku a zatem debuger już w ogóle hmmm moim zdaniem kompletnie niepotrzebny. Zaś na filmiku pokazałem - jak można sobie pomagać byle UART'em ... bo jak sobie pomagać diodą LED pokazałem już kiedyś w innym filmiku.

_________________
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 ]

ok - więc nie ma co demonizować debuggerów. Przecież właśnie pod względem dydaktyki itp gdy już się opanowało te podstawy z diodą i uartem debuger powinien być kolejnym krokiem. Więc nie zgodzę się z tymi obrazkami z przekreślonym debugerem itp - skoro jednak później ma to być tylko kolejne narzędzie w naszym warsztacie obok innych i sobie wybierzemy jakie będzie dla nas ok, ale jakoś trzeba go poznać - więc chyba też lepiej na jakiś małych poprawkach niż potem wskoczyć w wielki projekt/problem całkowie bez znajomości jego obsługi.

Wytłumaczę się jeszcze inaczej - miałem do czynienia z kilkoma osobami, które na tego typu etapie już pozostały i zwyczajnie "brakowało im warsztatu". Bardzo ciężko potem się przez to przebić przy współpracy z nimi. Oczywiście to zależy od osoby - nie generalizuje, ale właśnie tego typu wymówki słyszałem, że "tego nigdy nie uruchamiałem, bo mi zawsze dioda wystarczała". Albo przeniesienie 1:1 wiedzy z mikrokontrolerów na programowanie np w pythonie/c# i też debug printfem jako odpowiednik uartu zamiast innych metod, które wtedy są łatwo dostępne, ale nie ma się tej bazy. Trzeba czasem ten krok w tył zrobić i "naostrzyć piłę"
Co do idei się zgadzam, że trzeba wiedzieć w jakim miejscu się "zasadzić" na buga a czy to będzie breakpoint/watchpoint/dioda/uart schodzi wtedy na drugi plan - ale trzeba te narzędzia poznać. A samo skonfigurowanie debugera nawet na 8bit to też jest dobra nauka, coś co może się przydać i da jakieś podstawy na kolejne procki/platformy itp.

Nie generalizujesz ale generalizujesz i to mocno

Ja zostaję przy swoim - że nie ma co przesadzać z wykorzystywaniem debugerów do wszystkiego ale też nigdy nie mówiłem że to są jakieś szatańskie i niedobre narzędzia. Nawet nie ma co dyskutować - już tobie mówiłem znasz się na tym wszystkim to działasz na tym co chcesz i co wybierzesz i nic nikomu do tego przecież. Natomiast polecanie do byle problemu debugera będę uważał za nieporozumienie i można na to zrobić tylko Facepalm jak na filmiku po prostu.

Ja będę wciąż preferował mój styl dydaktyki i przy tym pozostanę - to tylko tyle albo aż tyle.

_________________
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 ]

Ale przecież przy programowaniu na PC debugger to kompletnie inna bajka - tam się z tego korzysta i to często

Panowie, nie ma się co kłócić o debugger.
Zarówno Mirek jak i Landrynek macie po części rację.
W 99% przypadków próba uruchomienia kodu z mikroprocesorów na debuggerze PC skończy się niepowodzeniem.
W przypadku początkujących zamiast rozwiązać problem dojdą nowe. Dlatego warto najpierw poznać inne metody,
w tym z wykorzystaniem diody LED, UART'u czy wyświetlacza LCD.
Kluczem do sukcesu nie są same narzędzia, a umiejętność "wyłapywania" potencjalnych problemów i to jak to napisał landrynek "jak się na nie zasadzić".
Dioda, Uart czy debugger to tylko narzędzia które to ułatwiają, natomiast same problemów nie rozwiązują.

Co do pierwszego pytania i zaprezentowanego kodu to, akurat po niewielkich przeróbkach dało się go uruchomić w debuggerze do którego link podał Zealota.
Kod pomógł przeportować Anshar. Tak, że myślę, że koledzy wykazali chęć pomocy i nie można ich za to krytykować.
Warto mieć głowę otwartą na różne pomysły i sugestie.

pod tym co napisał auers brakuje tylko "amen"

Ja nikogo nie krytykuję - za to ZDECYDOWANIE powiem tak.....

gdy początkująca osoba, która zadaje pytanie i w sumie ładnie prezentuje problem - tak jak gordon10 ... warto jednak pochylić się i podpowiedzieć hmmm udzielić wskazówki - jak próbować rozwiązać problem ... ale nie zaraz podpowiadając, że ...



to jest dla mnie po prostu NIEDORZECZNOŚĆ bez urazy dla kolegi "landyrynek" i nie piszę tego broń Boże żeby dogryźć koledze ! ...

Ja dostrzegam od razu, że osoba która zadaje tego typu pytanie - nie zdaje sobie sprawy z najprostszych metod "IZOLOWANIA PROBLEMU" ... z tzw testów jednostkowych....

dlatego podpowiedź żeby od razu rzucać się na debuger w wielu takich przypadkach powoduje, że początkujący nie potrafiąc samemu sobie radzić ze zwykłą "diodą DEBUG LED" .... od razu myśli .... 'aaaa - pewnie gdy użyję debugera, to on od razu podpowie mi co trzeba zrobić' .... i to jest mega pułapka....

I mówicie sobie co chcecie ale odpowiedź autora wątku świadczy tylko o jednym:


I nie chodzi o to że zrobił to Mirek czy landyrynek czy auers czy Zelaota czy Anshar czy ktokolwiek inny ... !!!

... chodzi o to aby pokazać drogę - jak sobie radzić w TAK MEGA PROSTYCH sytuacjach korzystając z MEGA PROSTYCH narzędzi - bo czy tego chcecie Panowie czy nie, to naprowadza człowieka dopiero na właściwe tory myślenia - jak analizować działanie kodu od PODSTAW. Gdy się przejdzie te kroki - to dopiero później jest o WIELE ŁATWIEJ korzystać z różnej maści debugerów i po 100-kroć lepiej rozumieć ich działanie.

Tymczasem Wy odsyłacie początkującego na kolejną MINĘ - zamiast próbować naprowadzić go na rozwiązanie błahego problemu - najprostszymi metodami, gdzie nie trzeba zaraz się uczyć zasad działania Debugera X czy Y czy Z ... to zupełny nonsens wg mnie i zdania nie zmienię.

Gdybym spotkał się tu z problemem godnym użycia debugera - to owszem - pewnie sam bym coś opisał polecił i rozumiał że wskazujecie właściwą drogę. Tymczasem początkujący nie zna jeszcze np podstaw - a Wy kierujecie go na debugera, gdzie będzie potrzebował kolejnych sporych ćwiczeń - żeby rozwiązać swój "DROBNY" podkreślam "DROBNY" problem .... który można rozwiązać bez Qurczę debugera - a to WCALE QURNA nie oznacza, że ja rzekomo twierdzę , że debugery są do niczego ! ... bo pisząc to próbujecie wmawiać mi coś czego nie powiedziałem....

to tyle

_________________
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 ]

Mirku,

Widzisz potwierdzam twoje zdanie.
Kolega Landrytek też się z tym zgodził.
Dlatego dobrze, że zrobiłeś taki poradnik, który pokazał krok po kroku jak sobie radzić bez debuggera.
Nikt tu nie kwestionuje twoich metod dydaktycznych.

Natomiast mimo, iż podpowiedź kolegi Landrynek może była trochę lakoniczna, to inni ją pociągnęli i w sumie autor postu dostał dodatkowe narzędzie które mogło mu pomóc w rozwiązaniu problemu. Po to jest forum.
Nie ma potrzeby o ten debugger toczyć dalszej wojny.

Absolutnie nie chcę toczyć żadnej wojny bo nie ma o co .... i dlatego też często proszę aby podejść troszkę na luzie do takiej dyskusji

_________________
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 ]

o jednak nie amen - tylko kolejna ściana tekstu. No nic - niech tak zostanie.