I recently bought a couple of ATtiny85 chips and have been using my Arduino UNO as an ISP Programmer to flash them from the Arduino IDE.
Now I want ot flash some code made in Ateml Studio onto the chip.
I tried C:\>avrdude -c arduino -p attiny85 -P com9 -U flash:w:/path/to/code.hex:i, however it will allways tell me that it expected another device signature and fails when it tries to verify the code on the board after uploading it.
As suggested by a fried, I tried -b 19200 -c avrisp -F -V, but it will still not run the code after uploading the file.
Is there a way to find out which command the arduino IDE executes when I press the play button, since it works perfectly this way.
I hate to post an external URL as my main answer, but the process is a bit involved. First you need to hook up everything just right, put a crystal on the 85 chip, etc, get it breadboarded, then you have a starting point
Try the procedure outlined here.
Related
I have firmware installed on an Arduino DUE from a different mac, it is designed to interface with a Matlab-based application. It has been tested and known to work. I am attempting to modify the firmware from the mac in my office, but I ran into a snag after installing the Arduino IDE.
First, I cannot get the Arduino Serial Monitor to interact with the DUE. I have tried multiple times, it worked once but I have not managed to make it work since. No errors are reported.
Second, I cannot get the screen terminal command to interact with the DUE either. No errors are reported.
Third, if I simply use text pipes in the terminal (e.g., echo 'status' > /dev/cu.usbmodem1421 or head -20 /dev/cu.usbmodem1421 &) I get appropriate responses from the DUE.
Fourth, the Matlab application can interact with the DUE just as designed.
Note that this is the native USB port in the DUE, no serial adapters (with their driver weirdnesses) are involved. I have not tried to download new code to the DUE as the firmware works as it is as long as we use macs (it is just that I need to modify it so that it can work with the much-slower ports in a Windows PC).
I need to be able to debug the code I am modifying, and for that I need to be able to interact via a terminal, any terminal. Any ideas of where to look?
UPDATE: I noticed that the code was not waiting for USB to be ready. So I added
while(!WiredSerial){
digitalWrite(PIN_LED, HIGH);
delay(125);
digitalWrite(PIN_LED, LOW);
delay(125);
}
After this change the DUE waits for the terminal to be opened and the terminals display the initialization text without a hitch. After that the behavior is the same as reported before.
Never mind.
I was certain that I had already checked this before posting. As a matter of fact, I am sure that it is the first thing I checked, something else must have changed in the interim.
The code was expecting a newline character before it sent anything back while the terminals were just sending a carriage return.
I'm working on a project where I need to program an NRF51822 using an ST-Link V2 (well, perhaps I don't have to do it this way, but that's what I'm currently doing/own).
I'm pretty sure it's running properly, but I really need a debug console to get some information back from the NRF51 module to make sure things are connected OK.
I'm not going to lie:
I'm really quite new to this, and most of my success thus far has been thanks to quite in-depth tutorials.
I'm using ubuntu and openOCD for programming
I'm not sure what I need to put in my program in order to get debug/console info out (and I'm not even sure what I would do to receive it on my computer).
I would really appreciate some help on:
What to add to my program to log info to the console, and
How to view that debug console on my computer.
Thank you very much!
You need to use such OpenOCD config file to connect with ST-Link
#nRF51822 Target
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
set WORKAREASIZE 0x4000
source [find target/nrf51.cfg]
You need to insert your version stlink-v2-1.cfg or stlink-v2.cfg
Also you need to add this to your makefile to write program
flash: $(OUTPUT_BINARY_DIRECTORY)/$(HEX)
$(OPENOCD) -d2 -f $(TEMPLATEROOT)/openocd.cfg -c 'init_reset halt; program $(OUTPUT_BINARY_DIRECTORY)/$(HEX) verify; reset; exit'
Debug is more complex. You'd better set eclipse with OpenOCD/GDB to make it. For console solution you can follow this lesson
This worked for me. Good luck.
I would like to make an Windows application that receives an .hex file and than it uploads to an AVR microcontroller (in my case ATmega88p) via a programmer (like Pocket AVR Programmer or similar) .
I need to be able to send a new .hex file to the application but the application should not be able to change the .hex. Does something like that already exist?
I searched if visual studio has any library to send data to an microcontroller but I did not find any useful hint.
Thank you for your time.
EDIT:
As suggested my problem using different words:
I want an standalone application that is able to send .hex data via a simple programmer to a microcontroller (ATmega88p).
Where should I start? I have some experience in .NET. Is it possible in Visual studio? Does something like that already exist?
avrdude is a preexisting application that is able to program to a number of AVR micro controllers through a number of different interfaces. This is a console application. While I don't have experience with Visual Studio, I imagine most IDEs are able to call a command line application with the appropriate arguments.
In this case, avrdude needs to know which chip you're using (-p), which programming interface is connected to the chip (-c), and where the hex file is (-U). In your case, you're using the ATMega88p, so you'll pass -p m88p, a pocket programmer (which is essentially a USBTiny): -Pusb -c usbtiny, and the command to write your micro controller's flash, so -U flash:w:path\to/your/file.hex
The whole command looks like this:
avrdude -Pusb -c usbtiny -p m88p -U flash:w:path\to\your\file.hex
You can learn more by reading ladyada's AVRDUDE tutorial
I am working on a project that uses the Spartan 6 FPGA eval kit.
The problem I am having is that when trying to change the directory on the CF card, the software can't build the working stack.
The directory is "a:\\setup" and that is being passed to the sysace_chdir(const char *path) function.
When I try to add some print code to debug the problem, none of the changes are registered.
In the SDK, I have the MicroblazeProc_hw_platform, then my project, then a standalone_bsp_0 project, which has the sysace_chdir() function in it.
When I build all the projects, the simple print statements (I use xil_printf() for output) do not display in the output.
Any help would be great.
PS - I am connected to the FPGA in the SDK using a COM port, and other print statements do get output during the initialization of the other things like the UARTs, so this is not a problem with output to the terminal or anything.
I think I figured out what the problem was.
I inserted my card into a USB card reader and formatted it using a FAT32 file system.
As for the cnages in the BSP, I was not able to figure that out, but the code is now able to change directory.
The wierd thing is that after the code is executed, if I pull out the CF card and insert it into my pc, I don't see the newly created directory. I don't know why.
I'm just starting out with the arduino uno and I've got a program previously loaded on which receives information from a bunch of sensors and outputs the received information through serial. So when I connect from COM3 (as on my computer) to the UNO with putty it outputs the sensors readings.
But I'm having an issue now with resetting the UNO with an empty sketch with just
void setup(){}
void loop(){}
when I upload the above it says compiled but when I connect with putty the old program seems to be still active?.
Any idea as to what is going wrong here?
Make sure you close putty before uploading as it will probably block the commication between the IDE and the Arduino.
Also check not just for compilation, but also for uploading. Use the serial from the Arduino IDE during development. The compilation process knows how to kill that, and will do that automatically.