kaworu

Przy 12V? I No wychodzi 0,2A. No ale powiedzmy, ze to jest 6 Ohm, wtedy tak, redukujesz wypełnienie póki prąd nie osiągnie 1A (i napięcie 6V).

Jeśli masz tylko jeden obwód mocy, i jest sterowany PWMem, to tak, tylko wypełnieniem i tylko tym tranzystorem. Nawet ograniczenie termiczne po prostu zmusi układ sterowania do redukcji wypełnienia.

Nooo, niezupełnie. Powiedzmy, że możesz się poruszać w granicach w jakich potrzebujesz. Bo to jakie parametry możesz uzyskać zależny od obciążenia. Możesz regulować wypełnieniem tak aby uzyskać zadany prąd albo napięcie. Bo popatrz, nie da się uzyskać prądu 1A i 30V jak nic do zasilacza nie podłączysz, no nie? Zasilacz będzie podbijał wypełnienie dopóki nie dobije do zadanego napięcia albo prądu, jeśli któreś zostanie osiągnięte to na tym zostanie.

Po prostu obniżasz wypełnienie tak, żeby prąd się zgadzał z zadanym, i tyle

Przecież nazwa pliku w C/C++ nie ma absolutnie żadnego znaczenia.

Niby tak, ale taka sytuacja raczej nie nastąpi. Źle na to patrzysz tak w ogóle (co usiłuję przetłumaczyć). MPPT interesuje utrzymanie takiej mocy aby napięcie na wejściu w Twoim przykładzie było min 22V, jakby mógł to by regulował tylko prąd wejścia tak aby utrzymać min 22V. Niestety musi jeszcze brać pod uwagę prąd wyjscia i napięcie wyjścia, bo jak przekroczy zadane ograniczenia to coś wybuchnie. Ale co do zasady algorytm MPPT chce dobrać wypełnienie tak aby prąd na panelu był taki aby jego napięcie było w okolicy 22V.

Nooo, jak masz 13,5 na aku, i granice na 14V na ładowarce, to jest jeszcze 0,5V miejsca na całkiem duży prąd. No ale, póki ładowarka może pobić napięcie powyżej napięcia akumulatora - może go ładować, chociażby mocą 10mW.

No, jak masz pełny akumulator to nie będzie ładować.

W wypełnienie to jedyny parametr jaki możesz ustawić, więc siłą rzeczy jak dobierzesz właściwe to będzie właściwe Popatrz na to z punktu widzenia mocy przez pryzmat prawa ohma. Jak spada Ci dostępna moc, a chcesz utrzymać napięcie - musi spaść pobierany prąd - nie ma innej opcji. Oraz to jednak są ładowarki, więc nie muszą utrzymywać jakiegokolwiek napięcia, jedynie nie przekroczyć zadanego. Zatem jak brakuje mocy z panelu to ładowarka ograniczy prąd ładowania - i co za tym idzie napięcie spadnie - ale dalej będzie ładować akumulator z maksymalną dostępną mocą.

Bo nie jest. Jak masz dostępne 100W z paneli i limity ładowania na 10W, to kontroler nie bardzo interesuje napięcie po stronie paneli. Może sobie pobrać całą dostępną moc jakiej potrzebuje - 10W. Jak masz z paneli 8W, a potrzebujesz 10W to no nie ma bata aby utrzymać potrzebną moc/napięcie/prąd na wyjściu i wtedy MPPT ma znaczenie. Bo ładowarka MPPT będzie ładowała z maksymalną dostępna mocą (starając się utrzymać punkt maksymalnej pracy na panelu) a nie jak "zwykła" wyssać to co się da z panelu efektywnie redukując dostępną moc.

Mało widziałeś. *Szczególnie* jeśli używasz DMA, CubeMX uwielbia generować złą sekwencję inicjalizacji w wypadku niektórych urządzeń przez co no, nie działa. Żeby było zabawniej błąd znany od paru lat i prosty do poprawienia, a patrząc po internetach, to 5 miesięcy temu dalej tam był (i pewnie dalej jest znając ST). Albo jak kod HAL używa alokacji pamięci w przerwaniach w co najmniej kodzie drivera USB.

#define LOOP_VARS() #define LOOP_WAIT(v,n,d) while(v) int8_t spiWrite(const struct spiDevInfo *pParams, uint8_t *out, uint16_t len) { LOOP_VARS(); ATOMIC_BLOCK(ATOMIC_RESTORESTATE) { SPI_TypeDef *pSPI = getSpiBus(pParams->bus); if (!(pSPI->CR1 & SPI_CR1_SPE)) { return KSPI_ERROR; } spiSetParams(pParams, len); pSPI->IFCR = SPI_IFCR_SUSPC | SPI_IFCR_TXTFC; pSPI->CR1 |= SPI_CR1_CSTART; for (int i = 0; i < len; ++i) { LOOP_WAIT( !(pSPI->SR & SPI_SR_TXP) , "spiWrite", SPI_STATE("spiWrite(TxP)")); *((volatile uint8_t *)(&pSPI->TXDR)) = out[i]; LOOP_WAIT( !(pSPI->SR & SPI_SR_RXP) , "spiWrite", SPI_STATE("spiWrite(RxP-W)")); (volatile void)*((volatile uint8_t *)(&pSPI->RXDR)); } while( !(pSPI->SR & SPI_SR_EOT) ); } return KSPI_OK; } Taka procedura wysyłki z pewnością działa na H750, testowane.

No właśnie o tym napisałem (wykonalne, ale się tak nie robi). A, że JL nie używam, to tez odpowiedziałem tylko na ogólną część posta. Tak czy inaczej SWD daje programatorowi dostęp do wszystkiego, więc fizycznie przez samo SWD da sie dobrać do czegokolwiek co jest w przestrzeni adresowej MCU + rdzeń. Także ładujesz program pod adres pamięci RAM, ustawisz PC i uruchamiasz. Pierwszy wynik z google na to jak to zrobić JLinkiem https://forum.segger.com/index.php/Thread/1992-Jlink-to-download-a-bin-file-to-memory-and-execute-it/ aczkolwiek post z 2014, mogło się coś zmienić. No i o części FPGA niech się jakiś spec wypowie co miał z tym układem do czynienia.

Nie mogę powiedzieć jak to dokładnie wygląda z j-linkiem, ale mogę powiedzieć jak w ogole wygląda wgrywanie programu do pamięci. I generalnie jest tak, że żaden programator nie programuje pamięci bezpośrednio, bo to jest horrendalnie wolna operacja. *Chyba* wszystkie programatory działają tak, że wgrywają mały program do pamięci SRAM, odpalają go i za jego pośrednictwem ładują dane do flasha. W przypadku st-linka w folderze z interfejsem programatora jest folder "FlashLoader", który zawiera programy ładujące dla różnych id rdzeni. A jako, że do programowania i tak używa się loadera pracującego na docelowym MCU nic nie stoi na przeszkodzie aby mieć taki loader, który zaprogramuje cokolwiek co jest podłączone do procesora. Co z resztą w stlinku jest używane do programowania pamięci SPI flash obecnych na płytkach developerskich.

BOOT0 jest nieaktywny, chyba, że go sobie włączysz w option bytes.