STM32 har allt - Utom trådlöshet

[DanielM]

Nej, du ska lagra alla filer permanent i flash och mellanlagra dem i RAM när de ska skickas till klienter.

Jo, det förstår jag. Jag bara inte vet hur.
Det är så att det finns en fil som heter fsdata_custom.c. I denna C-fil så finns hela hemsidan. Rakt av direkt. Troligtvis så läses denna in vid början på uppstarten.
Däremot måste man ta Exlude From Build på detta C-fil. Jag vet dock inte varför.

Wait, what? Din hemsida bor på din webserver. Ska du köra UDP till dig själv? Eller ska webbservern hämta data från någon annan server för att sedan kunna skicka den vidare till klienter?

Webservern ska skicka data till hemsidan, och hemsidan skall skicka data till webbservern.

Och du är medveten om att ifall du ska skicka data över UDP så behöver du implementera egen felhantering för att upptäcka och hantera fel som kan uppstå under överföringen. Har du en tjänst någonstans som enbart pratar UDP eller varför tror du UDP är något du vill blanda in här?

Jag väljer TCP istället.

NodeJS är en javascriptmotor som du använder för att köra JavaScript som en applikation, typiskt sett någon form av webbserver, på en dator.
AngularJS, VueJS, React och allt vad de nu heter är olika ramverk för att bygga interaktiva webbsidor. Dessa ramverk kan vara rätt komplicerade att använda om du frågar mig, men de är väl ett nödvändigt ont om man ska bygga en modern hemsida.

Du kan ladda in VueJS från CDN, alltså du länkar till en VueJS-fil som finns på VueJS's egna server. På så sett behöver man bara skicka hemsidan till webbläsaren.

Om man ska ladda olika JS-ramverk, så bör man undersöka ifall de går att hämta från något CDN istället för att själv servera det från sin egen server. Det är oftast det enkla sättet att lösa det hela på om man har tillgång till internet.

VueJS och AngularJS har detta. Även Socket.IO har detta. Så jag tror jag väljer VueJS då jag har hört att den ska vara det enklaste JS-biblioteket.

[TomasL]

Webservern ska skicka data till hemsidan, och hemsidan skall skicka data till webbservern.

Har du inte blandat ihop saker nu, en hemsida ligger alltid på en Webserver.
En Webserver kan aldrig initiera en anslutning, det är bara Klienten som kan initiera en anslutning och begära data från Webservern.
En hemsida är alltid skriven i HTML, eftersom det är det enda som Klienten (Webläsaren) förstår, i HTML koden kan man infoga script som körs på klientsidan och/eller serversidan.
Exempel på script som körs på klientsidan är Javascript, exempel på skript som körs på serversidan är PHP

[DanielM]

Jo, det vet jag. Men när webbläsaren anropar webbservern så skickar webbservern data till webbläsaren och denna typ av data är ju det man ser på webbläsaren.
Vi behöver inte gå in på dessa detaljer.

Det jag tycker vi borde gå in på är följande:

• JavaScriptramverk som läses in via CDN.
• Socket.IO som läses in via CDN.
• Hur man kan utföra lite TCP/IP socket mellan webbserver och hemsida.
• Hur man kan mellanlagra mellan ROM och RAM.

Det där med JavaScriptramverk verkar vara inte det största problemet. Jag har kollat runt lite. VueJS verkar fint och smidigt samt väldigt populärt. Det är en teknologi som jag kan investera i.

CDN är busenkelt, bara hitta HTTP adressen till valda filen

Socket.IO TCP blir i framtiden.

Det jag finner mest intressant just nu är att mellanlagra mellan ROM och RAM.
https://github.com/ARMmbed/lwip/blob/ma ... d/fsdata.c

För att detta ska fungera för mig, så måste jag ändra detta.

Kod: Markera allt

