Der AVR-/ARDUINO-Faden

Der chaotische Hauptfaden

Moderatoren: Heaterman, Finger, Sven, TDI, Marsupilami72, duese

Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

lange5766 hat geschrieben:
Daniel hat geschrieben:Hallo,
seid gestern habe ich einen Arduino 2560 aus China.
Den wollte ich aktivieren, es gelingt nicht.
Bekomme den Port nicht geändert usw.
Wie geht man vor wenn er neu aktiviert werden soll???

Danke und Gruß vom Daniel

Hi,

Ich würde sagen der "Arduino 2560 aus China" wird wohl ein günstiger Arduino Mega Clone sein
mit CH340-Chip als USB zu seriell-Umsetzer.

Wenn ein CH340 auf dem Board ist muss zumindest unter Windows der passende Treiber installiert werden.
Siehe http://www.jens-bretschneider.de/aktuel ... b-adapter/

Nach der Installation sollte bei angesteckten Arduino im Gerätemanager ein neuer COM-Port auftauchen,
dann in der Arduino-IDE den gefundenen Port und als Board "Arduino Mega or Mega 2560 einstellen.

Gruß: Marco (lange5766)
Hallo und danke,

nach ich den China Treiber installierte, laufen beide Clone.
Gruß Daniel
Benutzeravatar
erwin
Beiträge: 710
Registriert: Do 15. Aug 2013, 08:57
Wohnort: 68642 Bürstadt
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von erwin »

Hallo ich bekomme diesen
/**
Polargraph Server for Arduino UNO and MEGA compatible boards.
Written by Sandy Noble
Released under GNU License version 3.
http://www.polargraph.co.uk
https://github.com/euphy/polargraph_server_a1


CONFIGURATION!! Read this! Really.
==================================

Kung fu is like a game of chess. You must think first! Before you move.

This is a unified codebase for a few different versions of Polargraph Server.

You can control how it is compiled by changing the #define lines below.

There are five config sections:
1. Specify what kind of controller board you are using
2. Add some libraries if you have a MEGA
3. Specify what kind of motor driver you are using:
i. Adafruit Motorshield v1
ii. Adafruit Motorshield v2
iii. Discrete stepper drivers (eg EasyDriver, stepstick, Pololu gear).*
iv. Signal amplifier like a UNL2003*
4. Turn on some debugging code
5. Disable program features if you need to free up space

For motor drivers iii and iv, you will need to change the values in
configuration.ino to set the exact pins the drivers are wired up to.

*/


// 1. Specify what kind of controller board you are using
// ======================================================
// UNO or MEGA. Uncomment the line for the kind of board you have.
#ifndef MICROCONTROLLER
#define MICROCONTROLLER MC_UNO

#endif


// 2. Add some libraries if you have a MEGA
// ========================================
// Uncomment the SPI and SD lines below if you have a MEGA.
// http://forum.arduino.cc/index.php?topic=173584.0
//#include <SPI.h>
//#include <SD.h>


// 3. Specify what kind of motor driver you are using
// ==================================================
// Only ONE set of lines below should be uncommented.

// i. Adafruit Motorshield v1. The original, and still the best.
// -------------------------------------------------------------
#define ADAFRUIT_MOTORSHIELD_V1


// ii. Adafruit Motorshield v2. It's all squealy.
// ----------------------------------------------
//#define ADAFRUIT_MOTORSHIELD_V2
//#include <Wire.h>
//#include <Adafruit_MotorShield.h>
//#include "utility/Adafruit_PWMServoDriver.h"

// iii. Using discrete stepper drivers? (eg EasyDriver, stepstick, Pololu gear)
// ----------------------------------------------------------------------------
// Don't forget to define your pins in 'configuration.ino'.
//#define SERIAL_STEPPER_DRIVERS

// iv. Using a signal amplifier like a UNL2003?
// --------------------------------------------
// Don't forget to define your pins in 'configuration.ino'.
// #define UNL2003_DRIVER


// 4. Turn on some debugging code if you want horror
// =================================================
//#define DEBUG
//#define DEBUG_COMMS
//#define DEBUG_PENLIFT
//#define DEBUG_PIXEL


// 5. Disable program features if you need to free up space
// ===================================================



/* ===========================================================
These variables are common to all polargraph server builds
=========================================================== */

// ==========================================================
// Some microcontroller's names
#define MC_UNO 1
#define MC_MEGA 2

#include <AccelStepper.h>
#include <Servo.h>
#include <EEPROM.h>
#include "EEPROMAnything.h"

const String FIRMWARE_VERSION_NO = "1.2.1";

// EEPROM addresses
const byte EEPROM_MACHINE_WIDTH = 0;
const byte EEPROM_MACHINE_HEIGHT = 2;
const byte EEPROM_MACHINE_MM_PER_REV = 14; // 4 bytes (float)
const byte EEPROM_MACHINE_STEPS_PER_REV = 18;
const byte EEPROM_MACHINE_STEP_MULTIPLIER = 20;

const byte EEPROM_MACHINE_MOTOR_SPEED = 22; // 4 bytes float
const byte EEPROM_MACHINE_MOTOR_ACCEL = 26; // 4 bytes float
const byte EEPROM_MACHINE_PEN_WIDTH = 30; // 4 bytes float

const byte EEPROM_MACHINE_HOME_A = 34; // 4 bytes
const byte EEPROM_MACHINE_HOME_B = 38; // 4 bytes

const byte EEPROM_PENLIFT_DOWN = 42; // 2 bytes
const byte EEPROM_PENLIFT_UP = 44; // 2 bytes

// Pen raising servo
Servo penHeight;
const int DEFAULT_DOWN_POSITION = 90;
const int DEFAULT_UP_POSITION = 180;
static int upPosition = DEFAULT_UP_POSITION; // defaults
static int downPosition = DEFAULT_DOWN_POSITION;
static int penLiftSpeed = 3; // ms between steps of moving motor
const byte PEN_HEIGHT_SERVO_PIN = 9; //UNL2003 driver uses pin 9
boolean isPenUp = false;

// Machine specification defaults
const int DEFAULT_MACHINE_WIDTH = 650;
const int DEFAULT_MACHINE_HEIGHT = 650;
const int DEFAULT_MM_PER_REV = 95;
const int DEFAULT_STEPS_PER_REV = 400;
const int DEFAULT_STEP_MULTIPLIER = 1;

// working machine specification
static int motorStepsPerRev = DEFAULT_STEPS_PER_REV;
static float mmPerRev = DEFAULT_MM_PER_REV;
static byte stepMultiplier = DEFAULT_STEP_MULTIPLIER;
static int machineWidth = DEFAULT_MACHINE_WIDTH;
static int machineHeight = DEFAULT_MACHINE_HEIGHT;


static float currentMaxSpeed = 800.0;
static float currentAcceleration = 400.0;
static boolean usingAcceleration = true;

int startLengthMM = 800;

float mmPerStep = 0.0F;
float stepsPerMM = 0.0F;

long pageWidth = machineWidth * stepsPerMM;
long pageHeight = machineHeight * stepsPerMM;
long maxLength = 0;

//static char rowAxis = 'A';
const int INLENGTH = 50;
const char INTERMINATOR = 10;
const char SEMICOLON = ';';

float penWidth = 0.8F; // line width in mm

boolean reportingPosition = true;
boolean acceleration = true;

extern AccelStepper motorA;
extern AccelStepper motorB;

boolean currentlyRunning = true;

static char inCmd[10];
static char inParam1[14];
static char inParam2[14];
static char inParam3[14];
static char inParam4[14];

static byte inNoOfParams;

char lastCommand[INLENGTH + 1];
boolean commandConfirmed = false;

int rebroadcastReadyInterval = 5000;
long lastOperationTime = 0L;
long motorIdleTimeBeforePowerDown = 600000L;
boolean automaticPowerDown = true;
boolean powerIsOn = false;

long lastInteractionTime = 0L;

#ifdef PIXEL_DRAWING
static boolean lastWaveWasTop = true;

// Drawing direction
const static byte DIR_NE = 1;
const static byte DIR_SE = 2;
const static byte DIR_SW = 3;
const static byte DIR_NW = 4;

static int globalDrawDirection = DIR_NW;

const static byte DIR_MODE_AUTO = 1;
const static byte DIR_MODE_PRESET = 2;
static byte globalDrawDirectionMode = DIR_MODE_AUTO;
#endif

#if MICROCONTROLLER == MC_MEGA
#define READY_STR "READY_100"
#else
#define READY_STR "READY"
#endif

#define RESEND_STR "RESEND"
#define DRAWING_STR "DRAWING"
#define OUT_CMD_SYNC_STR "SYNC,"

char MSG_E_STR[] = "MSG,E,";
char MSG_I_STR[] = "MSG,I,";
char MSG_D_STR[] = "MSG,D,";

const static char COMMA[] = ",";
const static char CMD_END[] = ",END";
const static String CMD_CHANGELENGTH = "C01";
const static String CMD_CHANGEPENWIDTH = "C02";
#ifdef PIXEL_DRAWING
const static String CMD_DRAWPIXEL = "C05";
const static String CMD_DRAWSCRIBBLEPIXEL = "C06";
const static String CMD_CHANGEDRAWINGDIRECTION = "C08";
const static String CMD_TESTPENWIDTHSQUARE = "C11";
#endif
const static String CMD_SETPOSITION = "C09";
#ifdef PENLIFT
const static String CMD_PENDOWN = "C13";
const static String CMD_PENUP = "C14";
const static String CMD_SETPENLIFTRANGE = "C45";
#endif
#ifdef VECTOR_LINES
const static String CMD_CHANGELENGTHDIRECT = "C17";
#endif
const static String CMD_SETMACHINESIZE = "C24";
const static String CMD_GETMACHINEDETAILS = "C26";
const static String CMD_RESETEEPROM = "C27";
const static String CMD_SETMACHINEMMPERREV = "C29";
const static String CMD_SETMACHINESTEPSPERREV = "C30";
const static String CMD_SETMOTORSPEED = "C31";
const static String CMD_SETMOTORACCEL = "C32";
const static String CMD_SETMACHINESTEPMULTIPLIER = "C37";

