Svenska ElektronikForumet

> I de fall jag gjort en funktion så får jag leta mer då jag aldrig kan minnas
> funktionernas namn. Nu kan jag bara söka på case 'U' så är jag där.

OK, här får du gärna förklara bättre. Varför behöver du *minnas* funktionsnamnet ?
Funktionens namn kommer ju att stå, om inte på raden direkt efter, så i alla fall väldigt
nära "case 'U'", alltså på CALL raden.

Sen så är ju hela grejen att man testar av sina funktioner *först* så att man inte
i onödan behöver gå tillbaka till dom när man kodar case-satsen och "högre" lager.
Och är det något man behöver veta om funktionen så läser man sin dokumentation.

> Är du säker på det, Sodjan?

Nej, absolut inte. *Något* ska väl du göra...

"Och så slipper jag göra massor av variabler globala (vilket jag vill undvika)."
Du får också gärna förklara varför du behöver göra massor variabler globala om du refaktoriserar koden till funktioner?

OK, här får du gärna förklara bättre. Varför behöver du *minnas* funktionsnamnet ?
Funktionens namn kommer ju att stå, om inte på raden direkt efter, så i alla fall väldigt
nära "case 'U'", alltså på CALL raden.

För att det blir ett sökmoment till - jag måste markera funktionsnamnet och klicka ctrl-F. jobbigt.

>Du får också gärna förklara varför du behöver göra massor variabler globala om du refaktoriserar koden till funktioner?
Eh.. orkar nog inte gå in på det just nu.. men jag lärde mig ett nytt ord refaktorisera

jesse: läs sista inlägget på förra sidan med
ctrl-f låter långsamt, då hamnar man ju på alla andra ställen funktionen anropas med, har din miljö ingen "go to implementation" (eller vad det nu brukar heta) funktion?

Varför måste du läsa upp hela texterna i ram? Är väll bara att läsa en byte med pgm funktionen och skicka ut den på spi direkt? Sannolikt kommer kompilatorn optimera ner den i något register nånstans.?

Jo, men det är ju just det jag gör, och det var det som ifrågasattes, och man rekommenderade att jag skulle använda "const char[]" istället - och *den* grejen gör att kompilatorn laddar upp innehållet i RAM. Om det tar permanent utrymme, eller om det tillfälligt läggs på stacken när de ska användas vet jag inte... men ... jo, jag tycker precis som du.

Ang.. 16 MB RAM... ok, det kanske finns, men varför betala 100kr mer för en processor som drar mer ström bara för att kunna slriva klumpig kod? Jag har 1kB RAM i min Atmega644 och det räcker utmärkt.

>har din miljö ingen "go to implementation" (eller vad det nu brukar heta) funktion?

Tyvärr har jag nog programmeringsvärldens sämsta miljö - AVR Studio 4 med inbyggd editor. Saknar alla finesser. Tröghet i systemet (min hjärna) är det enda som hindrat mig att byta till nåt bättre. Jag har nåt som fungerar, och har inte orkat krångla med att försöka få nåt annat att fungera. Men har du något tips om bra editor / miljö för AVR som är lite smidigare?

Eclipse + avr-gcc

Du kan koppla AVR-GCC till Visual Studio om du vill, jag har provat. Borde fungera bra även med gratisversionen men det kan vara mer jobb att lära sig en ny IDE än ett nytt programspråk tycker jag.

Programmers Notepad som följer med AVR-GCC och har noll inlärningströskel men ändå bra stöd för just C och är gratis.

Hur funkar det - kan man integrera Programmer's Notepad i AVR Studio eller kör man den separat?

Hur ser ni på de båda andra IDE:na , Eclipse och Visual Studio, vilken tror ni skulle vara enklast att komma igång med? Har hört att Eclipse ska vara krånglig för man får göra en massa (obegripliga?) manuella inställningar för att få den at samarbeta?

Vad har dom för finesser som ni finner mest värdefulla?

Jag har själv aldrig kört Eclipse med avr-gcc, men använder det dagligen på jobbet till diverse projekt med TI och blackfin processorer (men använder deras egna IDEn som debuggers).
Har även använt det till en del hobby-projekt med ARM-processorer, där har jag kört debuggningen i eclipse.
Tycker att det som är knepigt med inställningarna är just att få debuggningen och byggningen att funka, vill man bara använda det som en avancerad editor så är det rätt lätt att komma igång.

Edit:
Funktioner som jag tycker är värdefulla:
- hoppa till deklarationen av funktioner, typer och variabler (F3)
- få fram en lista varifrån funktioner ropas (ctrl-shift-g)
- vandra fram och tillbaka i historik var man hoppat runt i koden (alt-höger/vänster pil)
har säkert glömt en massa, men de där är de jag använder mest

jesse skrev: Ang.. 16 MB RAM... ok, det kanske finns, men varför betala 100kr mer för en processor som drar mer ström bara för att kunna slriva klumpig kod? Jag har 1kB RAM i min Atmega644 och det räcker utmärkt.

Nu var det ju 16kiloByte, Atmega644 är ju lillebror till 1284, och enligt databladet är strömförbrukningen exakt samma. 644 har förövrig 4k minne. Anledningen att välja en större är ju att kunna snabbt göra en prof of concept och få ut en produkt. Sen kan man börja optimera och trimma om man anser att det är lönt. (prisskillnaden mellan en atmega1284(61.16kr) och atmega644 (52.65kr) är alltså 10 kr inte 100 kr) (farnells +100 pris)

Men visst, slarvig kod ska man ju aldrig skriva, men att sitta och optimera en byte här och en byte där tidigt i projektet är sällan lönsamt..
Sen ska man ju inte förtränga att inte alltför sällan så blir de där planerade refactoring eventen aldrig av...

jesse skrev:Hur funkar det - kan man integrera Programmer's Notepad i AVR Studio eller kör man den separat?

Vad jag vet så går det inte att byta ut editordelen i AVR studio mod PNotepad vilket är synd men det går att få dem att samarbeta bra genom att peka projekten mot samma katalog och ha inställningsfilerna i underkataloger. Då kan du koda och kompilera i Programmers Notepad (eller Visual Studio för den delen) och sen ladda och debugga med AVR Studio.

jesse skrev:Hur ser ni på de båda andra IDE:na , Eclipse och Visual Studio, vilken tror ni skulle vara enklast att komma igång med?

Här är en kortfattad och bra beskrivning av hur man ställer in både Visual Studio och Eclipse för att jobba med AVR-GCC: http://www.societyofrobots.com/member_t ... s/node/380