*.pde to *.hex?

For Adafruit customers who seek help with microcontrollers

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
dragonuv
 
Posts: 235
Joined: Tue Dec 04, 2007 1:22 pm

*.pde to *.hex?

Post by dragonuv »

Hi, Ive made a simple program using the Arduino envoronment which basically says :

Code: Select all

void setup() 
{
  pinMode(2, INPUT);
  digitalWrite(2, HIGH);
}

void loop() 
{

}
Is there a way of converting this pde file to hex so i can upload it to my attiny2313?
Thanks.

mtbf0
 
Posts: 1645
Joined: Sat Nov 10, 2007 12:59 am

Re: *.pde to *.hex?

Post by mtbf0 »

nope. the arduino libraries are not built for the attiny2313 and, in fact would not build for it. which pin, for instance, would digital pin 2 be on a t2313?

the following, were you to compile and link it, would do pretty much what you want. PORTB pin 2, if i recall correctly, is pin 13 on the t2313.

Code: Select all

#include <avr/io.h>

void setup (void) {
  DDRB = (1 << PB2);
}

int main (void) {
  PORTB |= (1 << PB2);
}
you would need isp programmer such as the usbtiny to upload the code to the t2313. unless it's already installed in a minipov3.

dragonuv
 
Posts: 235
Joined: Tue Dec 04, 2007 1:22 pm

Re: *.pde to *.hex?

Post by dragonuv »

I already got the usbtinyisp, but i still need the hex file. what compiler do i need in order to convert your code to a hex file?

mtbf0
 
Posts: 1645
Joined: Sat Nov 10, 2007 12:59 am

Re: *.pde to *.hex?

Post by mtbf0 »

you need avr-gcc, avr-binutils, avr-libc, avrdude, make and cygwin all of which are used by the arduino environment, so you've got them already.

a t2313 fresh from the factory will be set up to run at 1MHz. it can be configured to run at 8MHz without an external clock source or at up to 10MHz or 20MHz, (depending on the chip you bought), with an external clock source. to turn on an led and leave it on 1MHz will suffice.

oops. gotta jet. i'll finish this later...

mtbf0
 
Posts: 1645
Joined: Sat Nov 10, 2007 12:59 am

Re: *.pde to *.hex?

Post by mtbf0 »

hmmm. the easiest thing to do would be grab the miniov3 firmware download. it has several examples of working tiny2313 code and a makefile to run the compiler, avr-objcopy nd avrdude. just hook up some leds at pins 11-14 or something, then make a couple of changes to the file called Makefile to get it to use the usbtiny,

these are the original first four lines

Code: Select all

MCU = attiny2313
F_CPU = 8000000         # 8 MHz
AVRDUDE_PORT = /dev/ttyUSB0     # programmer connected to serial
AVRDUDE_PROGRAMMER = dasa
change them to

Code: Select all

MCU = attiny2313
F_CPU = 8000000         # 8 MHz
AVRDUDE_PROGRAMMER = usbtiny
have a look at some of the .c files in the directory. you will notice that they bear very little resemblance to arduino programs. this is real c without all the arduino helper functions and it's what you will have to learn how to write. you will also need to download a copy of the attiny2313 datasheet. it will tell you what the chip can do and how to get it to do it. this involves writing a lot of arcane values to a lot of special function registers. it is not particularly difficult, but you have to learn to look things up in the datasheet.

try this to compile the minipov code and upload it to your t2313

Code: Select all

make program-minipov
you ought to see whatever leds you connected to portb start to flash. the chip will be running at 1MHz and the code is written to run at 8MHz. to speed the chip up

Code: Select all

make burn-fuse
now create a file called foo.c and put the following code into it

Code: Select all

#include <avr/io.h>

void setup (void) {
  DDRB |= (1 << PB2);
}

int main (void) {
  PORTB |= (1 << PB2);
  while (1);
}
to compile and link this code type

Code: Select all

make foo.hex
to upload it to the 2313 type

Code: Select all

avrdude -c usbtiny -p t2313 -U flash:w:foo.hex
avrfreaks is an excellent resource.

neutered
 