void setup()
{
Serial.begin(57600); // set up Serial library at 57600 bps
Serial.println("POLARGRAPH ON!");
Serial.print("Hardware: ");
Serial.println(MICROCONTROLLER);

#if MICROCONTROLLER == MC_MEGA
Serial.println("MC_MEGA");
#elif MICROCONTROLLER == MC_UNO
Serial.println("MC_UNO");
#else
Serial.println("No MC");
#endif
configuration_motorSetup();
eeprom_loadMachineSpecFromEeprom();
configuration_setup();

motorA.setMaxSpeed(currentMaxSpeed);
motorA.setAcceleration(currentAcceleration);
motorB.setMaxSpeed(currentMaxSpeed);
motorB.setAcceleration(currentAcceleration);

float startLength = ((float) startLengthMM / (float) mmPerRev) * (float) motorStepsPerRev;
motorA.setCurrentPosition(startLength);
motorB.setCurrentPosition(startLength);
for (int i = 0; i < INLENGTH; i++) {
lastCommand = 0;
}
comms_ready();

#ifdef PENLIFT
penlift_penUp();
#endif
delay(500);

}

void loop()
{
if (comms_waitForNextCommand(lastCommand))
{
#ifdef DEBUG_COMMS
Serial.print(F("Last comm: "));
Serial.print(lastCommand);
Serial.println(F("..."));
#endif
comms_parseAndExecuteCommand(lastCommand);
}
}

#if MICROCONTROLLER == MC_MEGA
const static String CMD_TESTPENWIDTHSCRIBBLE = "C12";
const static String CMD_DRAWSAWPIXEL = "C15,";
const static String CMD_DRAWCIRCLEPIXEL = "C16";
const static String CMD_SET_ROVE_AREA = "C21";
const static String CMD_DRAWDIRECTIONTEST = "C28";
const static String CMD_MODE_STORE_COMMANDS = "C33";
const static String CMD_MODE_EXEC_FROM_STORE = "C34";
const static String CMD_MODE_LIVE = "C35";
const static String CMD_RANDOM_DRAW = "C36";
const static String CMD_START_TEXT = "C38";
const static String CMD_DRAW_SPRITE = "C39";
const static String CMD_CHANGELENGTH_RELATIVE = "C40";
const static String CMD_SWIRLING = "C41";
const static String CMD_DRAW_RANDOM_SPRITE = "C42";
const static String CMD_DRAW_NORWEGIAN = "C43";
const static String CMD_DRAW_NORWEGIAN_OUTLINE = "C44";

/* End stop pin definitions */
const int ENDSTOP_X_MAX = 17;
const int ENDSTOP_X_MIN = 16;
const int ENDSTOP_Y_MAX = 15;
const int ENDSTOP_Y_MIN = 14;

long ENDSTOP_X_MIN_POSITION = 130;
long
ENDSTOP_Y_MIN_POSITION = 130;

// size and location of rove area
long rove1x = 1000;
long rove1y = 1000;
long roveWidth = 5000;
long roveHeight = 8000;

boolean swirling = false;
String spritePrefix = "";
int textRowSize = 200;
int textCharSize = 180;

boolean useRoveArea = false;

int commandNo = 0;
int errorInjection = 0;

boolean storeCommands = false;
boolean drawFromStore = false;
String commandFilename = "";

// sd card stuff
const int chipSelect = 53;
boolean sdCardInit = false;

// set up variables using the SD utility library functions:
File root;
boolean cardPresent = false;
boolean cardInit = false;
boolean echoingStoredCommands = false;

// the file itself
File pbmFile;

// information we extract about the bitmap file
long pbmWidth, pbmHeight;
float pbmScaling = 1.0;
int pbmDepth, pbmImageoffset;
long pbmFileLength = 0;
float pbmAspectRatio = 1.0;

volatile int speedChangeIncrement = 100;
volatile int accelChangeIncrement = 100;
volatile float penWidthIncrement = 0.05;
volatile int moveIncrement = 400;

boolean currentlyDrawingFromFile = false;
String currentlyDrawingFilename = "";

static float translateX = 0.0;
static float translateY = 0.0;
static float scaleX = 1.0;
static float scaleY = 1.0;
static int rotateTransform = 0;

#endif


Sketch nicht zum laufen habe für mich unlösbare Fehlermeldungen schon beim kompilieren .Er befindet sich hier https://github.com/euphy/polargrap ... 1-26-23-24
es sollten zwei Schritt motoren mit zweihundert schritten und ein servo mit einem Motor Shield v2.0 angesteuert werden
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Wie wäre es wenn du diese "unlösbaren Fehlermeldungen" postest? Das wäre deutlich Sinnvoller als den Code hier rein zu kopieren... und dann auch noch ohne Code-Tags. Der Link zu Github ist übrigens 404. So können wir dir nicht helfen.
Benutzeravatar
gafu
Beiträge: 6393
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

Name vergessen hat geschrieben:Deine Befehlszeile versucht, das Ding als STK500 anzusprechen (es gibt Bootloader, für die das korrekt ist). Das STK500 ist aber ein RS232-Gerät (obwohl es dabei hauptsächlich um das Protokoll geht, kann das ggfs. auch die Port-Einstellung beeinflussen, und die kannst Du ja z.Zt. nicht ändern, oder meinst Du einen Port im AVR-Code? Da Dein Rechner maximal einen RS232-Port haben dürfte, schießt die IDE sich auf den ein; aber auch, wenn Du mehrere hättest, würde davon keiner stimmen).
Der Uno montiert sich aber als USB-Gerät (zumindest unter Linux).
Hier war offensichtlich doch windoof gefragt.. aber trotzdem der vollständigkeit halber:
Es gibt die boards mit verschiedenen seriell-usb-adaptern.
original ist ein quadratischer "MEGA16U2" drauf.
Der spricht USB und hat seine eigene firmware und meldet sich als usb-device an.

Viele der Clones haben aber jetzt stino-USB-Seriell-Chips drauf, was auch nix macht. Treiber sind unter linux für alle gängigen devices im Kernel enthalten, unter windoof muss man halt suchen ob der serielle port auftaucht.

Ist der USb-Ser-Port da, (gerätemanager bei windoof), den im Arduino IDE auswählen. Nicht vergessen das richtige Arduino-board auszuwählen, sonst gibts viele fehler...

Unter linux das gerät anstecken (USB) und dann einfach mal mit "dmesg" die letzten kernelmeldungen ansehen. Da sollte in den letzten Zeilen das usb-gerät als /dev/ttyACM0 oder sowas aufgelistet sein.

Dann das arduino-IDE von der konsole mit root-rechten starten, oder mit chmod der "datei" /dev/ttyACM0 zugriffsrechte (schreiben auch!) für "alle" verpassen, und den eigenen user der gruppe "dialout" hinzufügen (für rechte für serielle kommunikation).

Sonst geht unter linux kein zugriff von der IDE auf das Gerät, weil die Rechte nicht vorhanden sind.
Benutzeravatar
gafu
Beiträge: 6393
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

@erwin: Code bitte immer mit dem Code-Tag einbinden.
Eerstens wird dann im Forum nicht Code zu smileys konvertiert und damit kaputt gemacht, und zweitens bekommt er nen feld mit scrollbalken und macht die lesbarkeit des Thread hier nicht kaputt.

@Bauteiltöter: Der richtige link steht oben im Code.
Benutzeravatar
xoexlepox
Beiträge: 4815
Registriert: So 11. Aug 2013, 19:28
Wohnort: So etwa in der Mitte

Re: Der AVR-/ARDUINO-Faden

Beitrag von xoexlepox »

gafu hat geschrieben:Unter linux das gerät anstecken (USB) und dann einfach mal mit "dmesg" die letzten kernelmeldungen ansehen.
Das geht mit "dmesg"? Ich verwende immer "tail -f /var/log/messages", das zeigt dann kontinuierlich an (bis du es mit "ctrl-C" abbrichst). Mag sein, das manche Distributionen dafür Rootreche (oder ein "sudo " davor) haben wollen.
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Jo, dmesg nehme ich auch immer. Tippt sich schneller und scrollt nicht weiter (naja, so viel scrollt da ja nicht), und man braucht auch kein STRG-C, bevor man weitertippen kann.
gafu hat geschrieben:Dann das arduino-IDE von der konsole mit root-rechten starten, oder mit chmod der "datei" /dev/ttyACM0 zugriffsrechte (schreiben auch!) für "alle" verpassen, und den eigenen user der gruppe "dialout" hinzufügen (für rechte für serielle kommunikation).
Eschd, man braucht beides? Ich hätte jetzt erwartet, daß das mit Lese+Schreibrechten für jeden gegessen sei, bzw. hätte das wohl nur in dialout o.Ä. gepackt.
Benutzeravatar
gafu
Beiträge: 6393
Registriert: Mi 14. Aug 2013, 20:56
Wohnort: nahe Jena
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von gafu »