static const unsigned int dummy_align__img_sics_gif = 0;
static const unsigned char data__img_sics_gif[] = {
/* /img/sics.gif (14 chars) */
0x2f,0x69,0x6d,0x67,0x2f,0x73,0x69,0x63,0x73,0x2e,0x67,0x69,0x66,0x00,0x00,0x00,

Till

Kod: Markera allt

static unsigned int dummy_align__img_sics_gif = 0;
static  unsigned char data__img_sics_gif[] = {
/* /img/sics.gif (14 chars) */
0x2f,0x69,0x6d,0x67,0x2f,0x73,0x69,0x63,0x73,0x2e,0x67,0x69,0x66,0x00,0x00,0x00,

Alltså jag tar bort const. Då ligger datat på RAM, istället för ROM. Det är detta som ST säger att buggen är.

Jag har svårt att se hur man ska kunna mellanlagra här. Detta är säkert något som TomasL kan
Jag menar, om du har två arrayer.

Kod: Markera allt

static  const unsigned char  ROM_array[10];

static  unsigned char*  RAM_array; 

Om du ska föra över minnet från ROM_array till RAM_array så kan man bara göra.

Kod: Markera allt

memcpy(RAM_array, ROM_array, sizeof(ROM_array));

Eller tänker jag fel nu?
Jag tror det är enklare att jag bara fortsätter och kodar, och låter ST lösa detta problem vecka 23 som de lovar då dom har identifierat felet.
Jag menar, jag har ändå tillräckligt med RAM för att göra det jag vill göra.

[Mr Andersson]

JavaScriptramverk som läses in via CDN.

Det är väl det vanligaste sättet att använda js-bibliotek. Jag förstår inte riktigt vad som behöver diskuteras om den punkten.

Socket.IO som läses in via CDN.

Då måste du ha en websocket-server på kortet.
socket.io har HTTP-fallback, men då tappar man ju hela syftet och kan lika gärna använda fetch() eller HttpWebRequest.

Hur man kan utföra lite TCP/IP socket mellan webbserver och hemsida.

Jag antar att när du skriver hemsida menar du egentligen webbläsare.. Det korta svaret är att det går inte.
chrome.sockets som du nämnde tidigare är
1) Bara tillgängligt för extensions. Du kan inte använda det från en webbsida.
2) Deprecated och snart borttaget.

Det finns så vitt jag vet ingen mainstream-webbläsare som tillåter råa sockets från webbsidor pga säkerhetsskäl. Chromium (inte chrome) har ett experimentalt API för raw sockets men det verkar inte finnas mycket intresse från de stora webbläsarna att implementera det. Mozilla dömde direkt ut det som ett säkerhetshål.

Hur man kan mellanlagra mellan ROM och RAM.
[...]
Jag tror det är enklare att jag bara fortsätter och kodar, och låter ST lösa detta problem vecka 23 som de lovar då dom har identifierat felet.

Ditt problem, som du verkar ha missuppfattat, är att MAC-DMA-motorn inte har tillgång till flash.
Du skriver
"Deras kod har gjort så Ethernet MAC kan ej komma åt ROM"
ST själva svarar dig
"It is due to Hardware limitation, in fact the Ethernet MAC does not have access to the Flash (in STM32F407 device)"
Databladet för F405/F407 matchar STs svar för det nämner bara ram och inte flash.
"2.2.28 Ethernet MAC interface with dedicated DMA and IEEE 1588 support
Dedicated DMA controller allowing high-speed transfers between the dedicated SRAM and the descriptors"

Det är ingenting som de kan fixa med ny kod. Vad de mest troligt menar är att de kommer fixa exempelkoden, gissningsvis bara genom att flytta datan till SRAM.

Som en workaround kan du t.ex. göra
Generell DMA flash till SRAM
Vänta på completion-interrupt
MAC-DMA SRAM till MAC
(om det är filer som är större än vad som ryms i minnet i en överföring)
- Vänta på tx-buffer-nästan-tom-interrupt
- Repetera tills all data överförts

[TomasL]

