I am writing a program in Atmel Studio 7 that I just installed and started using. I have set up the studio for Arduino and added the Atmega128 to the library of supported chips. All is good there. When I try to use the SoftwareSerial library and compile, I get an error that Atmega128 and Atmega64 do not support SoftwareSerial. Why is this? What is so different about this AVR over the atmega328, etc that it will not support the library. Is there a better approach to use SoftwareSerial or SoftUart on the atmega128? Thanks
Did you run into this compile error: This version of NewSoftSerial supports only 20, 16 and 8MHz processors?
This comes from these defines in the cpp file. It might work if you define F_CPU to be 8000000, and make sure that you actually set the register to make that the clock speed. Some processors use a slower clock speed by default. Consult the hardware manual.
Note that F_CPU needs to be defined before the NewSoftwareSerial.cpp file is processed. You can create defines right in the command line with a D switch.
#if F_CPU == 16000000
[snip]
#elif F_CPU == 8000000
[snip]
#elif F_CPU == 20000000
[snip]
#else
#error This version of NewSoftSerial supports only 20, 16 and 8MHz processors
#endif
Through my research, while using the Arduino libraries and set up, their included SoftwareSerial library does not support the atMega64 and atMega128 because of the differences in the PIN and interrupt on these chips. I have successfully set up softserial on other GPIO pins on the atMega128 by modifying this example. This example is only for transmitting. I am still working on the receive portion because it involves setting up interrupts and clocking. A key note to remember is to make sure your clock settings match throughout your project and the serial bauds are set properly. I tested my code using several different baud rates.
As a side note for beginners, I have found that testing with an Arduino is great. However, when trying to move to a custom built C project, it is extremely difficult to migrate from the Arduino project to a clean C project. In my opinion, its almost easier to just learn C and start testing within the Atmel Studio environment and stay away from Arduino. I sope this helps someone starting out with programming.
Related
I have just finished a project using an Arduino Micro dev board and want to move to a standalone ATmega32.
I need to run this at 3.3V and I dont want to go down the overclocking road so I have an 8MHz crystal to put on it.
I still want to be able to upload sketches via USB and the Arduino compiler so I gather I need to burn a different bootloader.
For this purpose I have purchased a USBASP programmer.
I am slightly unsure of what to do next - everything I can find on the topic either relates to the ATmega328 or to burning bootloaders using another Arduino.
I have worked out that I need to modify boards.txt to point to the correct bootloader....but which is the correct bootloader for ATmega32 at 8Mhz?
Also do I need to change any fuses?
Thanks
I think you're a bit out of luck.
The ATmega doesn't have hardware USB, so I assume the bootloader is using V-USB to implement USB. That stack, being a software implementation of USB's high-speed signalling, requires at least a 12 MHz clock (higher is better).
I don't think you can run V-USB using only the internal 8 MHz oscillator.
According to the OP comments the micro is indeed an Atmega32u4, not an Atmega32 (#OP: please fix the question to match this).
Since it has onboard USB, you can use a pre-existing bootloader like the sparkfun one:
https://www.sparkfun.com/products/12587
Here you have the link to one of their products, the Arduino pro micro 3.3V (which runs at 8MHz). You can add the sparkfun arduino boards repository to your IDE and then just use the board specification for their pro micro 3.3V do upload the correct bootloader and to program it through the USB just like the usual Arduino Micro.
I want to use debugger which is provided my atmel studio to walk through my program which i want to write in assembly or c but not in arduino script language.
P.S: i don't want to use visual micro because i tried it already but it doesn't go through my assembly code
The Arduino Uno exposes the RESET pin, which is all that is needed for a debug connection via debugWIRE. Alternatively, JTAG debugging requires (IIRC) the SPI and RESET pins, which are conveniently broken out via the ICSP header.
This is the same question that I've posted on the Arduino Forums, as there could be someone here who could help me :)
I'm using an Arduino Pro Micro 3.3V/8MHz from SparkFun for a project. I've installed the drivers, added support for the board on the IDE and tried uploading a sketch to it - it worked okay. I realize that the bootloader shipped with the board emulates a distinct serial port for uploading, as the normal port is COM5 and the upload port is COM6. Though for this project, code optimization is paramount, so I moved on to the Atmel Studio which I had already used successfully with the UNO. I constructed a simple blinky code for the Micro using the registers and functions:
#define ledpin PC6
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRC |= (1 << ledpin);
while(1)
{
PORTC |= (1 << ledpin);
_delay_ms(1000);
PORTC &= ~(1 << ledpin);
_delay_ms(1000);
}
}
I can upload it okay through Atmel Studio with the following command in avrdude:
C:\Program Files (x86)\Arduino\hardware/tools/avr/bin/avrdude -C"C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf" -v -v -patmega32u4 -cavr109 -P\\.\COM6 -b57600 -D -Uflash:w:"$(ProjectDir)Debug\$(ItemFileName).hex":i
To be able to do this, I have to press the reset button twice in less than 750 ms, as the hookup guide sugests (https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/troubleshooting-and-faq#ts-reset).
The code works, but now I notice that the normal serial port (COM5) never comes back. What could be the cause? I can still upload new code to the Micro, so the bootloader should be okay right?
Thanks for the help in advance :)
I have sort of found the solution. As I posted on the Arduino forums:
I was able to revert the pro micro to the state it was delivered to me by SparkFun.
To do that, I used an Arduino Uno as ISP (with the ArduinoISP example) connected to the MISO, MOSI, SCLK and RST pins of the Micro and uploaded the bootloader through the Arduino IDE. At first, I got an error that read:
avrdude: verification error, first mismatch at byte 0x0000 0xfe != 0xce
Then, I went looking into how to set the fuse bits on the Pro Micro when I realized the boards.txt specifies the fuse bits to be used. All I had to do was change the "extended_fuses=0xfe" to "extended_fuses=0xce", restart the IDE and retry the bootloader upload. At last, success!
To test it, I wrote a simple UART "Hello world" application in the IDE, which worked flawlessly.
When uploading the bootloader, make sure you have the correct board selected (SparkFun 3.3V/8MHz) and select the COM port of the ISP Arduino.
i have an PIC32MX460L512 microcontroler( Cerebot MX4 board from Digilent) and after doing some projects, i can`t program it any more.
This happend after i tested the board multipliers and dividers to see how the board works using #pragma pll ....
i can not write a new hex or change the configuration bits, and i get the following errors
PIC32 Starter Kit hardware initialization failure. Error= -1004, Detail=0x80004005, (LID:29)
or a second error
Device reset failed/ make sure Configuration Bits are correct.
I think the board still works because windows can see it in the Devices and Printers.
what ca i do? can i reset the memory from some bits? i`m still a noob with microcontrollers.
Thanks in advance
the problem was the configuration bits that i wrote earlier. i googled a little more and found that there is a file -- sk_erase.exe -- that erases the configuration bits
I have a Keil ULINK2 USB emulator box attached to the JTAG connector on my board, which is working fine with the Cortex-M3 CPU onboard (TI/Stellaris/LuminaryMicro LM3S series). It seems that both a JTAG and a SWJ-DP port share the same pins (and thus connector on your board) on these CPUs. One appears not to have ITM (printf) capability, the other does.
The previous firmware people have always used stdio to UART (serial port), but I need the serial port freed up so that debug messages do not interfere with other data being sent/received to/from the serial port, thus I need for trace messages to go elsewhere. Sadly I only have one serial port on this board. I thought that the ITM (Trace) feature in this CPU meant that I could send debug printf messages directly to my debugger/IDE (Keil uVision). The TI/Stellaris CPU documentation call this feature 'Serial Wire JTAG Debug Port (SWJ-DP)', support for which, I have read, is definitely a feature implemented in the Keil uVision IDE.
Adding a printf message to my code causes my code to lock up when I start debugging. The lockup seems to be here in the RTL libraries which are linked into my application, in the function _sys_open, at the BKPT instruction:
_sys_open:
0x00009D7A B50E PUSH {r1-r3,lr}
0x00009D7C E9CD0100 STRD r0,r1,[sp,#0]
0x00009D80 F7FFFC0F BL.W strlen (0x000095A2)
0x00009D84 9002 STR r0,[sp,#0x08]
0x00009D86 4669 MOV r1,sp
0x00009D88 2001 MOVS r0,#0x01
>>0x00009D8A BEAB BKPT 0xAB
0x00009D8C BD0E POP {r1-r3,pc}
The above appears to be part of code called by __rt_lib_init_stdio_1.
What is going on? I don't know what BKPT does. I assume it raises a software breakpoint which should then be handled by the debugger? Shouldn't the Keil/ARM ULINK2 software and hardware already be configured for this? Is there some trick to making debug printf work with Keil JTAG/sw ports?
I am unsure what the difference between an sw and JTAG port is. sw means what exactly, I believe it refers to one of two possible modes for the JTAG physical connector on a board, where JTAG is a classic but more limited mode without trace support, and sw mode adds trace support without adding any pins to the JTAG connector layout? But this is embedded systems, where being cryptic is the norm. I am new to Cortex-M3 development, and a lot of this stuff is new to me since the old ARM7TDMI days. But the Keil uVision prints this message out: "ITM works only with SW port, not with JTAG". Is SW a different physical port that you have to design on your board? (I am using a custom designed application board, not a development starter board.)
[Googling around lets me in on the fact that _sys_open and some pragma __use_no_semihosting_swi and something else are intimately involved in this puzzle, BRKPT instructions in ROM might be some ARM variant on the SWI ('software-interrupt') ARM instruction.]
This one was a failure on my part to understand that stdio is not implemented, but rather you must provide your own implementation, usually done inside a file called "retarget.c". The filename is pure convention, but is well documented (as it turns out) inside Keil's uVision/RTLIB documentation
I've done this with the IAR EWW ARM toolchain, but the term semihosting leads me to believe that the Keil approach is similar. There should be an option when specifying the standard library to link in to use semihosting. That will compile/link in a different library which redirects printf / putc through the JTAG port to the debugger.
So look at the options for the project in the Uvision IDE or in the make scripts. In the IAR linker command line this is "--semihosting" but is probably different for the Keil tools.
BKPT is the instruction the tools insert in the source to trigger the debugger. It's how the IDE enables you to add breakpoints to the code when the debugger doesn't support HW breakpoints (or you have used your full complement of them already).
SW is a two wire interface that provides access to debugging ports on the device.
Arm have a .pdf about it here:
http://www.arm.com/files/pdf/Low_Pin-Count_Debug_Interfaces_for_Multi-device_Systems.pdf
To deal with this problem in Keil uVision just go to project options. In Target tab/Code Generation check the Use MicroLIB checkbox.