ob man beides braucht weiß ich auch nicht mit sicherheit, nur das adduser --addgroup nicht ausreicht.
Das blöde ist ja, das die vergebenen rechte auf dem usb-seriell-device bei jedem abstecken wieder verloren gehen, und man erst wieder in den linux-eingeweiden herumfummeln muss um eine ausnahme zu konfigurieren.

Da ist es echt einfacher, wenn man das nur alle jubeljahre mal braucht, die arduino-ide als root zu starten und das programmchen als root auf die hardware draufzubrezeln.

Das gleiche gilt leider auch für AVRDUDE mit dem usbasp, und natürlich für tty-usb-devices von 3d-druckern unter linux.
Wenn man den drucker aber regelmäßig braucht, dann kann man sich ja ein shellscript machen (mit gksu drinn) zum starten vom Programm, und den chmod-befehl vor dem programmstart automatisiert ausführen.
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Also zumindest die usbasp-Sache hatte ich gestern auch, da gibt es einen sehr einfachem Workaround. Einfach mal nach "usbasp Linux arduino" oder so googeln, da hatte ich was gefunden. Meine UNOs hab ich auch mit 2 Befehlen zum laufen bekommen.

Viele Grüße!
margau
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Trotz etwas Skepsis beim Chinamann eine Charge Nanos (328) mit CH-340 gekauft. Funktioniert mit dem Win 7-CH-341-Treiber einwandfrei und geht nahtlos in der IDE. Für knapp 2 Euro pro Stück und dazu ESP8266 (2,5 €) sehr schönes Teil für Funk-Sensoren.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Heaterman hat geschrieben:Trotz etwas Skepsis beim Chinamann eine Charge Nanos (328) mit CH-340 gekauft. Funktioniert mit dem Win 7-CH-341-Treiber einwandfrei und geht nahtlos in der IDE. Für knapp 2 Euro pro Stück und dazu ESP8266 (2,5 €) sehr schönes Teil für Funk-Sensoren.
Kann ich bestätigen!

Ich hatte letzten Sommer eine Idee, die rein analog nicht lösbar ist. Mit digitaler Hardware mochte ich nicht anfangen, unbekannte Parameter - also vom Ali zwei UNOs geordert, in Summe 5,58 € incl Kartengebühren.

Nach etwas Sucherei den CH341-Treiber gefunden, spielte klaglos. Quer über diverse Foren finden sich diverse Leute, die zu dusselig sind, den CH341-Treiber zu finden bzw. zu installieren - für die ist das Original vermutlich besser, das soll Windows angeblich per WinUpdate selbst holen.

Da ich den UNO mechanisch dämlich finde, erstmal zwei Nanos gekauft und bespielt, später weitere - zwischen 1,95 und 2,99 U$D. Hier gab es einen Ausrutscher, zwei von drei gelieferten spielten nicht. Gab etwas Diskussion mit dem Dispute beim Ali, aber wurde erstattet. Inzwischen weiß ich, dass auf den zwei ChinNanos der Bootloader fehlte - aber, wenn ich Hardware habe, den flashen zu können, brauche ich eigentlich keinen Arduino mehr.

Ganz nett finde ich die Adapterplatinen, wenn man mal einen fliegenden Testaufbau machen muss.

Für den einen oder anderen Einsteiger hier könnte das aktuelle Sonderheft von Heise interessant sein: 24,95 Euro versandkostenfrei incl. einem UNO.
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Ich denke mal, das Hauptproblem, das viele mit dem Treiber haben, ist das, dass der nicht richtig entpackt wird und die Leute in dem chinesischen Konfigurator des Treibers landen, statt das Setup zu finden, mit dem das Ding in einer Minute erledigt ist.
Benutzeravatar
Hightech
Beiträge: 11500
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Für den avr-dude gibt die Anleitung die Regeln so anzupassen, das die USB devices direkt beim einstecken der Gruppe dialout oder hier im Beispiel useres zugeordnet werden.
Irgenwo hier kann man auch festlegen, das ein bestimmtes USB Gerät immer auf z.B. ttyS05 gelegt wird

http://www.mikrocontroller.net/articles/AVRDUDE



Aus Mikrocontroller.net:

Code: Alles auswählen

Dies liegt daran, dass die device-nodes, die beim Einstecken des USB-Programmers von udev angelegt werden, root zugeordnet sind. Man kann dies ändern, indem man udev-Regeln für die verwendeten Programmer anlegt. Unter Debian muß man dazu nur eine neue Datei, z. B. 015_usbprog.rules unter /etc/udev/rules.d anlegen, z. B. mit folgenden Inhalt:


# Atmel AVR ISP mkII
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2104", GROUP="users", MODE="0660"

# usbprog bootloader
ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c62", GROUP="users", MODE="0660"
 
# USBasp programmer
ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="users", MODE="0660"
 
# USBtiny programmer
ATTRS{idVendor}=="1781", ATTRS{idProduct}=="0c9f", GROUP="users", MODE="0660"


Danach muss in der Regel der udev-Dienst neu gestartet werden, was -- je nach System -- mit einem der beiden folgenden Befehle funktionieren sollte (natürlich nur als root):

sudo /sbin/udevadm control --reload-rules

bei aktueller udev-version, oder

sudo /sbin/udevcontrol --reload_rules
Benutzeravatar
zauberkopf
Beiträge: 9535
Registriert: So 11. Aug 2013, 15:33
Wohnort: gefährliches Halbwissen

Re: Der AVR-/ARDUINO-Faden

Beitrag von zauberkopf »

Hi !

Ich hatte mal ne Website gefunden, da konnte man ganz einfach für PWM sich die Register und sogar Code ausgeben lassen.
Also AVR Wählen, frequenz, verhältnis, pin.. und schwups war alles da.
Find ich blos nicht mehr wieder.

hat da jemand was für mich ?
lg Jan
Benutzeravatar
Hightech
Beiträge: 11500
Registriert: So 11. Aug 2013, 18:37

Problemchen

Beitrag von Hightech »

Moin, hab da mal ein Problemchen
Ich hab hier so ein Rfid U2270 Eval Board mit einem at90S8515 drauf.
Einen "passenden" Code habe ich auch gefunden.

Blöderweise konfiguriert er den INT0 als "trigger on falling and rising Edge"
Kacke, der 90S8515 kann nur trigger auf LOW, falling or rising.

Bild

Was mach ich denn jetzt ?

Kann ich sowas schreiben wie:
SIGNAL (SIG_INTERRUPT1)||(SIG_INTERRUPT0)
dann lasse ich den INT0 als rising und den INT als fallig laufen und packe das Signal auf beide Eingänge.

Oder kann ich den INTF0 nutzen ?

Also INT1 falling INFT=1 = interruptroutine INT0
INT0 rising = Interrupt routine INT0
Benutzeravatar
Fritzler
Beiträge: 12604
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Problemchen

Beitrag von Fritzler »

Hightech hat geschrieben:Dann lasse ich den INT0 als rising und den INT1 als fallig laufen und packe das Signal auf beide Eingänge.
Jo das würd ich auch so machen, aber dein Interruptaufruf geht so nicht.
Mach für jeden der beiden Interrupts ein Handler und beide rufen dieselbe Unterfunktion auf.

void feed_cookies(void){
//Interruptbehandlung
}

SIGNAL (SIG_INTERRUPT0){
feed_cookies();
}

SIGNAL (SIG_INTERRUPT1){
feed_cookies();
}
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

SIGNAL (SIG_INTERRUPT1)||(SIG_INTERRUPT0)

geht nicht, SIGNAL() ist ein Makro und expandiert zu einem normalen Funktionsaufruf (mit zusätzlichen Attributen), daher kann man das nicht so schreiben.

Fritzlers Ansatz ist schon der Richtige, abgesehen davon, das SIGNAL() schon seit Jahren "deprecated" ist und nicht mehr genutzt werden sollte.
avr-libc doku hat geschrieben:Deprecated: Do not use SIGNAL() in new code. Use ISR() instead.
Avr-libc.
ACHTUNG, wenn man ISR() statt SIGNAL() verwendet ändern sich die Vektor-Namen!
In deinem Fall INT0_vect und INT1_vect.

Und das ganze hat den Nachteil das der Compiler nicht mehr so gut optimieren muss, er muss alle caller-saved register sichern. Es sei denn es wird geinlined, da müsste man dann mal ins ELF schauen wenn man es genauer wissen möchte.


Eine Alternative, vermutlich die eleganteste, wäre auch das Makro ISR_ALIASOF, damit kann man zwei Interrupt-Vektoren mit einer ISR verknüpfen.

Das sähe dann so aus:

Code: Alles auswählen

ISR(INT0_vect) 
{
  //Dein Code hier
}

ISR(INT1_vect, ISR_ALIASOF(INT0_vect) );
Das ganze funktioniert aber erst ab GCC 4.2
Benutzeravatar
Fritzler
Beiträge: 12604
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Bauteiltöter hat geschrieben:Fritzlers Ansatz ist schon der Richtige, abgesehen davon, das SIGNAL() schon seit Jahren "deprecated" ist und nicht mehr genutzt werden sollte.
ich hab da nur SIGNAL geschrieben, weil das in HIghtechs Ausgangspost auch schon so stand :twisted:
Benutzeravatar
Hightech
Beiträge: 11500
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Jau, gute Idee.

Nun ist mir der AT90S8515 abgeraucht. Kotz !

Der Mega88 kann es ja von Hause aus.

