Niestety VirtualBox coś nie chce ruszyć na moim laptopie.
Wyświetla się menu GRUB-a, później
Kod: Zaznacz cały
loading linux 3.16....
loading initial ramdisk ...
Żadnych komunikatów kernela.
Nie mam doświadczenia z VB, nie wiem co jest nie tak.
ESP8266 i DS18B20
Urządzenie usunąłem z cloud.supla. Niestety "przy okazji" usunąłem starą lokalizację, więc konfiguracja na pewno już nie pasuje.
Niestety VirtualBox coś nie chce ruszyć na moim laptopie.
Wyświetla się menu GRUB-a, później
ekran pozostaje ciemny, kursor w lewym rogu i to wszystko.
Żadnych komunikatów kernela.
Nie mam doświadczenia z VB, nie wiem co jest nie tak.
Niestety VirtualBox coś nie chce ruszyć na moim laptopie.
Wyświetla się menu GRUB-a, później
Żadnych komunikatów kernela.
Nie mam doświadczenia z VB, nie wiem co jest nie tak.
Która wersja VirtualBox-a ?
Jaki procesor na hoście ?
Ta maszyna musi chodzić na 64-bitach.
Sprawdź czy po imporcie nie przełączyła się na 32 bity.
Jaki procesor na hoście ?
Ta maszyna musi chodzić na 64-bitach.
Sprawdź czy po imporcie nie przełączyła się na 32 bity.
Możliwe, że masz Virtualbox-a 32bitowego albo Twój procesor nie wspiera wirtualizacji 64 bitowej.
Znalazłem laptopa z lepszym CPU, ale musiałem zrobić downgrade VB - miałem ten błąd https://www.virtualbox.org/ticket/13697
System się uruchomił. Jutro spróbuję przekompilować firmware. Dzięki za pomoc.
System się uruchomił. Jutro spróbuję przekompilować firmware. Dzięki za pomoc.
Pobrałem najnowszy kod socketa z repozytorium.
Zmieniłem przycisk na #define BTN_PORT 2
Skonfigurowałem na nowo moduł. Moduł połączył się do cloud.supla.org
I tu pojawił się problem - stan socket-a (ON/OFF) samoistnie, cyklicznie zmienia się co kilka sek.
Zastanawiam się, czy nie wybór portu GPIO2 nie spowodował jakiegoś konfliktu z odczytem DS18B20 na tym samym porcie.
Myślałem, że to jakieś wejście pływa, ale manualnego switch-a ON/OFF na GPIO5 chyba nie ma w firmware, więc to chyba nie to.
Zmieniłem przycisk na #define BTN_PORT 2
Skonfigurowałem na nowo moduł. Moduł połączył się do cloud.supla.org
I tu pojawił się problem - stan socket-a (ON/OFF) samoistnie, cyklicznie zmienia się co kilka sek.
Zastanawiam się, czy nie wybór portu GPIO2 nie spowodował jakiegoś konfliktu z odczytem DS18B20 na tym samym porcie.
Myślałem, że to jakieś wejście pływa, ale manualnego switch-a ON/OFF na GPIO5 chyba nie ma w firmware, więc to chyba nie to.
Konflikt jest. W takim razie wprowadź na sztywno ustawienia, a przycisk odepnij z GPIO2
Skonfigurować na nowo udało mi się. Teraz wrzuciłem niemodyfikowane firmware z githuba i wszystko wróciło do normy.
Gniazdka widać w cloud.supla.
Pozostaje nadal problem, że temperatura z DS-a źle się wyświetla. Tu proszę o pomoc, bo nie wiem jak to zdebugować.
Gniazdka widać w cloud.supla.
Pozostaje nadal problem, że temperatura z DS-a źle się wyświetla. Tu proszę o pomoc, bo nie wiem jak to zdebugować.
W pliku https://github.com/SUPLA/supla-core/blo ... _ds18b20.c
funkcja supla_ds18b20_read_temperatureB
pod if ( data != 255 ) d = 1; dopisz:
supla_log(LOG_DEBUG, "data[%i]=%i", i, data);
aby wyszło tak:
for(i=0;i<8;i++) {
data = supla_ds18b20_read();
if ( data != 255 ) d = 1;
supla_log(LOG_DEBUG, "data[%i]=%i", i, data);
}
skompiluj (bez wskazywania BTN_PORT na gpio2) wrzuć do układu i sprawdź co wyrzuca na porcie szeregowym.
Możesz połączyć się przez putty.
Nie zaglądałem do dokumentacji czujnika ale może w Twoim przypadku jest tam inna precyzja.
Daj znać co wyszło i jaka powinna być orientacyjna temperatura.
funkcja supla_ds18b20_read_temperatureB
pod if ( data != 255 ) d = 1; dopisz:
supla_log(LOG_DEBUG, "data[%i]=%i", i, data);
aby wyszło tak:
for(i=0;i<8;i++) {
data = supla_ds18b20_read();
if ( data != 255 ) d = 1;
supla_log(LOG_DEBUG, "data[%i]=%i", i, data);
}
skompiluj (bez wskazywania BTN_PORT na gpio2) wrzuć do układu i sprawdź co wyrzuca na porcie szeregowym.
Możesz połączyć się przez putty.
Nie zaglądałem do dokumentacji czujnika ale może w Twoim przypadku jest tam inna precyzja.
Daj znać co wyszło i jaka powinna być orientacyjna temperatura.