Posts: 43
Joined: Wed Dec 03, 2008 3:21 pm

Re: *.pde to *.hex?

Post by neutered »

dragonuv wrote:Is there a way of converting this pde file to hex so i can upload it to my attiny2313?
Thanks.
other people have answered the big part, but one thing i think is missing is that the arduino environment expects a bootloader to be runnig on the target. the pde is really just a c++ file compiled/linked so that it can be loaded at 0x0000 and jumped to by the bootloader.

anyway, you can get the support libraries built for whatever chip, but it might take a little coaxing. if you grab the environment's source you'll find a 'template' in hardware/cores/blank, but it might be easier to copy one of the existing ones and modify it to taste/needs.

mtbf0
 
Posts: 1645
Joined: Sat Nov 10, 2007 12:59 am

Re: *.pde to *.hex?

Post by mtbf0 »

neutered wrote:anyway, you can get the support libraries built for whatever chip, but it might take a little coaxing. if you grab the environment's source you'll find a 'template' in hardware/cores/blank, but it might be easier to copy one of the existing ones and modify it to taste/needs.
i think "a little coaxing" is a slight understatement here.

register and bit names are different between the two chips. capabilities are certainly different. and the 128 bytes of sram on the tiny2313 is almost certain to make this a no go.

i have written code that compiles for both the tiny2313 and the atmega168 using avr-gcc and that will also build in the arduino environment, so i'm not saying it's impossible, but i only used one timer to control two pwm channels and stayed away from almost all of the arduino functions. no pinMode, no digitalWrite, no analogWrite.

by the time you'd learned enough to coax, (shoehorn might be more approriate), the arduino code onto a tiny2313, you'd know enough about both the mega168 and the tiny2313 that you'd be able to program both of them in straight c and would understand that that is a much more efficient approach than using the arduino functions.

dragonuv
 
Posts: 235
Joined: Tue Dec 04, 2007 1:22 pm

Re: *.pde to *.hex?

Post by dragonuv »

this is so complicated... i just thougt there is a compiler that can convert pde to hex so i can run the line:

avrdude -c usbtiny -p ... -U flash:w:program.hex

mtbf0
 
Posts: 1645
Joined: Sat Nov 10, 2007 12:59 am

Re: *.pde to *.hex?

Post by mtbf0 »

dragonuv wrote:this is so complicated... i just thougt there is a compiler that can convert pde to hex
a pde file is not quite a c++ program. the arduino environment must tweek it a little to make it compilable by avr-gcc. once compiled it will only run on an atmegax8 or an atmega8 chip, because there are parts of the code that are specific to these chips.

if you wish to write code for other avr chips, you'll have to learn a little c and you'll have to learn to read a datasheet.

what the arduino environment does is shield you from the details revealed in the data sheet, but the stuff is not rocket science.

pin 2 on an arduino board is actually in 2 of i/o port D. in order to make it an output you have to set the appropriate pin in port D's data direction register. in your arduino you do this with the call, (hey, just noticed that in your example you set the pin to be an input, then use it as an output.)

Code: Select all

  pinMode (2, OUTPUT);
this compiles to a call to a function that figures out which pin of which port you want and sets the correct bit of the appropriate data direction register for you. it's not a terribly efficient approach, but it shields you from having to understand the details.

to do the same thing in c, takes 1/16000000 of a second, requires a single word of program memory and looks like this

Code: Select all

  DDRD |= (1 << PD2);
not that hard, just a tad arcane looking. to set that pin high you would use

Code: Select all

PORTD |= (1 << PD2);
to set it low

Code: Select all

  PORTD &= ^(1 << PD2);
again, the arduino code introduces inefficiencies in the usage of both cpu cycles and program storage. this is much more critical on a small device like a tiny2313 with 2k of program space and 128 bytes of sram and running at 1MHz or 8MHz than it is on a mega168 running at 16MHz with 16k of program space and 1k of sram.

jeez, i'm even starting to bore myself...
Last edited by mtbf0 on Wed Jun 03, 2009 1:14 pm, edited 1 time in total.

User avatar
westfw
 
Posts: 2010
Joined: Fri Apr 27, 2007 1:01 pm