Danke schön trotz dem !!
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

Moin Leute,

Ein großer Kritikpunkt an Arduino ist ja vor allem die Performance die so viel schlechter ist, deswegen habe ich mich in einem Anflug von Langeweile mal hingesetzt und einen einfachen Portzugriff zwischen Arduino und "klassischem" C gegenüber gestellt.
Alle Beispiele werden mit avr-gcc 4.5.1 und -Os als Optimierung kompiliert.

Einfache Aufgabe: Setze PD2 auf "high".

1. Versuch, klassischer Portzugriff bei AVRs, Bitgefrickel:

Code: Alles auswählen

#include <avr/io.h>
void f1(void)
{
	PORTD |= (1<<PD2);
}
avr-gcc -S -Os -mmcu=atmega328p test.c
macht daraus:

Code: Alles auswählen

	.file	"test.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	f1
	.type	f1, @function
	f1:
	/* prologue: function */
	/* frame size = 0 */
	/* stack size = 0 */
	.L__stack_usage = 0
		sbi 43-32,2
	/* epilogue start */
		ret
	.size	f1, .-f1
Wenn man die Hinweise und zusätze für den Linker weglässt bleibt also das hier über:

Code: Alles auswählen

	f1:
		sbi 43-32,2
		ret
Ein einfaches sbi, optimaler geht es nicht mehr. In realem Code würde das vermutlich auch noch geinlined.

Jetzt zu der Arduino-Variante:

Code: Alles auswählen

void f2(void)
{
	digitalWrite(2,1);
}
Das geht natürlich nicht durch den Compiler, da fehlen ja die Funktionen. Also, auf ins Internet und in die innereien von Arduino. Kann ja nicht so viel Code sein den man dafür braucht, oder?
Eine halbe Stunde später und 300MB Sourcecode reicher hatte ich dann alles auf meinem Computer (ok, zugegeben, da ist auch der Sourcecode der Arduino-"IDE" dabei).

Code: Alles auswählen

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <avr/interrupt.h>

#define cbi(port,bit) (port) &= ~(1 << (bit)) 

#define PB 2
#define PC 3
#define PD 4

#define NOT_A_PIN 0
#define NOT_A_PORT 0

#define HIGH 0x1
#define LOW  0x0

#define NOT_ON_TIMER 0
#define TIMER0A 1
#define TIMER0B 2
#define TIMER1A 3
#define TIMER1B 4
#define TIMER2  6
#define TIMER2A 7
#define TIMER2B 8

#define digitalPinToTimer(P) ( pgm_read_byte( digital_pin_to_timer_PGM + (P) ) )
#define digitalPinToBitMask(P) ( pgm_read_byte( digital_pin_to_bit_mask_PGM + (P) ) )
#define digitalPinToPort(P) ( pgm_read_byte( digital_pin_to_port_PGM + (P) ) )
#define portOutputRegister(P) ( (volatile uint8_t *)( pgm_read_word( port_to_output_PGM + (P))) )
const uint8_t PROGMEM digital_pin_to_port_PGM[] = {
        PD, /* 0 */
        PD,
        PD,
        PD,
        PD,
        PD,
        PD,
        PD,
        PB, /* 8 */
        PB,
        PB,
        PB,
        PB,
        PB,
        PC, /* 14 */
        PC,
        PC,
        PC,
        PC,
        PC,
};

const uint8_t PROGMEM digital_pin_to_timer_PGM[] = {
        NOT_ON_TIMER, /* 0 - port D */
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        TIMER2B,
        NOT_ON_TIMER,
        TIMER0B,
        TIMER0A,
        NOT_ON_TIMER,
        NOT_ON_TIMER, /* 8 - port B */
        TIMER1A,
        TIMER1B,
        TIMER2A,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER, /* 14 - port C */
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
        NOT_ON_TIMER,
};
const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[] = {
        _BV(0), /* 0, port D */
        _BV(1),
        _BV(2),
        _BV(3),
        _BV(4),
        _BV(5),
        _BV(6),
        _BV(7),
        _BV(0), /* 8, port B */
        _BV(1),
        _BV(2),
        _BV(3),
        _BV(4),
        _BV(5),
        _BV(0), /* 14, port C */
        _BV(1),
        _BV(2),
        _BV(3),
        _BV(4),
        _BV(5),
};

const uint16_t PROGMEM port_to_output_PGM[] = {
        NOT_A_PORT,
        NOT_A_PORT,
        (uint16_t) &PORTB,
        (uint16_t) &PORTC,
        (uint16_t) &PORTD,
};

static void turnOffPWM(uint8_t timer)
{
        switch (timer)
        {
                case TIMER1A:   cbi(TCCR1A, COM1A1);    break;
                case TIMER1B:   cbi(TCCR1A, COM1B1);    break;
                case  TIMER0A:  cbi(TCCR0A, COM0A1);    break;
                case  TIMER0B:  cbi(TCCR0A, COM0B1);    break;
                case  TIMER2A:  cbi(TCCR2A, COM2A1);    break;
                case  TIMER2B:  cbi(TCCR2A, COM2B1);    break;
        }
}

void digitalWrite(uint8_t pin, uint8_t val)
{
        uint8_t timer = digitalPinToTimer(pin);
        uint8_t bit = digitalPinToBitMask(pin);
        uint8_t port = digitalPinToPort(pin);
        volatile uint8_t *out;

        if (port == NOT_A_PIN) return;

        // If the pin that support PWM output, we need to turn it off
        // before doing a digital write.
        if (timer != NOT_ON_TIMER) turnOffPWM(timer);

        out = portOutputRegister(port);

        uint8_t oldSREG = SREG;
        cli();

        if (val == LOW) {
                *out &= ~bit;
        } else {
                *out |= bit;
        }

        SREG = oldSREG;
}

void f2(void)
{
	digitalWrite(2,1);
}
Schnuckelige 140 Zeilen C, exklusive meiner aufrufenden Testfunktion "f2". Zu sehen sind einige Tabellen im Flash, Pointer werden dereferenziert, 101 Abfragen gegen Fehlbedienung... Zweifel kommen auf ob sich das ganze Effektiv kompilieren lässt.
avr-gcc -S -Os -mmcu=atmega328p test2.c bestätigt das ganze:

Code: Alles auswählen

	.file	"test2.c"
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
	.text
.global	digitalWrite
	.type	digitalWrite, @function
digitalWrite:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	ldi r25,lo8(0)
	movw r30,r24
	subi r30,lo8(-(digital_pin_to_timer_PGM))
	sbci r31,hi8(-(digital_pin_to_timer_PGM))
/* #APP */
 ;  121 "test2.c" 1
	lpm r18, Z
	
 ;  0 "" 2
/* #NOAPP */
	movw r30,r24
	subi r30,lo8(-(digital_pin_to_bit_mask_PGM))
	sbci r31,hi8(-(digital_pin_to_bit_mask_PGM))
/* #APP */
 ;  122 "test2.c" 1
	lpm r20, Z
	
 ;  0 "" 2
/* #NOAPP */
	subi r24,lo8(-(digital_pin_to_port_PGM))
	sbci r25,hi8(-(digital_pin_to_port_PGM))
	movw r30,r24
/* #APP */
 ;  123 "test2.c" 1
	lpm r24, Z
	
 ;  0 "" 2
/* #NOAPP */
	tst r24
	brne .+2
	rjmp .L1
	tst r18
	breq .L3
	cpi r18,lo8(3)
	breq .L6
	cpi r18,lo8(4)
	brsh .L10
	cpi r18,lo8(1)
	breq .L4
	cpi r18,lo8(2)
	brne .L3
	rjmp .L17
.L10:
	cpi r18,lo8(7)
	breq .L8
	cpi r18,lo8(8)
	breq .L9
	cpi r18,lo8(4)
	brne .L3
	rjmp .L18
.L6:
	lds r25,128
	andi r25,lo8(127)
	rjmp .L13
.L18:
	lds r25,128
	andi r25,lo8(-33)
.L13:
	sts 128,r25
	rjmp .L3
.L4:
	in r25,68-32
	andi r25,lo8(127)
	rjmp .L15
.L17:
	in r25,68-32
	andi r25,lo8(-33)
.L15:
	out 68-32,r25
	rjmp .L3
.L8:
	lds r25,176
	andi r25,lo8(127)
	rjmp .L14
.L9:
	lds r25,176
	andi r25,lo8(-33)
.L14:
	sts 176,r25
.L3:
	mov r30,r24
	ldi r31,lo8(0)
	lsl r30
	rol r31
	subi r30,lo8(-(port_to_output_PGM))
	sbci r31,hi8(-(port_to_output_PGM))
/* #APP */
 ;  132 "test2.c" 1
	lpm r18, Z+
	lpm r19, Z
	
 ;  0 "" 2
/* #NOAPP */
	movw r26,r18
	in r25,__SREG__
/* #APP */
 ;  135 "test2.c" 1
	cli
 ;  0 "" 2
/* #NOAPP */
	tst r22
	brne .L11
	ld r24,X
	com r20
	and r24,r20
	rjmp .L16
.L11:
	ld r24,X
	or r24,r20
.L16:
	st X,r24
	out __SREG__,r25
.L1:
	ret
	.size	digitalWrite, .-digitalWrite
.global	f2
	.type	f2, @function
f2:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
	ldi r24,lo8(2)
	ldi r22,lo8(1)
	call digitalWrite
/* epilogue start */
	ret
	.size	f2, .-f2
.global	main
	.type	main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
