are condemned to reinvent it, poorly
- Henry Spencer
-Original Message-
From: avr-gcc-list-bounces+matt.vandewerken=csiro...@nongnu.org
[mailto:avr-gcc-list-bounces+matt.vandewerken=csiro...@nongnu.org] On Behalf Of
Raymond Moore
Sent: Monday, 14 March 2011 10:43 AM
To: avr-gcc-list@nongnu.org
Hi Rick:
I too am interested in this topic.
I have a board that has an AVR and an Altera FPGA on it, which at the
moment I need to program separately.
Some options I've thought of:
1. Daisy-chain the JTAG from the Mega128 to the Altera. This doesn't
seem to work, I believe it's due to the AVR
That looks like it has compiled to me.
Cheers,
Matthew van de Werken - Electronics Engineer
CSIRO EM - Mining Geoscience Group
1 Technology Court - Pullenvale - 4069
p: (07) 3327 4142 * f: (07) 3327 4455 * e: [EMAIL PROTECTED]
We do not inherit the earth from our ancestors, we borrow it from our
Perhaps an alternative is to roll your own multi-core processor with an
FPGA and some of the many 8-bit processor cores running around. This has
the advantage of you being able to select different processors for
different purposes, and also to choose the internal bussing mechanism.
Cheers,
For what the OP wanted, and more:
http://www.xs4all.nl/~dicks/avr/usbtiny/
Cheers,
Matthew van de Werken - Electronics Engineer
CSIRO EM - Mining Geoscience Group
1 Technology Court - Pullenvale - 4069
p: (07) 3327 4142 * f: (07) 3327 4455 * e: [EMAIL PROTECTED]
We do not inherit the earth from
Hi all:
I am running winavr 2006*, on an atmega128 with 32k of XRAM mapped to
0x8000-0x. I would like the .bss memory section to be allocated by
the linker in the internal RAM, while I'd like the .data section and the
__malloc_heap_start to both be in XRAM. .bss being in IRAM is not really
Title: Message
An AVR
with only 8k flash wouldn't generally be suitable for any OS, however you might
want to check out avrX, freeRTOS and tinyos.
Cheers,
Matthew van de Werken -
Electronics EngineerCSIRO EM - Rock Mass Characterisation - 1
Technology Court - Pullenvale - 4069p: (07) 3327
I tried exactly this, however I now get a linker error:
c:\apps\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe:main.
o: file format not recognized; treating as linker script
c:\apps\WinAVR\bin\..\lib\gcc\avr\3.4.3\..\..\..\..\avr\bin\ld.exe:main.
o:1: parse error
make: *** [main.elf]
Having solved all that, I wanted to add an auto-incrementing build
number to the build process, which lives in program memory. Here's how I
did it:
I made a buildnumber file, as follows:
buildnumber:
=8--
# This is the current build
I have the same problem, and the point is that part of my external
memory is inside an FPGA, basically under control of the FPGA (It's
high-speed ADC data), while another part is external SRAM which I use
for my heap etc.
I access the FPGA memory at the moment using pointers which I initialise
Hi all:
I am looking for an automated way to update a static string in program
space when my project is built. Is there an easy way to do this, either
by adding an extra target to the makefile, or some other way? I'd prefer
not to manually have to change the information, and I'd also prefer for
Hi David/avr-gcc list:
The __DATE__ and __TIME__ macros as mentioned by others in this thread
are useful for timestamps.
However, I'm having a problem getting my head around the following:
Suppose I create a version.c file, that contains those macros as progmem
strings, like this:
const
Apologies for the continuation of the off-topic thread, but anyway:
In my application I use an AVR with an Altera FPGA to control some ADCs,
and do other stuff. The ADC result is memory-mapped on the external bus
of the AVR, which works well. The FPGA also performs many other
functions, which are
13 matches
Mail list logo