Re: *.pde to *.hex?

Post by westfw »

this is so complicated.
Yep. This is the sort of of "complexity" that the Arduino environment specifically tries to avoid (successfully, IMO.) The arduino install includes all the bits and pieces you need to write C programs (or C++ programs) for other Atmel AVR CPUs, but it will get "complicated", relatively speaking. (starting with needing to give up your GUI and start working in a command-line based environment.)

Now, if you're willing to pay the dollar or two extra, you CAN have the arduino environment load up an ATmega8 chip instead, with a lot fewer complications.

dragonuv
 
Posts: 235
Joined: Tue Dec 04, 2007 1:22 pm

Re: *.pde to *.hex?

Post by dragonuv »

great :) it works, i used a program that turns on and off the portb pins. so i guess the makefile looks for a *.c file in the same folder. What if i tried to program using assembly? what file would i need to use for that?

and how do i use the equivalent command of Delay(int) in usbtiny?

thanks.

User avatar
macegr
 
Posts: 293
Joined: Fri Apr 04, 2008 4:46 pm

Re: *.pde to *.hex?

Post by macegr »

If you're going to develop for a lot of chips not supported by the Arduino environment, it's worthwhile to just download AVR Studio and WinAVR. That will let you develop projects for any Atmel microcontroller, in GCC or assembly, or both.

User avatar
westfw
 
Posts: 2010
Joined: Fri Apr 27, 2007 1:01 pm

Re: *.pde to *.hex?

Post by westfw »

how do i use the equivalent command of Delay(int) in usbtiny?

Code: Select all

/* At start of program */
#include <util/delay.h>

/* In your actual code */
main() {
/*  :    */
   _delay_ms(1000.0);
/*  :    */
}
Note that the argument to _delay_ms() is a floating point number. If you use the correct compiler optimization switches, all the floating point disappears before actual code is generated, and everything is cool. If you DON'T, it will suck in lots of floating point libraries and the resulting delays will be "much longer than expected and basically unpredictable." I think this was done intentionally because otherwise it wouldn't have been complicated enough.

Note that implementation-wise, this is quite a bit different than the arduino delay() function, which uses one of the cpu timers, interrupts, and its own set of complicated math (all happily hidden where the user isn't bothered so much.) _delay_ms() just generates a busy-loop designed to eat up a specific number of CPU cycles. I don't think this will matter for your application, though.

dragonuv
 
Posts: 235
Joined: Tue Dec 04, 2007 1:22 pm

Re: *.pde to *.hex?

Post by dragonuv »

westfw wrote: Note that the argument to _delay_ms() is a floating point number. If you use the correct compiler optimization switches, all the floating point disappears before actual code is generated, and everything is cool. If you DON'T, it will suck in lots of floating point libraries and the resulting delays will be "much longer than expected and basically unpredictable." I think this was done intentionally because otherwise it wouldn't have been complicated enough.

Note that implementation-wise, this is quite a bit different than the arduino delay() function, which uses one of the cpu timers, interrupts, and its own set of complicated math (all happily hidden where the user isn't bothered so much.) _delay_ms() just generates a busy-loop designed to eat up a specific number of CPU cycles. I don't think this will matter for your application, though.
thank you very much, will that command take much memory? because i tried to copy-paste some kind of command and because it was a lot of lines it didnt have much memory in the end.

User avatar
westfw
 
Posts: 2010
Joined: Fri Apr 27, 2007 1:01 pm

Re: *.pde to *.hex?

Post by westfw »

_delay_ms() should result in relatively small code, but it's inline for each time you use it, so if you have "many" delays of a particular time:

Code: Select all

main()
{
  _delay_ms(1000.0);
    :
  _delay_ms(1000.0);
    :
  _delay_ms(1000.0);
    :
}
then it would be smaller to create a subroutine:

Code: Select all

void delay_onesec()
{
  _delay_ms(1000.0);
}
main()
{
  delay_onesec();
   :
  delay_onesec();
   :
  delay_onesec();
   :
}
Other than that, you'll just have to try it out and see if it fits...

Locked
Please be positive and constructive with your questions and comments.

Return to “Microcontrollers”