/* epilogue start */
	ret
	.size	main, .-main
.global	digital_pin_to_port_PGM
	.section	.progmem.data,"a",@progbits
	.type	digital_pin_to_port_PGM, @object
	.size	digital_pin_to_port_PGM, 20
digital_pin_to_port_PGM:
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	4
	.byte	2
	.byte	2
	.byte	2
	.byte	2
	.byte	2
	.byte	2
	.byte	3
	.byte	3
	.byte	3
	.byte	3
	.byte	3
	.byte	3
.global	digital_pin_to_timer_PGM
	.type	digital_pin_to_timer_PGM, @object
	.size	digital_pin_to_timer_PGM, 20
digital_pin_to_timer_PGM:
	.byte	0
	.byte	0
	.byte	0
	.byte	8
	.byte	0
	.byte	2
	.byte	1
	.byte	0
	.byte	0
	.byte	3
	.byte	4
	.byte	7
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
	.byte	0
.global	digital_pin_to_bit_mask_PGM
	.type	digital_pin_to_bit_mask_PGM, @object
	.size	digital_pin_to_bit_mask_PGM, 20
digital_pin_to_bit_mask_PGM:
	.byte	1
	.byte	2
	.byte	4
	.byte	8
	.byte	16
	.byte	32
	.byte	64
	.byte	-128
	.byte	1
	.byte	2
	.byte	4
	.byte	8
	.byte	16
	.byte	32
	.byte	1
	.byte	2
	.byte	4
	.byte	8
	.byte	16
	.byte	32
.global	port_to_output_PGM
	.type	port_to_output_PGM, @object
	.size	port_to_output_PGM, 10
port_to_output_PGM:
	.word	0
	.word	0
	.word	37
	.word	40
	.word	43
Ein gewaltiger Code-Klotz. Um einen Pin zu setzen!
Flash-Größe ist dabei nicht mal das größte Problem, eher das die Ausführung ewigkeiten dauert.
Da das Teil echt unübersichtlich ist habe ich den C-Quelltext um eine main() erweitert und das ganze durchcompiliert, anschließend fördert ein Aufruf von avr-nm --size-sort --print-size folgendes zu Tage:

Code: Alles auswählen

Position | Größe | Art | Name
00000174 00000006 T main
0000016a 0000000a T f2
000000a4 0000000a T port_to_output_PGM
00000090 00000014 T digital_pin_to_bit_mask_PGM
00000068 00000014 T digital_pin_to_port_PGM
0000007c 00000014 T digital_pin_to_timer_PGM
000000c6 000000a4 T digitalWrite
6 Bytes für die Main, 10 Bytes für meine f2-Funktion.
Dann 10 und 3x 20 Bytes für die Übersetzungsmakros (bzw deren Tabellen im Flash) und 164 Bytes für die eigentliche digitalWrite()-Funktion. "Nur" diese 164 Bytes sind Code (und natürlich main/f2).

Fazit:
Der Laufzeitunterschied ist gewaltig. Beim AVR kann man halbwegs davon ausgehen das die Laufzeit linear mit der Codegröße wächst, mit mehr 160 Bytes für digitalWrite() im Gegensatz zu 4 Bytes für Bitshifts ist man also bei einem Geschwindigkeitsfaktor von ~40.

Und was ist der Vorteil? Ich kann keinen sehen.
Wenn man mit dem C-Syntax für Bitgefrickel nicht klar kommt, dann kann man das ganze auch hinter Makros verstecken. Oder, an der Stelle der Arduino-Ersteller, hätte man das ganze in ordentliche C++-Templates stopfen können. Das ist zwar für die Arduino-Entwickler komplizierter, dafür lässt es sich so schreiben, dass der Compiler es in zu einem einfachen "sbi" wegoptimieren kann. (Im Statischen Fall, wird der angesprochene Port/Pin variabel geht das natürlich nciht mehr so einfach. Das ist auch der einzige Vorteil des Arduino-Code, er wächst nicht mehr wenn man die Übergabeparameter an digitalWrite() Variable gestaltet, im Gegensatz zum C-Code, der dann etwas hässlicher würde. Allerdings ahbe ich diesen Fall noch in keinem Programm gehabt, das lässt sich eigentlich immer eleganter lösen).
Das Beispiel mit den C++-Templates war vor einiger Zeit mal im mikrocontroller.net.
Der Arduino-Code, so wie er jetzt ist, hat eigentlich nur den "Vorteil", das fehlerhafte Optionen zur Laufzeit abgefangen werden (wie z.B. if (port == NOT_A_PIN) return;) und der Code einfach "nicht funktioniert".
Beim C-Bitgeshifte funktioniert der Code auch nicht oder aber der Compiler warnt einen mit Meldungen wie "test.c:4:2: warning: left shift count >= width of type" (Im Falle von dicken Fingern z.B.).

Ich habe ehrlich gesagt wenig Zweifel daran, dass es bei anderen, grundlegenden Funktionien wie Timern/PWM, UART und I2C ähnlich aussieht. Libs auf höheren Ebenen wie LCD-Displays oder Sensoren dürften deutlich besser aussehen, abgesehen davon das sie auf die verkorksten Grundbibliotheken aufsetzen.

So, die akute Langeweile ist vorbei. Was ihr jetzt damit anfangt? Euer Bier.

lg
Bauteiltöter.
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Hallo!
Ein bisschen muss ich den Arduino ja jetzt verteidigen.

Was ich zuerst zu sagen habe: So wie ich das sehe initialisiert der Arduino, bevor er in die Hauptschleife geht, auch noch diverse Timer die er für Dinge wie Delay oder millis() braucht. Das machst man beim reinen C natürlich nicht.

Desweiteren ist der Arduino darauf ausgelegt, mit Programmiertechnisch nicht ganz so begabten Leuten zu funktionieren. Jetzt erklär du denen mal, welchen Port sie wann setzten müssen, wo im 150-seitigen Datenblatt das steht.

Ich persönlich bin dankbar, dass es die Arduino-IDE gibt, mit sowas wird man nämlich deutlich einfacher an das richtige rangeführt. Und um ein paar LEDs Faden zu lassen reicht das auch.

Viele Grüße!
margau
Benutzeravatar
Fritzler
Beiträge: 12604
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

Nö, das Setup hat er nicht mit kompiliert.
Bauteiltöter hat nicht per vergurkter A IDE compiliert, sondern die digitalWrite Funktion aus deren Libs compiliert.

Wie er auch sagte, gibt es bessere Wege dieses digitalWrite zu implementieren, sodass der compiler es dann doch wieder schafft ein sbi draus zu zaubern.

Wenn schon verteidigen, dann vorher den Text lesen und verstehen ;)
margau
Beiträge: 78
Registriert: Sa 7. Nov 2015, 23:15
Wohnort: Rhein-Main

Re: Der AVR-/ARDUINO-Faden

Beitrag von margau »

Ok, das mit dem Setup hab ich heute morgen nicht gesehen. Trotzdem sollte man meiner Meinung nach nicht so stark auf Arduino rumhaken, es ist wenn auch nicht optimal, für viele die beste/einzige Lösung.
Seit doch einfach froh das ihr es nicht braucht ;)

Und ja, man kann einiges besser lösen. Ich bin mir sicher die Arduino-Community freut sich über entsprechende Beiträge :D

Viele Grüße!
margau
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Lass Dich nicht von Fritzler ärgern, der hasst Arduinos eben und kanns nicht lassen... :)

Die Dinger erfüllen ihren Zweck und es wird keiner gezwungen, sie zu nehmen, aus, das brauchts keinen Richtungsstreit.
Benutzeravatar
Fritzler
Beiträge: 12604
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Fritzler »

?
Bauteiltöter wars!
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Bauteiltöter hat geschrieben:Ein großer Kritikpunkt an Arduino ist ja vor allem die Performance die so viel schlechter ist ...

Einfache Aufgabe: Setze PD2 auf "high".
Ich weiß nicht, was Du uns sagen willst, aber einen Pin bekomme ich in der Arduino-IDE deutlich einfacher hoch:

Code: Alles auswählen

void setup() {
  pinMode(8, OUTPUT);  //LED
  digitalWrite(8, HIGH);
}  

void loop() {
  // Endlosschleife
  delay(500);
}
Vermutlich kann ich mir "pinMode(8, OUTPUT);" auch noch ersparen, es wird zumindest nicht angemeckert.

Was Du dabei total vergisst: Meinem Lötkolben ist es scheißegal, ob der Heizzyklus 75,000 ms oder 75037,13 µs dauert! Meinen NiCd-Akku juckt es nicht, wenn er 845 Minuten anstatt nur 14 Stunden geladen wird.

Ich bin bestimmt nicht der Einzige hier, der so denkt - es gibt genug Anwendungen, vermutlich sogar die Masse, wo es auf die µs nicht ankommt und einfach die bequeme Entwicklungsumgebung samt zugehöriger Kinderbücher in den Vordergrund rückt.
Benutzeravatar
ferdimh
Beiträge: 9430
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Tatsächlich brauchst du MEHR Zeilen Code als in der "klassischen C-Lösung".
Der Punkt ist nicht, dass die Arduinolösung pauschal schlecht ist. Der Punkt ist, dass man die Lösung (bei gleichem Verhalten!) deutlich geschickter bauen könnte.

Das andere Problem ist, dass Menschen die Grenzen nicht sehen. Wer keinerlei technische Vorbildung hat und mit Arduino spielt, sieht die Grenzen nicht. Aber das ist die alte Leier...
Benutzeravatar
Sven
Beiträge: 4423
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

