| Author |
Message |
|
|
 Posted: Apr 30, 2008 - 10:44 PM |
|
Joined: Feb 29, 2008
Posts: 36
|
|
Well, it's the end of April now.
Anyone heard when the Raven source code will be released? |
|
|
| |
|
|
|
|
|
|
Posted: May 01, 2008 - 08:53 AM |
|
Joined: Dec 21, 2007
Posts: 67
Location: Egypt
|
|
|
|
|
|
|
|
Posted: May 23, 2008 - 06:38 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
|
|
|
|
|
Posted: May 23, 2008 - 07:33 PM |
|
Joined: Apr 01, 2004
Posts: 3812
Location: New Mexico
|
|
|
|
|
|
|
|
Posted: May 28, 2008 - 09:52 AM |
|
Joined: May 28, 2008
Posts: 6
Location: Melbourne, Australia
|
|
I don't think that they did a good job on this RAVEN zigbee Kit, I am sorry to complain that.
I got two issues so far:
1,I can not debug avrraven_3290p, As both program size of data size are out of memory range.
2,when I start debugging ATmega1284p, the AVRRAVEN board can not communicate with USBSTICK.
3,source codes of IEEE802.15.4 and ZIGBEE are not very clear, right? before I used TI CHIPCON Z-Stack which is much better than the RAVEN. |
|
|
| |
|
|
|
|
|
|
Posted: May 28, 2008 - 04:14 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
Vivienne wrote:
1,I can not debug avrraven_3290p, As both program size of data size are out of memory range.
Is this after compiling the code with avr-gcc? The documentation states the code is less optimised than when compiled with IAR and thus won't fit.
They aren't kidding--I've been planning to post about the difference but haven't got to it yet--the bootloader is from memory ~8KB with GCC and 4KB with IAR. (Is this size discrepency "to be expected"?) The "application" is about 107% larger than 32KB for code and 103% larger for RAM.
I've gotten a GCC compiled bootloader to run by ifdef'n out most of the functionality. I also ifdef'd out much of the application code in order to get it to compile to size, but didn't get as far as getting it functional. I did manage to get the application to flash the LED and activate LCD icons--but not display text.
My current plan is to try to compile the full bootloader as the application to see if it works okay.
I've documented some of this but unfortunately my site is currently down.
--Phil. |
|
|
| |
|
|
|
|
|
|
Posted: May 28, 2008 - 05:21 PM |
|
Joined: Jan 23, 2004
Posts: 7014
Location: Melbourne, Victoria, Australia
|
|
They must be doing it wrong. I'd be able to easily test out some GCC switches if they'd supplied proper makefiles, but the AVRStudio dialog isn't flexible enough.
I can see they could have added in -gc-sections, --relax, -mcall-prologues, -finline-limit-20 and a few others (from memory) to get it down in size.
- Dean  |
_________________
|
| |
|
|
|
|
|
|
Posted: May 30, 2008 - 04:56 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
abcminiuser wrote:
They must be doing it wrong. I'd be able to easily test out some GCC switches if they'd supplied proper makefiles, but the AVRStudio dialog isn't flexible enough.
I can see they could have added in -gc-sections, --relax, -mcall-prologues, -finline-limit-20 and a few others (from memory) to get it down in size.
I'd appreciate any other suggestions along those lines that I could use in the Makefile AVR Studio lets you export--I'm aiming to be working on a non-Windows platform anyway.
I'll plan to try out the options you've mentioned and see what difference it makes.
Thanks for your reply.
--Phil. |
|
|
| |
|
|
|
|
|
|
Posted: May 31, 2008 - 07:12 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
Hi again...
abcminiuser wrote:
but the AVRStudio dialog isn't flexible enough.
I'm a little confused by this remark--why did you think the flags you suggested couldn't be specified in the dialog?
I've generated Makefiles from the supplied projects and will look at uploading them when my site is on-line again...
Quote:
I can see they could have added in -gc-sections, --relax, -mcall-prologues, -finline-limit-20 and a few others (from memory) to get it down in size.
I tried the flags you suggested and a couple of others I discovered and had small reductions but not significant enough to make the code fit without further work needed.
I've included some details below--I haven't actually tested any of the code generated. (I did wonder if the binaries needed to be stripped.)
Any further suggestions? 
--Phil.
Code:
======= 3290p_bootloader =======
Program: 9170 bytes (28.0% Full)
(.text + .data + .bootloader)
With -mcall-prologues [Program: 8884 bytes (27.1% Full)]
Unchanged with: --gc-sections -ffunction-sections -fdata-sections --relax -finline-limit=20 -fmerge-all-constants -funsafe-loop-optimizations
==========================
======= 3290p_application =======
Program: 35234 bytes (107.5% Full)
(.text + .data + .bootloader)
With -mcall-prologues [Program: 33390 bytes (101.9% Full)]
With above + -finline-limit=20 [Program: 33000 bytes (100.7% Full)]
Unchanged with: --relax --gc-sections -ffunction-sections -fdata-sections -funsafe-loop-optimizations -Wunsafe-loop-optimizations -fmerge-all-constants
==========================
|
|
|
| |
|
|
|
|
|
|
Posted: Jun 18, 2008 - 10:23 AM |
|
Joined: Mar 05, 2001
Posts: 125
|
|
Phil, did you get any further? I'm faced witht he same issue and am now busy stripping functionality out of the 3290p. Haven't yet managed to get it down to size. Looks like it's going to be a bare bones app. It seems almost unbelievable that the IAR compiler is able to compile so much more efficiently - unless of course we're missing a majic GCC switch??
Greg |
|
|
| |
|
|
|
|
|
|
Posted: Jun 21, 2008 - 10:23 AM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
greggallagher wrote:
Phil, did you get any further?
I managed to cut down the bootloader enough eventually to fit (without most of the functionality) but I couldn't get the Alphanumeric LCD code functioning properly.
I then tried using the base bootloader code as the application but the LCD still didn't work so I guess I'm missing something. While I could have tried to see if the radio stuff would work my current thinking is that trying to do it without the display would be an exercise in frustration.
Quote:
Looks like it's going to be a bare bones app.
Yeah, there seems to be a lot of "base" code (LCD, DataFlash, "file system", Radio I/O) that needs to be present before you can get something usefully functional.
Quote:
It seems almost unbelievable that the IAR compiler is able to compile so much more efficiently - unless of course we're missing a majic GCC switch??
It does seem somewhat strange but I don't have enough experience with IAR/GCC differences to know if this is atypical.
All complicated by my web server being down and having dev machine problems. 
--Phil. |
|
|
| |
|
|
|
|
|
|
Posted: Jun 27, 2008 - 12:38 PM |
|
Joined: Jun 26, 2008
Posts: 3
|
|
|
greggallagher wrote:
Phil, did you get any further? I'm faced witht he same issue and am now busy stripping functionality out of the 3290p. Haven't yet managed to get it down to size. Looks like it's going to be a bare bones app. It seems almost unbelievable that the IAR compiler is able to compile so much more efficiently - unless of course we're missing a majic GCC switch??
Greg
hi
I did the same as you. I stripped the speaker and audio and few other small functions. which result that the size is about 73% of the original one. But still if I try to program it, the same fault. stk500dll.
haven't you look inside your hex file?
the hex file has 2 strange rows:
this is end of hex file
:106B280000454D505459004552524F520057414963
:106B38005400444F4E450057524954494E47204D42
:106B48003132383420494D414745001C000000ECE3
:046B58000001000038 row1
:02DFFE0001011F row2
:00000001FF check sum
if I remowe those 2 rows of one of them,I am able to program but with mistakes. do you have any idea why?
did you solved your problem? |
|
|
| |
|
|
|
|
|
|
Posted: Jun 27, 2008 - 01:33 PM |
|
Joined: Mar 27, 2002
Posts: 9648
Location: Lund, Sweden
|
|
|
Quote:
the hex file has 2 strange rows
Strange in what way?
Quote:
if I remowe those 2 rows of one of them,I am able to program but with mistakes. do you have any idea why?
You changed the contents of the HEX file without updating the checksum? |
|
|
| |
|
|
|
|
|
|
Posted: Jun 27, 2008 - 02:12 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
elmir_24 wrote:
haven't you look inside your hex file?
the hex file has 2 strange rows:
this is end of hex file
:106B280000454D505459004552524F520057414963
:106B38005400444F4E450057524954494E47204D42
:106B48003132383420494D414745001C000000ECE3
:046B58000001000038 row1
:02DFFE0001011F row2
:00000001FF check sum
if I remowe those 2 rows of one of them,I am able to program but with mistakes. do you have any idea why?
I can't quite parse what you were saying, but that does remind me, I did remove the row you have marked as "row 2" because it is outside the address range of the target. I found a setting in the avrstudio file that suggested it's something to do with the firmware version or something? And it's supposed to be "at the end" of memory, I seem to recall.
Deleting the row enabled the hex file to be used.
--Phil. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2008 - 09:26 PM |
|
Joined: Jun 26, 2008
Posts: 3
|
|
| is there anyone who succeed to make the source code fix into 3290p? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 02, 2008 - 10:52 PM |
|
Joined: Feb 29, 2008
Posts: 36
|
|
It seems to me that Atmel put the Raven on the market too soon without the developer support (compilable source, drivers, etc.) one would expect. I love the concept, the product, the opportunity to get one for no cost (TNX Atmel!!!) but my Raven is languishing in my bookcase waiting for better support.
I'd be curious how many Raven owners are doing anything productive with their's besides trying make one work? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 03, 2008 - 10:20 AM |
|
Joined: Dec 20, 2002
Posts: 6697
Location: Dresden, Germany
|
|
|
|
|
|
|
|
Posted: Jul 03, 2008 - 02:01 PM |
|
Joined: Mar 27, 2002
Posts: 9648
Location: Lund, Sweden
|
|
|
Quote:
It seems to me that Atmel put the Raven on the market too soon without the developer support (compilable source, drivers, etc.) one would expect.
They have released compilable source which AFAIK runs just fine on the Ravens. It just isn't written for the compiler/toolchain you are using. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 07, 2008 - 12:04 AM |
|
Joined: Nov 17, 2004
Posts: 4578
Location: Great Smokey Mountains.
|
|
|
totallyembedded wrote:
It seems to me that Atmel put the Raven on the market too soon without the developer support (compilable source, drivers, etc.) one would expect. I love the concept, the product, the opportunity to get one for no cost (TNX Atmel!!!) but my Raven is languishing in my bookcase waiting for better support.
I'd be curious how many Raven owners are doing anything productive with their's besides trying make one work?
Let me join in with this question.
To which Jörg replied:
dl8dtl wrote:
I don't see how that helps?
I want to know if anyone can show how to use the bootloader on the Raven to load a tiny bit of code that will blink an LED on one of the GPIO pins. This should be so simple, yet no one seems to have done even something this simple. I've read the docs and even a lot of the source code and I don't see how to do this other than create a full image of both the 3290P and the 1284 and use the 'Upgrade firmware on node' which is what I think RancidBacon or Follower used which trashed his Raven.
What is going on?
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Jul 07, 2008 - 04:19 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
dl8dtl wrote:
Thank you! Thank you! Thank you! (Now, when did that code appear..? )
I finally have some text reliably displaying on my LCD!
So, no radio interaction yet, but I'm just happy to find something that compiles out-of-the-box with avrgcc and displays my text reliably!
Getting this far wasn't without incident however and you can catch up on the story in the usual place: http://code.rancidbacon.com/LearningAboutAtmelRZRAVEN . There's a gratuitous patch there too.
Side notes: I successfully jumpered the VCC & GND to the 1284p ISP header from the 3290p ISP header. Doing so enabled me to reflash the ATmega1284p which brought my b0rked Raven back to life! Now I'm back to having *two* Ravens to do my bidding!! Ah ha ha! (Well, when they feel like it...)
Also, I uploaded the firmware via the 3290p ISP header--my one additional attempt to use the over-the-air update bizarrely uploaded my original b0rked CRAVE firmware despite referring to the "factory default". Now that I do have ISP ability on both chips maybe I should look into the bootloader functionality again.
I also tried flashing the more recent, more functional firmware and while it worked I couldn't get the audio recording function to, well, function... Not sure why.
Next step I guess is to get the 3290p talking to 1284p radio firmware.
--Phil. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 07, 2008 - 04:28 PM |
|
Joined: Nov 06, 2007
Posts: 84
Location: New Zealand
|
|
|
smileymicros wrote:
To which Jörg replied:
dl8dtl wrote:
I don't see how that helps?
The key piece of text from that document, for me at least, is:
Quote:
The source code is available in the project release folder under the respective folders.
In order to compile the source code provided, WinAVR GCC compiler is a required
plug-in to AVR Studio.
Until that code was released I was unaware of any official Atmel code for the Raven that compiled out-of-the-box with avrgcc and was functional.
Quote:
'Upgrade firmware on node' which is what I think RancidBacon or Follower used which trashed his Raven.
I should point out that the modified firmware I tried to load (unsuccessfully) wasn't compiled from source but was a modified binary (which I didn't check carefully enough). I'm unsure whether an over-the-air update would work compiled from source, but with the most recent firmware update it is apparently possible to store a "known good" firmware in dataflash that can be retrieved (IIRC) via a menu item or shorting two pins. I have not done this successfully however (somehow it stored my b0rked firmware!).
If you're using avrgcc and have a 3290p ISP (or JTAG) header then the code associated with the above document (you'll need to get it from the Raven product page) should help you somewhat.
--Phil. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 18, 2008 - 03:32 AM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
Well after trolling around to try and find out what to do..... 
I got the basic boards upgraded using the firmware available through AVR2017.
Wireless services (WS) installed and start.
Then soldered the 0.05" JTAG connectors in, USB stick and one AVR Raven board. Once the board connected wirelessly, then through WS forced an
“Update Factory Default data on data flash”.
Requested versions and here is the listing from WS window.
HW 2.0
3290 1.1
1284 1.1
3290 Boot 2.0
1284 Boot 2.0
FD 3290 1.2
FD 1284 1.1
FD 3290 Boot 2.0
FD 1284 Boot 2.0
On the 2nd board AVR Raven tried to update it wirelessly, however it didn't seem to take and had the message "waiting for M1284 Boot Loader"
~Neil  |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2008 - 06:07 PM |
|
Joined: Jul 10, 2008
Posts: 50
|
|
Is there enough info in the datasheets to build your own apps?
Cheers, N |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2008 - 08:55 PM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
|
Navigateur wrote:
Is there enough info in the datasheets to build your own apps?
There are the hardware data sheets AVR2017,2002 with CCT diagrams including I saw at one point a good description of the custom RAven LCD mapping to 3290 pins. The processor data sheets are available, and as far as I can see the code for the three processors.
I haven't found any description on how to build the environment - either IAR or GCC - that is what I'm looking at now.
Some one earlier in another forum has put a package together with just the code and it looked like it was GCC build (thankyou)
So far I haven't found the "AVR Wireless services" code
So my objective is to take the RZ Raven and understand how it all went together and what the issues are. Then I've some specific objectives for my own AVR processor application - in particular I would like to have the standard base core functionality stuff like over air upgrading easily sorted out. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 19, 2008 - 09:27 PM |
|
Joined: Jul 10, 2008
Posts: 50
|
|
|
neilh wrote:
I haven't found any description on how to build the environment - either IAR or GCC
What does "build the environment" mean? I don't know what it means.
If you mean those register words you can use in C like "PORTA" or "DDRA" then I'm sure you could use the registers' addresses in the datasheet to make your own.
If not, what does it mean?
Thanks, N |
|
|
| |
|
|
|
|
|
|
Posted: Jul 20, 2008 - 01:39 AM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
|
Navigateur wrote:
neilh wrote:
I haven't found any description on how to build the environment - either IAR or GCC
What does "build the environment" mean? I don't know what it means.
So "Build environment" is the tool chain. What does it take in terms of tool chain and commands to be able to produce an error free executable.
BTW ArchRock has a disucssion forum with
http://asdsupport.archrock.com/?q=forum/1 |
|
|
| |
|
|
|
|
|
|
Posted: Jul 20, 2008 - 07:46 AM |
|
Joined: Apr 25, 2005
Posts: 106
|
|
The factory firmware is available from Atmel in source form, and builds without a hitch right out of the box with IAR- I have been able to do so.
It also can be built with AVR Studio/WinAVR, but the compiler optimizing is not as good, thus the code for the 3290p is too large to fit- I think others have been able to pair it down somewhat to make it fit.
The source is complete in every way- nothing is missing. |
|
|
| |
|
|
|
|
|
|
Posted: Jul 20, 2008 - 05:35 PM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
Does anybody know if the AVR Wireless Services Code is going to be made available - I'm particularly interesting in the upgrade procedures.
Quote:
It also can be built with AVR Studio/WinAVR
I've found the same for the AVR Studio code and compiled all the code.
The AVR project files are in the gcc directory.
I had a slight problem with the 1284P build. My tools are
AVR Studio 1.4
however the WinAvr\avr\include\avr\iom1248p.h needed a little massage to iron out typos with TCNT1 and UBRR0 bit mapping. I guess I should post it back as an issue.
I was also thinking maybe of adding a description to the RZRaven wiki of the boot architecture which I've been digging into (to port to my own ATmega2560 based board) |
|
|
| |
|
|
|
|
|
|
Posted: Jul 21, 2008 - 07:53 PM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
|
abcminiuser wrote:
They must be doing it wrong. I'd be able to easily test out
From what I've found it appears the linker is not removing unused code.
Doing some tests with the 3290P_bootloader, here is some data for what is not happening.
Any suggestion of switches ?
Size
9272 - 3290P boot loader original size
9144 - replace BLCC_WRITE macro with fn(): application\avrraven\3290P\bootloader\avrraven_3290p_bl.c
8310 remove unused code with switch in application\avrraven\3290p\board_peripherals\df.c
#ifndef AVRRAVEN_3290P_BL_REV_MAJ
So only need to find another 310 bytes and the 3290P bootloader can be gcc-ed.
I'm guessing but the next place it might come from is lcd.c or led.c in application\avrraven\3290p\board_peripherals
I'm using AVR Studio 4.14 which is invoking avr-gcc 4.2.2 |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2008 - 01:13 AM |
|
Joined: Jan 23, 2004
Posts: 7014
Location: Melbourne, Victoria, Australia
|
|
Well the appropriate switches to remove unused code (why is it in there in the first place?) would be:
Code:
-ffunction-sections
-Wl,--gc-sections
Which, coupled with linker relaxations:
Code:
-Wl,--relax
And inlining limitations:
Code:
-fno-inline-small-functions
Should reduce the code size by a decent amount.
- Dean |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2008 - 02:44 AM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
Hmmm.. thanks for the input - but nada changed for program size.
I added the options in one-by-one into AVR Studio 4.1, Project->ConfigurationOptions.CustomOptions
CustomCompilationOptions[AllFiles]
Had the following output.
-fno-inline-small-functions cc1 error unrecognised
After adding -Wl,--gc-sections (& -Wl,--relax)the output in the build window said
Code:
avr-gcc.exe: --gc-sections: linker input file unused because linking not done
avr-gcc.exe -mmcu=atmega3290p -Wl,-Map=AVRRAVEN_3290p_BOOTLOADER.map -Wl,-section-start=FW_REV_ADR_M3290P_BL=0xfffe hal_m3290_bl.o avrraven_3290p_bl.o bcd.o spi.o adc.o led.o df.o lcd.o self_programming.o -o AVRRAVEN_3290p_BOOTLOADER.elf
Couldn't find the option descriptions in gcc-4.1.2 manual, but the gcc manuals are for 4.1.2 and 4.3.0. Avr-gcc -dumpversion says 4.2.2
The compiler options that are used are
Code:
-mmcu=atmega3290p -Wall -gdwarf-2 -std=gnu99
-Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP
So perhaps I'm missing something. Is it possible to tell the linker to reveal itself?
A bit of puzzle
Neil |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2008 - 02:57 AM |
|
Joined: Jan 23, 2004
Posts: 7014
Location: Melbourne, Victoria, Australia
|
|
I got the (standard, unmodified) code down to 6460 bytes with the latest WinAVR applying the above switches.
Quote:
Had the following output.
-fno-inline-small-functions cc1 error unrecognised
You need a newer AVR-GCC - either upgrade or use the alternative:
Code:
-finline-limit=20
Which should do more or less the same thing.
Quote:
So perhaps I'm missing something. Is it possible to tell the linker to reveal itself?
You need to add the flags:
Code:
Wl,--relax
Wl,--gc-sections
To the "[Linker Options]" section of the project "Custom Options" configuration tab for it to work.
- Dean |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2008 - 09:26 AM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
Great - what version of the compiler ?
~neil |
|
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2008 - 09:29 AM |
|
Joined: Jan 23, 2004
Posts: 7014
Location: Melbourne, Victoria, Australia
|
|
GCC 4.3.0, the one in the latest WinAVR package.
- Dean |
_________________
|
| |
|
|
|
|
|
|
Posted: Jul 22, 2008 - 09:36 AM |
|
Joined: Mar 13, 2006
Posts: 20
Location: San Francisco, Ca
|
|
Just tried the following flags, and it
...----*~*~*~*worked*~*~*~*------...
Program: 6412 bytes
Note it is slightly different than your suggestion
Code:
-Wl,-relax
-Wl,-gc-sections
~Neil |
|
|
| |
|
|
|
|
|
|
Posted: Jul 23, 2008 - 06:32 AM |
|
Joined: Apr 25, 2005
Posts: 106
|
|
| Interesting... IAR compiles the bootloader down to a hair over 4000 bytes. Wonder how they do that? |
|
|
| |
|
|
|
|
|
|
Posted: Jul 23, 2008 - 07:58 AM |
|
Joined: Jan 23, 2004
Posts: 7014
Location: Melbourne, Victoria, Australia
|
|
Probably whole program optimizations, amongst other things. Unfortunatly Atmel haven't supplied proper makefiles (only AVRStudio projects) for the programs, so testing out different flags isn't as easy as it could be. Has anyone converted the programs to use standard makefiles yet?
I now regret giving away my second RZUSBSTICK - I now want to run my MyUSB RNDIS demo on both and see if I can make a simple wireless ethernet adapter between two of the sticks.
- Dean |
_________________
|
| |
|
|
|
|
|
|
Posted: Sep 05, 2008 - 11:24 PM |
|
Joined: Jun 15, 2008
Posts: 659
Location: North Carolina USA
|
|
Any progress? Getting rid of Fahrenheit, 12 hour time, audio playback looping, and audio record (not implemented anyway) takes off 828 bytes. Another 122 bytes by changing bcdtoi to
Code:
uint16_t bcdtoi(uint16_t bcd_number)
{
uint16_t integer;
// integer = ((bcd_number&0x000F) >> 0) * 1;
// integer += ((bcd_number&0x00F0) >> 4) * 10;
// integer += ((bcd_number&0x0F00) >> 8) * 100;
// integer += ((bcd_number&0xF000) >> 12) * 1000;
char i;
for (integer=0,i=12;i>=0;i-=4)
integer=10*integer+((bcd_number>>i)&0x0f);
return integer;
}
But I don't know how to combine with the bootloader for JTAG programming, and have had no success with over-the-air downloading an image (including the Atmel .a90 image, is that supposed to work?) |
|
|
| |
|
|
|
|
|
|
Posted: Sep 07, 2008 - 06:02 PM |
|
Joined: Jun 15, 2008
Posts: 659
Location: North Carolina USA
|
|
Well, with all the above changes it's down to Program:29072 bytes Data:1846 bytes without much loss in functionality. Possibly the 4K IAR bootloader could be extracted from the A90 file and pasted into the GCC hex output, but looking at the interrupt vectors it might share some routines with the IAR application. Anyway it didn't work for me when I cut out some audio code to leave room for it.
So I have been trying to get it to run without the bootloader, by turning off the BOOTRST fuse. So far just get a lot of thrashing of the display segments.
The out of range memory address in the hex file is caused by insertion of the revision numbers at the end of application memory, in avrraven_3290p.c
Code:
PROGMEM_LOCATION(static uint16_t ATmega3290p_appl_fw_rev, FW_REV_ADR_M3290P_APP) = AVRRAVEN_3290P_APP_REV
where in mmap.h
Code:
#define M3290P_BOOT_START_PAGE M3290P_APP_FLASH_PAGE_COUNT
#define M3290P_BOOT_FLASH_PAGE_COUNT 32UL
#define M3290P_BOOT_FLASH_SIZE ((uint32_t)M3290P_FLASH_PAGE_SIZE*(uint32_t)M3290P_BOOT_FLASH_PAGE_COUNT)
#define M3290P_APP_START_PAGE 0UL
#define M3290P_APP_FLASH_PAGE_COUNT ((uint32_t)M3290P_FLASH_PAGE_COUNT-(uint32_t)M3290P_BOOT_FLASH_PAGE_COUNT)
#define M3290P_APP_FLASH_SIZE ((uint32_t)M3290P_FLASH_PAGE_SIZE*(uint32_t)M3290P_APP_FLASH_PAGE_COUNT)
...
#define FW_REV_ADR_M3290P_APP (((M3290P_APP_START_PAGE + M3290P_APP_FLASH_PAGE_COUNT) * M3290P_FLASH_PAGE_SIZE) - (uint32_t)sizeof(uint16_t))
This seems correct but doesn't matter because it is overridden in the project configuration memory settings -
Code:
FW_REV_ADR_M3290P_APP = 0x6fff
Taking that out causes a linker error about overlapping segments, so that's probably why it was added. The correct value is 0x3fff if the application takes all available memory. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 17, 2009 - 05:30 AM |
|
Joined: Feb 17, 2009
Posts: 1
|
|
|
rjbishop wrote:
The factory firmware is available from Atmel in source form, and builds without a hitch right out of the box with IAR- I have been able to do so.
It's my first time using the raven board. At first, i tried compiling the factory firmware available in Atmel's website using IAR since I've been having problems compiling the code for 3290p using avr gcc. But when I switch to IAR, I still get some errors. This time it's regarding my codes for 1284p. It keeps on telling me that the SPIF0, SPE0, MSTR0, AND SPI2X0 are unidentified identifiers.
I just basically run the file that is loacetd in the IAR folder when I used the IAR software. Is there something I miss out that's why I'm having these kinds of error when compiling the code using IAR? |
|
|
| |
|
|
|
|
|
FAQ •
Search •
Register •
Log in to check your private messages
Log in
• 
Minimize
• 
RSS