Och varför skulle MAC överhuvudtaget ha tillgång till FLASH, finns ju överhuvudtaget ingen anledning.
Data som skickas till MAC måste naturligtvis alltid ligga i RAM, eftersom datat skapas av TCP/IP-stacken.

[Mr Andersson]

För att undvika onödigt kopierande fram och tillbaka. Mer kompetenta MAC:ar har scatter gather DMA som har tillgång till hela adressrymden.
Då kan man t.ex. skapa en TCP-header i RAM som säger att paketet har 30 bytes payload, sen gör man en enda DMA-transfer där man säger åt den att plocka headern från RAM, 25 bytes från flash, och 5 bytes från GPIO-input.
Givetvis går det att kopiera allt till ett sammanhängande RAM-block först, men det tar mera plats och mera tid.

[TomasL]

Ok. det förklarar saken.

[ToPNoTCH]

Det är ingenting som de kan fixa med ny kod. Vad de mest troligt menar är att de kommer fixa exempelkoden, gissningsvis bara genom att flytta datan till SRAM.

Vilket innebär att DanielM's kod inte kommer funka i vilket fall.
(Om dom nu inte pillar om drastiskt i HAL på något magiskt vis)

Det är ju ingen bug per definition, utan folk som inte förstår begränsningar i hårdvaran.

[Mr Andersson]

Precis. Buggen som ST verifierat åt DanielM är de två exempelprojekten som inte fungerar.
Jag gissar att den som skapat dem använde någon annan MCU med samma HAL men utan samma hw-begränsning och sen missat att testa koden på alla stm32-varianter.

[DanielM]

Webservern ska skicka data till hemsidan, och hemsidan skall skicka data till webbservern.

Har du inte blandat ihop saker nu, en hemsida ligger alltid på en Webserver.
En Webserver kan aldrig initiera en anslutning, det är bara Klienten som kan initiera en anslutning och begära data från Webservern.
En hemsida är alltid skriven i HTML, eftersom det är det enda som Klienten (Webläsaren) förstår, i HTML koden kan man infoga script som körs på klientsidan och/eller serversidan.
Exempel på script som körs på klientsidan är Javascript, exempel på skript som körs på serversidan är PHP

Ja. Det är exakt så jag försöker förklara. Jag är enig.

Det är väl det vanligaste sättet att använda js-bibliotek. Jag förstår inte riktigt vad som behöver diskuteras om den punkten.

Inte det vanligaste. Vanligaste är att man installerar ramverket på webbservern.

Då måste du ha en websocket-server på kortet.
socket.io har HTTP-fallback, men då tappar man ju hela syftet och kan lika gärna använda fetch() eller HttpWebRequest.

Jag har varken använt mig av Socket.IO eller JavaScript. Vanliga Socker har jag använt mig av. Då socket och websocket är inte samma sak? Detta trodde jag.
Annars får jag använda AJAX. Alltså inte tvättmedlet.

Jag antar att när du skriver hemsida menar du egentligen webbläsare.. Det korta svaret är att det går inte.
chrome.sockets som du nämnde tidigare är
1) Bara tillgängligt för extensions. Du kan inte använda det från en webbsida.
2) Deprecated och snart borttaget.

Det var synd...

Det finns så vitt jag vet ingen mainstream-webbläsare som tillåter råa sockets från webbsidor pga säkerhetsskäl. Chromium (inte chrome) har ett experimentalt API för raw sockets men det verkar inte finnas mycket intresse från de stora webbläsarna att implementera det. Mozilla dömde direkt ut det som ett säkerhetshål.

Då är det bara AJAX som är räddningen?

Ditt problem, som du verkar ha missuppfattat, är att MAC-DMA-motorn inte har tillgång till flash.
Du skriver
"Deras kod har gjort så Ethernet MAC kan ej komma åt ROM"
ST själva svarar dig
"It is due to Hardware limitation, in fact the Ethernet MAC does not have access to the Flash (in STM32F407 device)"
Databladet för F405/F407 matchar STs svar för det nämner bara ram och inte flash.
"2.2.28 Ethernet MAC interface with dedicated DMA and IEEE 1588 support
Dedicated DMA controller allowing high-speed transfers between the dedicated SRAM and the descriptors"