Also diese Diskussion ist ausgezeichnet dafür geeignet, Anfänger abzuschrecken...
Kainit
Beiträge: 156
Registriert: So 11. Aug 2013, 16:05
Wohnort: Thüringen

Re: Der AVR-/ARDUINO-Faden

Beitrag von Kainit »

Sven hat geschrieben:Also diese Diskussion ist ausgezeichnet dafür geeignet, Anfänger abzuschrecken...
Als einer dieser Anfänger bestätige ich das mal...

mfg
Benutzeravatar
Sven
Beiträge: 4423
Registriert: Fr 28. Jun 2013, 12:52
Wohnort: Sechsundzwanzigdreisechzehn

Re: Der AVR-/ARDUINO-Faden

Beitrag von Sven »

und genau deswegen wird diese Diskussion bitte woanders fortgeführt, sofern sie denn irgendein Ergebnis hervorbringt, z.B. einen effektiveren Arduino ;)
Ansonsten ist das nämlich allenfalls nur Anfänger abschreckendes Geschwafel.

Liebe Anfänger, die Diskussion aus den vorherigen Beiträgen ist für euch absolut irrelevant. (Ich gehe mal davon aus, dass keiner mit einem Anfängerprojekt auch nur ansatzweise in Regionen vorstößt, wo die Zugriffszeit und die Komplexität des generierten Codes kritisch werden. Da gibt es ganz andere Baustellen zwischen den Ohren, die mehr Zuwendung brauchen.)
Benutzeravatar
Bauteiltöter
Beiträge: 254
Registriert: So 11. Aug 2013, 17:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Bauteiltöter »

margau hat geschrieben:Was ich zuerst zu sagen habe: So wie ich das sehe initialisiert der Arduino, bevor er in die Hauptschleife geht, auch noch diverse Timer die er für Dinge wie Delay oder millis() braucht. Das machst man beim reinen C natürlich nicht.

Desweiteren ist der Arduino darauf ausgelegt, mit Programmiertechnisch nicht ganz so begabten Leuten zu funktionieren. Jetzt erklär du denen mal, welchen Port sie wann setzten müssen, wo im 150-seitigen Datenblatt das steht.
Nein,wie Martin schon sagte, von der Arduino-typischen Initalisierung ist nix dabei, der Code den ich rausseziert habe wird bei jedem Aufruf von digitalWrite() ausgeführt.
Wo steht wie man die Ports beschaltet? Datenblatt, Kapitel "I/O Ports". Oder, in mundgerechte Happen zerlegt, im Anfänger-Tutorial
Profipruckel hat geschrieben:
Bauteiltöter hat geschrieben:Ein großer Kritikpunkt an Arduino ist ja vor allem die Performance die so viel schlechter ist ...

Einfache Aufgabe: Setze PD2 auf "high".
Ich weiß nicht, was Du uns sagen willst, aber einen Pin bekomme ich in der Arduino-IDE deutlich einfacher hoch:

Code: Alles auswählen

void setup() {
  pinMode(8, OUTPUT);  //LED
  digitalWrite(8, HIGH);
}  

void loop() {
  // Endlosschleife
  delay(500);
}
Vermutlich kann ich mir "pinMode(8, OUTPUT);" auch noch ersparen, es wird zumindest nicht angemeckert.
Es ging mir darum herauszufinden was der Aufruf von digitalWrite() im Hintergrund bewirkt.
Und nein, pinMode() kannst du nicht weglassen... das ist vermutlich der einzige Punkt an dem die Arduino-IDE noch selber denken von dir verlangt, soll der Port Ein- oder Ausgang sein? :roll:
Der Compiler kann dich auch nicht vor allem retten, er warnt nur, wenn C-Regeln verletzt werden oder er C-Code sieht, der erfahrungsgemäß zwar legal ist, aber eigentlich nicht gewollt ist. (Klassiker wie if(a=true) oder if(bedinung);)
ferdimh hat geschrieben:Tatsächlich brauchst du MEHR Zeilen Code als in der "klassischen C-Lösung".
Der Punkt ist nicht, dass die Arduinolösung pauschal schlecht ist. Der Punkt ist, dass man die Lösung (bei gleichem Verhalten!) deutlich geschickter bauen könnte.

Das andere Problem ist, dass Menschen die Grenzen nicht sehen. Wer keinerlei technische Vorbildung hat und mit Arduino spielt, sieht die Grenzen nicht. Aber das ist die alte Leier...
Danke, das wollte ich mal aufzeigen. Mir ging es auch nicht darum, Arduino per se schlecht zu machen. Es heißt nur immer, "Arduino ist so langsam" und ich wollte das ganze mal mit Fakten untermauern.

Und um zu zeigen wie es effizient geht habe ichmal ein paar Makros gebastelt die sich genau so benutzen lassen wie digitalWrite()

Code: Alles auswählen

#include <avr/io.h>
/* spezialdefinitionen hier*/
#define LED B,1

void f1(void)
{
	digitalWrite(LED,HIGH);
}
Als Makro ausgeführt wird das ganze zu ganzen 3 ASM-Befehlen (+Funktionsrücksprung):

Code: Alles auswählen

f1:
	sbi 37-32,1
	in r24,37-32
	out 37-32,r24
	ret
Zwei der drei Befehle sind immernoch unnützer overhead (in/out), lassen sich aber bei weitem nicht so einfach vermeiden ohne an Komfort zu verlieren.
für ein digitalWrite(LED,LOW); compiliert es natürlich äquivalent in cbi...

Dazu habe ich noch passende Makros SET_OUTPUT, SET_INPUT, SET_PORT und RESET_PORT geschrieben die alle mit der Definition von LED funktionieren.
Die Verbindung zwischen Arduino-Nummern und Port-Pin-Konfiguration könnte man auch noch über ein paar Definitionen machen, z.B.
#define ARDU0 B,0
#define ARDU1 B,1
u.s.w.

Ein digitalRead() könnte man sicher auch recht einfach als Makro implementieren, das ganze hat mich jetzt vielleicht mit Beitrag schreiben 30min gekostet.
Das einzige, was meine Version anders macht: Sie überprüft nicht, ob der Benutzer den Pin vorher mit einem TImer verbunden hat (PWM-Out), das ist meiner Meinung nach aber auch... eher Überflüssig. Entweder PWM oder digitaler I/O, wenn man beides gleichzeitig an macht... nun, dann funktioniert es eben nicht richtig.

Hier der ganze Makro-Code:

Code: Alles auswählen

#include <avr/io.h>

#define digitalWritex(port, bit, state) do{PORT##port|=(state<<bit);PORT##port&=~(!state<<bit);}while(0);
#define digitalWrite(x, y) digitalWritex(x,y)

#define SET_PORTx(port, bit) 	do{PORT##port|=(1<<bit);}while(0)
#define SET_PORT(x)  SET_PORTx(x)

#define RESET_PORTx(port, bit) 	do{PORT##port&=~(1<<bit);}while(0)
#define RESET_PORT(x)  RESET_PORTx(x)

#define SET_OUTPUTx(port, bit) do{DDR##port|=(1<<bit);}while(0)
#define SET_OUTPUT(x) SET_OUTPUTx(x)

#define SET_INPUTx(port, bit) do{DDR##port&=~(1<<bit);}while(0)
#define SET_INPUT(x) SET_INPUTx(x)

#define HIGH 1
#define LOW 0

#define LED B,1

void f1(void)
{
	digitalWrite(LED,HIGH);
}
Nicht von der komischen Makro-Syntax verschrecken lassen, davon würde man ja nichts sehen wenn man es in eine header-Datei auslagert und einfach nur benutzt. SO könnte es gehen bei gleichem Konfort und mit 25x weniger Code (zur Laufzeit).

Ich poste das hier weil ich mich direkt auf Antworten beziehe und das auch mein letzter Beitrag zu dem Thema wird (es sei denn, es kommen Rückfragen).
Benutzeravatar
Harley
Beiträge: 1161
Registriert: So 11. Aug 2013, 21:16
Wohnort: Regensburg

Re: Der AVR-/ARDUINO-Faden

Beitrag von Harley »

Hi,
an alle Anfänger:

Lasst euch nicht bange machen! Fürs Erste reicht, denke ich dieses Heft (6,99€):

Bild->zoom

Es ist völlig ausreichend, nur das Heft zu kaufen, die Hardware bekommt man beim China-Mann billiger!

z.b. http://www.ebay.de/itm/Mega-2560-R3-REV ... SwoudW2Xmu

Ich habe mir das Board auch gekauft, es funktioniert einwandfrei, ich verwende es für alle Versuche...
Das Ding lohnt sich, weil man erstens jede Menge Speicherplatz hat, ausserdem hat das Teil 4 echte serielle Schnittstellen.
Da ist die serielle nicht mit dem Programmierport belegt, d.h. man kann Debug-Ausgaben über USB direkt in der Programmierumgebung machen und trotzdem die serielle Schnittstelle testen.

z.B. damit:

http://www.ebay.de/itm/New-2-4-Nextion- ... SwnipWVur0

Ich denke, damit gehts mit dem Einstieg ganz schnell!!

Gruß, Harley

EDIT: ganz vergessen: dafür gibts natürlich schon eine LIB: https://github.com/itead/ITEADLIB_Arduino_Nextion
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Profipruckel hat geschrieben:Ich weiß nicht, was Du uns sagen willst, aber einen Pin bekomme ich in der Arduino-IDE deutlich einfacher hoch:

Code: Alles auswählen

