Godagens!
Efter att ha pillat ett tag med STM32an så har jag börjat sätt att man kan koppla in TFT displayer till den via något som kallas FSMC (länk).
Men jag förstår inte hur det kan köras en display på så lite RAM.
Skulle någon kunna upplysa mig om hur detta fungerar?
Jag har läst igenom datablad efter datablad om det men blir inge smartare.
Det som jag hittar är:
"The STM32F10xxx flexible static memory controller (FSMC) is an embedded external memory controller that allows the STM32F10xxx microcontroller to interface with a wide range of memories, including SRAM, NOR Flash, NAND Flash and LCD modules.
The FSMC NOR Flash/SRAM bank is suitable for MCU parallel color LCD interfaces."
Men det är allt.
Så detta kan dock betyda att man kopplar in mer RAM till µCn för att orka driva LCDn men som sagt så förstår jag inte riktigt hur det fungerar.
//Emil
TFT LCD på STM32an
Hej Emil,
Vet inte exakt vilken display du menar primern eller stora kortet eval kortet?
STM32 har ingen inbyggd LCD controller vilket innebär att om större tft skärmar ska fungera bör dessa köras med en extern kontroller och isåfall så är den oftast utrustad med tillräckligt med ram.
Sen är fördelen med att köra de via det externa minnes interfacet(endast tillgänglig på 256+k flash) att du kan addressera ett externt minne precis om om det vore inbyggt. Alltså kan frame bufferten i skärmen se ut precis som en intern framebuf(fast långsammare).
På primern vet jag inte riktigt hur den är kopplad men på det stora kortet är det en chip-on-glass skärm med SPI eller paralell interface.
På 512k varianten är den paralellt kopplad via EMI och då har jag sett demon då de spelat upp film i QVGA fast då från okomprimerad källa.
Vet inte exakt vilken display du menar primern eller stora kortet eval kortet?
STM32 har ingen inbyggd LCD controller vilket innebär att om större tft skärmar ska fungera bör dessa köras med en extern kontroller och isåfall så är den oftast utrustad med tillräckligt med ram.
Sen är fördelen med att köra de via det externa minnes interfacet(endast tillgänglig på 256+k flash) att du kan addressera ett externt minne precis om om det vore inbyggt. Alltså kan frame bufferten i skärmen se ut precis som en intern framebuf(fast långsammare).
På primern vet jag inte riktigt hur den är kopplad men på det stora kortet är det en chip-on-glass skärm med SPI eller paralell interface.
På 512k varianten är den paralellt kopplad via EMI och då har jag sett demon då de spelat upp film i QVGA fast då från okomprimerad källa.
Tackar för svaret Matte!
Jo jag såg det på EVAL kortet, där jag vart intresserad att testa jag med, och efter lite googling så såg jag personer som hade gjort det själva, men alla displayer var relativt små (under 480 pixlar).
Men nu så förstår jag, tackar för det!
Man kopplar alltså in mer RAM för att köra framebuffern i.
Då blir det dax att göra kretskort för 512k modellen + externt RAM + liten TFT (kanske en touch screen) och börja leka.
Ska nog göra denna så jag kan sätta den i kopplingsbläck också.
Som en följdfråga, visst behövs det bara så mycket RAM så man får platts med frambuffern i det?
Dvs en 320x240xRGB á 16bit = 150kB framebuffer. (Valfri TFT på 320x240 pixlar)
Eller en 480x272xRGB á 24bit = 382.5kB framebuffer. (PSPs display)
//Emil
Jo jag såg det på EVAL kortet, där jag vart intresserad att testa jag med, och efter lite googling så såg jag personer som hade gjort det själva, men alla displayer var relativt små (under 480 pixlar).
Men nu så förstår jag, tackar för det!
Man kopplar alltså in mer RAM för att köra framebuffern i.
Då blir det dax att göra kretskort för 512k modellen + externt RAM + liten TFT (kanske en touch screen) och börja leka.
Ska nog göra denna så jag kan sätta den i kopplingsbläck också.
Som en följdfråga, visst behövs det bara så mycket RAM så man får platts med frambuffern i det?
Dvs en 320x240xRGB á 16bit = 150kB framebuffer. (Valfri TFT på 320x240 pixlar)
Eller en 480x272xRGB á 24bit = 382.5kB framebuffer. (PSPs display)
//Emil
Den skärmen är riktigt fin.
har kollat lite och den är relativt avancerad med kommandon osv. finns även ett rätt bra lib för kommunikation där all initiering, fonter och funktioner för att visa bilder mm. (samma som andvänds i demon).
Har ett sånt kit som ligger hemma som jag tänkte skulle få bli en provisorisk bränsle flödes mätare till båten.
Bara lite overkill!?
har kollat lite och den är relativt avancerad med kommandon osv. finns även ett rätt bra lib för kommunikation där all initiering, fonter och funktioner för att visa bilder mm. (samma som andvänds i demon).
Har ett sånt kit som ligger hemma som jag tänkte skulle få bli en provisorisk bränsle flödes mätare till båten.
Bara lite overkill!?
Mm, har setat och gått igenom demo koden för att få ett gräpp om vad man behöver göra själv och det ser mychet trevligt ut.
Behöver inte kåda så mycket själv då.
Hehe, trevlig flödesmätare!
Kanske liite overkill.
Jag måste väll ha en frambuffer om jag inte har RAM i displayen?
För jag behöver ha en frame i RAMet så jag kan ändra på och läsa till displayen så µCn inte behöver göra om framen efter varje frame.
Eller missuppfattar jag dig?
//Emil
Behöver inte kåda så mycket själv då.
Hehe, trevlig flödesmätare!
Kanske liite overkill.
Jag måste väll ha en frambuffer om jag inte har RAM i displayen?
För jag behöver ha en frame i RAMet så jag kan ändra på och läsa till displayen så µCn inte behöver göra om framen efter varje frame.
Eller missuppfattar jag dig?
//Emil
ja alltså om du har en tft kontroller vilket du bör ha så måste den nog ha inbyggt eller interface till extent RAM. TFT elementet kräver konstant uppdatering så för att få bild måste du konstant uppdaterade i 50-100hz om jag inte mins fel så den en du måste alltå mata den med typ 24Mbit per färg konstant vilket blir tufft för en STM32. det är vad tft kontrollen gör. jag skulle nog i första hand hålla mig till chip on glas.
det jag menar är att istället för att göra ändringarna i en buffert för att sedan uppdatera hela skärmen. så gör du din skrivning direkt till skärmen.
optimalt skulle nog vara att göra en command buffer istället, allså istället för att sätta färgen på pixeln i framebuf så skriver du kommandot för att sätta den i skärmen. då du sen vill visa den nya bilden skickar du bara hela din kommando listan.(förslagsvis med hjälp av en DMA kanal).
det jag menar är att istället för att göra ändringarna i en buffert för att sedan uppdatera hela skärmen. så gör du din skrivning direkt till skärmen.
optimalt skulle nog vara att göra en command buffer istället, allså istället för att sätta färgen på pixeln i framebuf så skriver du kommandot för att sätta den i skärmen. då du sen vill visa den nya bilden skickar du bara hela din kommando listan.(förslagsvis med hjälp av en DMA kanal).
Okej, nu är vi på samma sida.
Då tänkte vi lika iaf.
Jo, en LCD med ett controller är det bästa så stackars STM32an inte behöver jobba som en tok.
Och man brukar uppdatera en TFT med ca 60Hz. Så det blir ganska så mycket med data som ska överföras.
Nu när vi endå pratar om detta, vilken kontroller brukar du använda?
Eller kör du bara med LCDer som har inbyggd controller?
//Emil
Då tänkte vi lika iaf.
Jo, en LCD med ett controller är det bästa så stackars STM32an inte behöver jobba som en tok.
Och man brukar uppdatera en TFT med ca 60Hz. Så det blir ganska så mycket med data som ska överföras.
Nu när vi endå pratar om detta, vilken kontroller brukar du använda?
Eller kör du bara med LCDer som har inbyggd controller?
//Emil
Emil, Normalt sett brukar man välja en kraftigare MPU med inbyggd controller, sen beror det nog lite på vilken nivå man vill till. PSP displayen tex så tror jag att en STM32 är lite för klen. då kör man nog på 200Mips+ MPUer. jag kör egentligen bara chip on glas men funderade ett tag på att göra en egen kontroller i en FPGA men det blev inte så sen.
micke_S att paralellt mata ut 8 eller 4 bitar spelar ingen större roll ur en STM32 och har man ett paralellt interface så är det fullt möjligt att bygga en mjukvarustyrd kontroller. dock blir det kanske inte så jätte mycket kraft kvar till annat och sen krävs externt ram(och inte ens för 12bitars färg räcker ramet).
micke_S att paralellt mata ut 8 eller 4 bitar spelar ingen större roll ur en STM32 och har man ett paralellt interface så är det fullt möjligt att bygga en mjukvarustyrd kontroller. dock blir det kanske inte så jätte mycket kraft kvar till annat och sen krävs externt ram(och inte ens för 12bitars färg räcker ramet).
En liten fråga bara Matte, viket program kör du när du skriver koden för STM32an?
Ride7? WinARM?
Samt en gennerell fråga, skickade tillbaka min programmerare till skolan så jag har bara min JTAG ICE mkII.
Men på den är det en 10 pins header och på STM32 kortet är det en 20 pins header.
Jag lyckas inte hitta pinouten för 20 pins headern så jag vet inte om min JTAG ICE mkII fungerar.
Skulle någon kunna ge lite hjälp här?
//Emil
Ride7? WinARM?
Samt en gennerell fråga, skickade tillbaka min programmerare till skolan så jag har bara min JTAG ICE mkII.
Men på den är det en 10 pins header och på STM32 kortet är det en 20 pins header.
Jag lyckas inte hitta pinouten för 20 pins headern så jag vet inte om min JTAG ICE mkII fungerar.
Skulle någon kunna ge lite hjälp här?
//Emil
Emil, jag är så lyckligt lottad att jag har tillgång till både IAR och KEIL miljöerna så jag brukar köra Keils.
Vad det gäller debug har jag inte sett någon jtag med 10pinnars tidigare men pinouten för den som ST kallar standard finns i "hardware getting Started"
http://www.st.com/stonline/products/lit ... /13675.pdf
vilket för övrigt är ett bra dokument att läsa om du ska bygga eget.
Kolla även in manualen till det stora evalkortet. Här ska det finnas väl beskrivet alla portar och schema för hela baletten finns i slutet.
http://www.st.com/stonline/products/lit ... /13472.pdf
Hoppas det hjälper!
Vad det gäller debug har jag inte sett någon jtag med 10pinnars tidigare men pinouten för den som ST kallar standard finns i "hardware getting Started"
http://www.st.com/stonline/products/lit ... /13675.pdf
vilket för övrigt är ett bra dokument att läsa om du ska bygga eget.
Kolla även in manualen till det stora evalkortet. Här ska det finnas väl beskrivet alla portar och schema för hela baletten finns i slutet.
http://www.st.com/stonline/products/lit ... /13472.pdf
Hoppas det hjälper!