Det är ingenting som de kan fixa med ny kod. Vad de mest troligt menar är att de kommer fixa exempelkoden, gissningsvis bara genom att flytta datan till SRAM.

Som en workaround kan du t.ex. göra
Generell DMA flash till SRAM
Vänta på completion-interrupt
MAC-DMA SRAM till MAC
(om det är filer som är större än vad som ryms i minnet i en överföring)
- Vänta på tx-buffer-nästan-tom-interrupt
- Repetera tills all data överförts

Problemet är att det måste fungera med LwIP också. Jag har inget problem att kopiera minne från ROM till RAM. Problemet är när ska jag göra det och vart.

Jag har kollat lite i en fil som heter fs.c och i den filen så läser den in structer beroende på vilken hemsida det är som blir anropad. Om man kunde avgöra vilken hemsida som blir anropad så kan man väll använda malloc för att tillfälligt allokera data till en array som är icke const, från en array som är konst. När datat är skickat till webbläsaren, så frigör man minnet på RAM.

[Mr Andersson]

Då socket och websocket är inte samma sak? Detta trodde jag.

En socket är ju egentligen bara en datastruktur som OS:et använder för att spara nödvändig state för en IP-anslutning. Websockets är ett helt eget protokoll byggt ovanpå TCP. Följer du inte protokollspecifikationen kommer webbläsaren stänga ner anslutningen direkt.

Problemet är att det måste fungera med LwIP också. Jag har inget problem att kopiera minne från ROM till RAM. Problemet är när ska jag göra det och vart.

Jag har kollat lite i en fil som heter fs.c och i den filen så läser den in structer beroende på vilken hemsida det är som blir anropad. Om man kunde avgöra vilken hemsida som blir anropad så kan man väll använda malloc för att tillfälligt allokera data till en array som är icke const, från en array som är konst. När datat är skickat till webbläsaren, så frigör man minnet på RAM.

Allt lwIP vill ha är en minnesadress och datalängd. Du har din applikationskod (http-servern) som skickar datat till lwIP. lwIP slår in det i ett TCP-paket och skickar vidare till HAL:en som i sin tur skickar det till MAC:en.
Med reservation för att jag inte vet vilken httpserver du använder så gissar jag att enklast är att modifiera serverfunktionen som anropar lwIPs send-funktion. Om adressen ligger i flash-området så kopiera till ram först.

Du skulle kunna använda dynamisk allokering men då har du två fallgropar. Minnesfragmentering samt att vara säker på att alla kodvägar inklusive felhantering anropar free. Med en default-MTU på 1500 bytes är det inte så platskrävande att bara reservera en statisk data-buffer.

[DanielM]

>> En socket är ju egentligen bara en datastruktur som OS:et använder för att spara nödvändig state för en IP-anslutning. Websockets är ett helt eget protokoll byggt ovanpå TCP. Följer du inte protokollspecifikationen kommer webbläsaren stänga ner anslutningen direkt.

Ja, troligtvis så är det så. Jag är bara van att en socket är en socket, men om websocket skiljer sig från socket, så kan jag inte använda websocket. Det måste finnas någon annan lösning. Troligtvis AJAX, för det har jag sett på YouTube att det fungerar. Verkar vara en standardlösning.


>> Allt lwIP vill ha är en minnesadress och datalängd. Du har din applikationskod (http-servern) som skickar datat till lwIP. lwIP slår in det i ett TCP-paket och skickar vidare till HAL:en som i sin tur skickar det till MAC:en.
Med reservation för att jag inte vet vilken httpserver du använder så gissar jag att enklast är att modifiera serverfunktionen som anropar lwIPs send-funktion. Om adressen ligger i flash-området så kopiera till ram först.