void setup() {
  pinMode(8, OUTPUT);  //LED
  digitalWrite(8, HIGH);
}  

void loop() {
  // Endlosschleife
  delay(500);
}
Vermutlich kann ich mir "pinMode(8, OUTPUT);" auch noch ersparen, es wird zumindest nicht angemeckert.
Bauteiltöter hat geschrieben:Und nein, pinMode() kannst du nicht weglassen... das ist vermutlich der einzige Punkt an dem die Arduino-IDE noch selber denken von dir verlangt, soll der Port Ein- oder Ausgang sein? :roll:
Der Compiler kann dich auch nicht vor allem retten, er warnt nur, wenn C-Regeln verletzt werden oder er C-Code sieht, der erfahrungsgemäß zwar legal ist, aber eigentlich nicht gewollt ist. (Klassiker wie if(a=true) oder if(bedinung);)
Generell ist es eine gute Idee, alle Ein- und Ausgänge zu definieren und mit Namen zu versehen, ich mache das so.

Ich habe gelesen: Das Arduino-Kochbuch von O'Reilly sagt, dass beim Arduino erstmal alle Pins Eingänge sind und verzichtet in Programmbeispielen darauf, Inputs zu definieren. Schreibt man auf einen Input "HIGH", wird damit der interne Pullup-Widerstand aktiviert - eine nette Falle für den Bastler.

Damit ist klar, weshalb die IDE das nicht anmeckert.

Wenn Du sagst "noch selber denken von dir verlangt", na ja, oft genug muß ich mir denken, was so manche Fehlermeldungen mir wirklich sagen wollen :-)
Benutzeravatar
Hightech
Beiträge: 11500
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Ich bin eigentlich gegen die Adruiono Boards, da ist zu viel Geraffel drauf was man nicht braucht, schon gar nicht am Anfang wenn man was lernen möchte.
Da empfehle ich dringend, sich einen ATMEGA88 auf ein Steckbrett zu stecken und da dann einen ISP-Adapter mit drauf zu häkeln.
5V drauf und fertig.

Den RS232-ISP Adapter frickelt man sich schnell zusammen:
https://www.mikrocontroller.net/article ... rcon2m.png
Dann kann man mit Ponyprog den AVR programmieren, Ponyprog macht auch die Fuses.
https://www.mikrocontroller.net/article ... seriell.3F

Entweder macht man es mit Microsoft, dazu braucht man WINAVR
https://www.mikrocontroller.net/article ... mit_AVRISP
Das Studio braucht man NICHT.

Man will ja eigentlich nur eine programm.c schreiben und die dann zu einer hex Datei umwandeln.

Oder unter Linux braucht man
avr-gcc 4.3.3

Hier mal einlesen:
https://www.mikrocontroller.net/article ... C-Tutorial
Da sind auch die grundsätzlichen C Sachen drinnen.

AVR-LibC 1.6.7
avr-binutils
avrdude
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Harley hat geschrieben:Hi, an alle Anfänger:
Lasst euch nicht bange machen! Fürs Erste reicht, denke ich dieses Heft (6,99€):