>> Du skulle kunna använda dynamisk allokering men då har du två fallgropar. Minnesfragmentering samt att vara säker på att alla kodvägar inklusive felhantering anropar free. Med en default-MTU på 1500 bytes är det inte så platskrävande att bara reservera en statisk data-buffer.

Jag lägger mig inte i hur detta fungerar. Det för för komplicerat för mig. Till om med TomasL har varken sagt lösningen eller liknande, så därmed så låter jag ST sköta detta jobb.
Orsaken har med att jag förstår inte hur LwIP's projekt är uppbyggt.

LwIP's projekt är säkert väldigt intelligent uppbyggt, men som vanligt slutar alla projekt med #ifndef och #endif lite här och där och det finns ingen ledtråd vart man ska titta på.
Så jag bedömer att dom som har utvecklat implementeringen för LwIP för ST, bör fortsätta med det.

Jag hoppas verkligen att dom gör så att datat för hemsidorna kan läsas från ROM.

-----------------------------------------
Hur som helst, om inte websocket fungerar, då är det Ajax som jag ska fokusera på? Hur skulle ni ha gjort om ni vill ha liksom en webbapplikation på ett inbyggt system som ska fungera riktigt bra och dynamiskt?

[TomasL]

för det har jag sett på YouTube att det fungerar.

Ja, det är ditt stora problem, istället för att lära dig hur det fungerar, så tar du en video från youtube, suck

Jag hoppas verkligen att dom gör så att datat för hemsidorna kan läsas från ROM.

det kan du göra själv, utan problem, men du måste ha kunskap hur saker och ting faktiskt fungerar.

[DanielM]

Ja, det är ditt stora problem, istället för att lära dig hur det fungerar, så tar du en video från youtube, suck

Från YouTube lär man sig inte teorin. Man lär sig bara tillämpningen.

det kan du göra själv, utan problem, men du måste ha kunskap hur saker och ting faktiskt fungerar.

Enkelt sagt än gjort. Jag har revovisat ST's kommendar på buggen. Ingen har presenterat något förslag än.

[sodjan]

Känslan man får är att du inte riktigt vet vad du håller på med.

Det blir även enklare om de helt slutar med att använda begreppet "hemsida".
Kommunikationsmässigt finns det bara två delar "server" och "browser".

> Jag är bara van att en socket är en socket,

En socket är en förbindelse mellan två hosts över TCPIP.
Det finns en väldefinierat protokoll över hur en socket t.ex. öppnas och stängs.

> men om websocket skiljer sig från socket...

WebSocket är en specialfall med egen protokoll, men det körs fortfarande ovanpå en socket.
En WebSocket innebär att en browser kan öppna en linje (socket) till en webb server som
sedan hålls öppen så länge som ingen av ändarna stänger den. Sedan kan både browser
och webb servern skicka data över den linjen. D.v.s. att man får en "hemsida" som
dynamiskt kan ta emot data utan "pollning" eller att ladda om hela sidan.

> Det måste finnas någon annan lösning. Troligtvis AJAX,

Ajax använder (naturligtvis) också en socket.

Ajax är ungefär samma sak som att ladda om en hel hemsidan, fast det sker från JS.
Så man kan hämta valfria uppdateringar och ändra i bilden utan att ladda om hela bilden.
Men socketen som används stängs direkt då svaret är mottaget av browsern, Till skillnad
från en WebSocket som alltså hålls öppen.

Så det största skillnaden mellan em Ajax-socket och en WebSocket-socket, är att den första
stängs direkt efter att svaret har skickats, den andra hålls öppen tills endera sidan stänger den.
Men i grunden så använder de samma TCPIP socket funktioner för att "connect", "ACK", "close" o.s.v.

> Jag hoppas verkligen att dom gör så att datat för hemsidorna kan läsas från ROM.

Beror på vad du menar. MAC'en kan aldrig läsa från ROM eftersom hårdvaran hindrar det.
Högst sannolikt kommer de att justera exempelkoderna för att kringgå det (d.v.s. mellanlagra i RAM).