[Bild c't Make]

Es ist völlig ausreichend, nur das Heft zu kaufen, die Hardware bekommt man beim China-Mann billiger!
Wäre das Heft Anfang 2015 erschienen, hätte ich es vermutlich gekauft. Jetzt brauche ich es nicht mehr, habe zwei China-UNOs beim Ali geordert und ein paar Schulscripte aus dem Inernet abgearbeitet. Etwas Sucherei fördert auch richtige Bücher als .pdf zu Tage.

Für wirkliche Anfänger finde ich das Heft einschließlich einem originalen Uno für 24,95 € incl. Versandkosten als im Preis durchaus angemessen. Wenn es dann wirklich der Uno mit dem grossen DIL-IC ist, wie abgebildet, sowieso. Quer über diverse Foren scheitern etliche Leute am USB-Treiber für die Chinesenboards, Schaltbilder der Chinesen habe ich bislang auch nicht aufgetrieben.

Ich sehe den Uno eh nur zum Üben, für reale Projekte ist der mir mechanisch viel zu groß.
Profipruckel
Beiträge: 1506
Registriert: Di 13. Aug 2013, 19:10
Wohnort: Niedersachsen Süd-Ost

Re: Der AVR-/ARDUINO-Faden

Beitrag von Profipruckel »

Hightech hat geschrieben:Ich bin eigentlich gegen die Adruiono Boards, da ist zu viel Geraffel drauf was man nicht braucht, schon gar nicht am Anfang wenn man was lernen möchte.
Protest - Ich lerne nicht um des Lernes willen, ich habe eine Anwendung und will die zügig lösen.

Uno aus der Tüte ziehen, 5 LEDs dranlöten. Die IDE auf dem PC auspacken, den USB-Treiber suchen ... nach insgesamt 2 Stunden hatte ich ein Lauflicht, ohne zuvor jemals einen ATMega angefasst zu haben.
Da empfehle ich dringend, sich einen ATMEGA88 auf ein Steckbrett zu stecken und da dann einen ISP-Adapter mit drauf zu häkeln.
Bei Preisen um 2 €uro für einen kompletten Chinuino vergeht mir die Lust, Quarz und Kleinkram ans blanke IC zu löten! Solange Strom aus der Steckdose kommt, kann ich mir auch die 35 mA Stromaufnahme des kompletten nano leisten. Gegenwärtig könnte mich nur der Wunsch nach Batteriebetrieb zum blanken Controller-IC treiben, was dann aber auch einen tieferen Einstieg in dessen Programmierung nach sich ziehen würde.

Einen USB-ISP-Adapter habe ich beim ALI gekauft, mit U$D 4,95 schon fast das Luxusmodell. Spielt einwandfrei, ich habe aber ziemlich lange gesucht, welcher Windows-Treiber zu dem Ding passt und wie der Anschluß belegt ist - Dokumentation kennen die Chinesen nicht.
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Hallo,
inzwischen habe ich ein LCD Keyoad Shield erworworben und nun folgende Fragen:

Ich habe es auf den Mega 2560 gesteckt und einen Sketch kopiert und damit versucht einen Test zu starten.
Fehlanzeige, wer kann mir einen passenden Sketch dafür empfehlen.
Dann geht das Display nach dem Einstecken nach gut 5 Sekunden aus, normal???

Danke und ich glaube doch zu alt zu sein für diese Teile. :D :D :D
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Hast Du die zum LCD-Shield passende Lib eingebunden?
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Heaterman hat geschrieben:Hast Du die zum LCD-Shield passende Lib eingebunden?
Nein, wo finde ich diese?

Danke
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Da müsste man wissen, wie das Shield heißt und wo es her ist.

ich hab allein drei verschiedene Display-Shields hier im Einsatz.
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Heaterman hat geschrieben:Da müsste man wissen, wie das Shield heißt und wo es her ist.

ich hab allein drei verschiedene Display-Shields hier im Einsatz.
Dieses Teil aus Asien...!!!
1602 LCD Board Keypad Shield Blue Backlight For Arduino with UART Interface
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Das hier?

Bild


Das ist ein normales LC-Display mit 4-Bit-Ansteuerung. Da lädst Du Dir in der IDE unter „Sketch” und „Bibliothek einbinden” die Lib „LiquidCrystal”

Das sieht dann am Programmanfang so aus:

#include <LiquidCrystal.h>

Hier ein Tutorial für die Ansteuerung:

http://funduino.de/index.php/3-programm ... cd-display
Benutzeravatar
BMS
Beiträge: 220
Registriert: Di 13. Aug 2013, 10:56

Re: Der AVR-/ARDUINO-Faden

Beitrag von BMS »

Dann geht das Display nach dem Einstecken nach gut 5 Sekunden aus, normal???
Die Displaybeleuchtung kann einige zig mA ziehen, und der kleine Spannungsregler auf dem Board ist ganz schnell an seiner thermischen Grenze.
Kühlkörper ist vom Entwickler ja keiner eingeplant worden. Bei 12V am Eingang (bei geringerer Eingangsspannung sieht es besser aus) ist der Regler bei etwa 130mA an der thermischen Grenze. Diese Diskussion hatten wir schon vor kurzem:
http://www.fingers-welt.de/phpBB/viewto ... =14&t=5840

Grüße, Bernhard
Benutzeravatar
Daniel
Beiträge: 859
Registriert: Mi 14. Aug 2013, 21:43
Wohnort: NRW

Re: Der AVR-/ARDUINO-Faden

Beitrag von Daniel »

Heaterman hat geschrieben:Das hier?

Bild


Das ist ein normales LC-Display mit 4-Bit-Ansteuerung. Da lädst Du Dir in der IDE unter „Sketch” und „Bibliothek einbinden” die Lib „LiquidCrystal”

Das sieht dann am Programmanfang so aus:

#include <LiquidCrystal.h>

Hier ein Tutorial für die Ansteuerung:

http://funduino.de/index.php/3-programm ... cd-display
Das in 13 beschriebene Display läuft doch bei mir schon lange.
Es geht um das Keypadshield!!!
Benutzeravatar
Heaterman
Beiträge: 3990
Registriert: Fr 28. Jun 2013, 10:11
Wohnort: Am Rand der Scheibe, 6 m unter NN

Re: Der AVR-/ARDUINO-Faden

Beitrag von Heaterman »

Seh gerade, das Bild wurde nicht gezeigt.

Also das hier?

http://www.sainsmart.com/sainsmart-1602 ... a1280.html

Da ist auch ein Codebeispiel zu finden.

Wenn ich die Beschriftung richtig entziffere, ist das Display ganz normal im 4-Bit-Modus angeschlossen.
Benutzeravatar
Hightech
Beiträge: 11500
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Profipruckel hat geschrieben:Bei Preisen um 2 €uro für einen kompletten Chinuino vergeht mir die Lust, Quarz und Kleinkram ans blanke IC zu löten!
Man braucht 5V und einen AtMega oder Tiny. sonst nix. Keinen Quarz oder so, wofür auch.
Nur den Progammierer, und den kann man sich aus der Restekiste zusammenlöten.

Fertig kaufen kann jeder.

Für 2 Euro kaufen: gibt keinen Kenntnisgewinn.


Hier Beispielprogramm LED an/aus

Code: Alles auswählen

//Beispiel.c

#include <io.h> //Bindet die Anschlüsse PINs usw ein
#include <util/delay.h> //Bindet die Verzögerungsfunktion ein

#define F_CPU 8000000 //8Mhz RC Oszillatorfrquenz für die delay.h zur Berechnung

int main(void)     //Hauptprogramm
{
DDRB|=(1<<PB0); //Schaltet Pin B 0 auf Ausgang

while(1)  //Mach ne Schleife solgange 1 gleich 1 ist, also für immer ;)
{
_delay_ms(1000); //Sekunde Pause
PORTB|=(1<<PB0); //Port B Pin 0 an
_delay_ms(1000); //Sekunde Pause
PORTB&=~(1<<PB0); //Port B Pin 0 aus
} //Ende While Schleife
}//Ende main
das Übersetzt man mit avr-gcc und brennt es mit avrdude in den Atmel
Benutzeravatar
Zabex
Beiträge: 633
Registriert: Di 2. Jul 2013, 08:45
Wohnort: Aldenhoven
Kontaktdaten:

Re: Der AVR-/ARDUINO-Faden

Beitrag von Zabex »

Für 2€ kaufen kann einen grossen Erkenntnis Gewinn bringen. Ich selbst beherrsche die Atmel Familie auf C und Assembler Ebene. Und als Arduino. Letzteren verwende ich immer mehr.
Was ich inzwischen gelernt habe: Als Fachmann kann msn sich gar nicht mehr vorstellen, wie schwierig eine simple Programmierlösung für einen Anfänger ist. Hätte ich meiner Tochter erklären müssen wie man einen ATmega 328 mittels ISP flashed und mittels Portbefehlen den Pegel von Ausgangsleitungen setzen kann, dann würde sie bis heute Programmierjungfrau sein. Mit dem billigen Arduino und der doofen IDE hatte sie nach wenigen Minuten ihr Erfolgserlebnis. Es war ihr sicherlich total egal, was da im einzelnen vom Prozessor veranstaltet wurde. Hauptsache, die LEDs flimmern wie gewünscht.
Für mich ist der Arduino zum programmieren wie die Dachlatte zum Möbel bauen. Erklärung: Angenommen, ich brauche für eine Feier einen zusätzlichen Tisch. Da er in der Höhe genau zum bestehenden passen soll, will ich den bauen. Positiv: ich will ihn nicht fertig kaufen. Jetzt könnte ich mir 4 Beine drechseln, einen Rahmen keilverzinken und eine Leimholzplatte drauf dübeln. Nach allen Regeln der Tischlerzunft. Oder ich nehme Item-Profile, schraub damit ein Gestell zusammen und lege eine Siebdruckplatte drauf. Oder ich nehm ein paar Dachlatten, spax die zu einem Gestell zusammen und schraub mit ein paar Winkeln eine Spanplatte drauf. Vom gesparten Geld hole ich eine hochwertige Tischdecke.
Alle drei Lösungen ergeben einen Tisch, an dem man prima feiern kann. Jede Lösung braucht ein deutlich unterschiedliches handwerkliches Geschick, ist aber eine Lösung. Ich verstehe, dass jeder Tischler und jeder VielGeldBesitzer nur die erste Lösung akzeptieren möchte. Aber was ist an dem Dachlattentisch denn wirklich so schlecht? Man hat geringe Investitionskosten und ein schnelles und sicheres Erfolgserlebnis. Und genau da sehe ich den Arduino. Der kann einfach Spaß machen, weil er ziemlich simpel und ziemlich billig ist.
Morgen werde ich vier OneWire Temperaturfühler mittels ATmega an ein LC Display häkeln. Klar: das lass ich einen Arduino-Nano machen. OneWire, Dallas TemperaturLib und Lcd-Lib includiert, zwei handvoll Zeilen Code und fertig. Im wesentlichen zusammenkopiert aus den mitgelieferten Beispielen. Ohne einmal in die 600Seiten Prozessorhandbuch zu blicken und mich mit den ganzen Registern rumzuschlagen. Der Prozessor muss wahrscheinlich zehn mal so viel machen, als wenn ich das von Hand unter Ausnutzung der Hardwaremöglichkeiten codiert hätte. Für die Aufgabe ist das aber total egal.
Und:ich kann es hinterher jemandem recht einfach erklären.
Am Wochenende bin ich auf der Make in Dortmund. Ich freue mich schon auf das ganze kreative Geraffel das von Programmieranfängern mittels Arduino gesteuert wird.

Gruß,
Zabex
Name vergessen
Beiträge: 3261
Registriert: Mo 12. Aug 2013, 19:47

Re: Der AVR-/ARDUINO-Faden

Beitrag von Name vergessen »

Zabex hat geschrieben:Hätte ich meiner Tochter erklären müssen wie man einen ATmega 328 mittels ISP flashed und mittels Portbefehlen den Pegel von Ausgangsleitungen setzen kann
Nicht zu vergessen, daß sie zuerst den ISP-Adapter hätte bauen, dann avr-gcc und avrdude installieren und konfigurieren sowie die Befehlszeilensyntax herausbekommen müssen. Und wenn man noch nie vorher gelötet hat, ist das erstmal schon ein Problem, während Steckbretter durch ihre Unzuverlässigkeit gleich viel Frustpotential bergen. Das Viech hat seine Daseinsberechtigung, es räumt schonmal eine Menge Fehlerquellen aus dem Weg und spart auch eine Menge Zeit. Und wenn man dranbleibt, kommt das Datenblattlesen und avr-gcc irgerndwann von selber. Aber ich bin auch für den Vergleich des erzeugten Codes dankbar, denn das ist eine belastbarere Analyse als das eigene Bauchgefühl. :)
Benutzeravatar
Hightech
Beiträge: 11500
Registriert: So 11. Aug 2013, 18:37

Re: Der AVR-/ARDUINO-Faden

Beitrag von Hightech »

Keine Frage! Der Adruino ist DAS Einsteigerteil für Nichtlötkolbenhalterwindowsnutzer für einen leichten Einstieg.
Ebenso kann man als erfahrener Assembler die Teile nutzen um schnell das gewünschte Ergebiss zu erziehlen.

Die Kollegen hier im Forum sind aber keine kleinen Töchter mehr und können sich in 10Minuten einen ISP Adapter zusammenlöten.

ICH würde nicht mit der Adruino-IDE und der verknubbelten Sprache anfangen, wenn ICH mich erstmal an so was gewöhnt habe fällt es mir sehr schwer
zu z.B. C zu wechseln.
Wenn man dann doch mal an die Register will oder muss, ist es schwierig dann auf eine Ebene tiefer zu gehen.
Und man muss C für die einfachen Sachen mit dem Atmel nicht vollständig lernen.
Hier muss man nur mal an die Hand genommen werden für die grundsätzlichen Dinge, wie man sein Programm in den Chip bekommt.
Der Rest findet sich durch versuchen und im Internet.

Ich mag nicht zu weit von der Hardware weg gehen wie es der Adruino tut.
Lieber überlege ich mir, ob im Register TCCRA1 besser CS00 oder CS01 steht.

Das sollte man in der Lage sein, dann kann man auch mit wenigen Handgriffen einen anderen Chip nehmen, z.B. wenn das Programm eigentlich für einen Tiny ist kann man es für einen Mega88 umschreiben.
Benutzeravatar
ferdimh
Beiträge: 9430
Registriert: Fr 16. Aug 2013, 15:19

Re: Der AVR-/ARDUINO-Faden

Beitrag von ferdimh »

Tatsächlich halte ich die Arduino-"Sprache" für eine sehr gute Idee. Sie ist nämlich ausreichend nah an C dran, dass man im Prinzip schonmal die Syntax lernt.
Das Setup/Loop-Konzept bringt einen "nebenbei" auch noch auf einen sehr guten Weg ein Mikrocontrollerprogramm zu schreiben. Leider ist hier ein Detail danebengegangen: Wenn diese Schleife noch timergesteuert wäre, wäre es noch schöner.
Ein Problem entsteht halt, wenn die Projekte komplexer werden und man krampfhaft am Arduino festhält und dann anfängt sich um die Arduinokonstrukte rumzuwürgen, weil sie zu langsam sind. Ein weiteres Problem entsteht, wenn die idiologische Diskussion losgeht.
Leider wird diese von beiden Seiten nicht sehr konstruktiv geführt. Ich habe in meinen Programmen immer SET_PIN und GET_PIN Makros. Ich habe Funktionen, um Timer automatisch passend zu initialisieren. Warum hat die AVR-Libc das nicht, so dass dieses (nicht unerhebliche) Stück Vereinfachung exklusiv den Arduinos zufällt?
Statt die Lücke kleiner zu machen rantet man lieber...
Antworten