Nice portable AVR XMEGA IDE

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking that if I make my board/device, I'll have to have an attractive IDE for programming it.

Arduino IDE: Nice, portable, everyone uses it. However, it isn't an option because Arduino doesn't support XMEGA (well, only the Xmegaduino port of it). Also, my device will have a kernel in Boot Section with all user functions there so that the user doesn't have to have them in the Application Section. Arduino uses everything in the Application Section and that would come into conflict. I also don't think my board would really qualify to be an Arduino one.

Atmel Studio: My mentor has trouble with it every single year installing it on fresh PCs in school because it uses Visual Studio 2010 Shell and it comes into conflict with Visual Studio 2010 and Visual Studio 2012. DLL HELL! Also, it takes 1 hour to install and also also (which is a double-also), it's not portable.

WinAVR: I've heard it's not being worked on anymore and that it erased the PATH environment variable on someone's PC!

 

So which AVR IDE with AVRASM2, avr-gcc (C & C++) and AVRDude (with all its programmator support like on Arduino) exist out there that are free and portable?

 

If none exist, can I make one? What licenses and permissions do I need?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Code::Blocks would be my choice - as far as I know it's fairly open.

 

I doubt anything is ever going to offer DEBUGGING as good as Atmel Studio does though (having said that David like Rowley and IAR - but both are commercial) so all that really leaves is an editor and Makefile generator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Code::Blocks would be my choice - as far as I know it's fairly open.
A variant of Code::Blocks is Em::Blocks or its follow-on EmBitz but concerns are :

  • AVR appears to be a secondary target (ARM Cortex-M is one of the primaries).
  • Licensing added to EmBitz for enhanced features to aid revenue to its creator.

Board index EmBlocks EmBlocks IDE

EmBlocks and AVR

http://www.emblocks.org/forum/viewtopic.php?f=1&t=441

 

Board index EmBlocks EmBlocks IDE

Pre-release new EmBlocks platform 0.40

...

http://www.emblocks.org/forum/viewtopic.php?f=1&t=595&start=60#p3395

by EmBlocks

Jun 10, 2015

...

Yes, this whole license thing is new.

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:
Atmel Studio: My mentor has trouble with it every single year installing it on fresh PCs in school because it uses Visual Studio 2010 Shell and it comes into conflict with Visual Studio 2010 and Visual Studio 2012. DLL HELL! Also, it takes 1 hour to install and ...
Your mentor might try a virtual machine on Windows iff the "fresh PCs" are capable enough (Windows OS level and EULA that allows virtualization, CPU, RAM, mass storage timing and sizing, USB host controller).

Some Windows versions contain a virtual machine manager that will use virtual disk images; otherwise, VirtualBox is popular.

Once the mentor has a functional virtual disk image then the mentor can serve that image to each PC.

Atmel Logo

Atmel Studio

Driver and USB Issues

Firmware upgrade fails on VirtualBox

http://www.atmel.com/webdoc/atmelstudio/atmelstudio.faq.virtualbox.html

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are using XMEGA ICs, then your needs are greater than regular AVRs. 

 

Have you considered moving the designs to the Cortex-Mx ARM platform?  This 32-bit ICs sell in the same price range as XMEGAs and will have more advanced (easier to use and quicker to load) IDEs than those available for XMEGA.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 and will have more advanced (easier to use and quicker to load) IDEs than those available for XMEGA.

+1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would do it if the project wasn't about making an 8-bit game console with maximum RAM and CPU frequency. I'll do as much as I can with it. Thanks for the IDEs.

Last Edited: Fri. Jun 26, 2015 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why would the user of an 8bit console need an "IDE"??

 

If I'm the user of a console the only interface I require is a joystick/d-pad and some buttons.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Because the point of the console isn't only to play the game, but to make games and even make mods of existing games. That can't be done without an IDE.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Arduino IDE ... isn't an option because Arduino doesn't support XMEGA

Given the 1.6.x Arduino IDE, it is probably no harder to add XMEGA support than it is to add it to any other IDE...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does Xmegaduino even work? Does XMEGA even have the Arduino bootloader?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only requirement of a bootloader to work with Arduino is simply that it can be driven by avrdude. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Probably all the classic games were written without an IDE. Maybe even without an assembler.
Where do you get these notions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Probably all the classic games were written without an IDE. Maybe even without an assembler.
Where do you get these notions?

I have some personal experience. I worked for Amstrad in the 1980's and we handled the publishing of games for our CPC464, CPC664 and CPC6128 range of home computers. In the course of this I actually got to see some of the source code for some games. The fact is that it was written in Z80 Asm. I remember one classic example that had no comments whatsoever - just thousands and thousands of lines of Z80 mnemonics. Apparently the programmer had a "picture" of what everything was doing in his head (and I guess no one else needed to know?). Such games were assembled using command line tools (usually on a CP/M development machine in fact). This all pre-dated the widespread use of IDEs - I guess the first true classic IDE that really caught on was Borland but that wasn't due to arrive for a few years yet.

 

The reason why these games were all written in Z80 Asm was that on the whole they were pushing the 3.5 .. 4MHz CPUs to their absolute limit and a lot of what was happening had to be cycle accurate. (also there weren't any really sensible choices for Z80 C compilers at that time either). I imagine the same was true of the various 6502 based home computers too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But to even get to sell my product, it needs to be programmable in a user friendly way which people like. People like Arduino and people like video games. Combine both, you get Gamebuino which you can program in the Arduino IDE. I don't think that my product will be enough selling if only the little number of very scarce hardcore binary programmers are going to make games for it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you not remember the days of 8bit home computers? (I guess it's an age thing?)

 

Anyway, back then, as well as your Manic Miners and Jet Set Willy's there were various "game generator" packages. None were ever successful because it's a bit like running code in a JavaVM rather than on a base CPU - you may well give the "game designer" high level concepts like move_sprite(sprite3, 100, 100, 300, 400) which animates the movement of a sprite from (100,100) to (300,400) or whatever but giving this kind of high-level (Arduino-like?) notions to the user is at the expense of raw performance. It's true that an AVR is 16/20/32MHz so you have a bit more performance to burn than back on those 3.5/4/6MHz CPUs of yesteryear but back then there wasn't really a choice - things like the sprite movement had to be done in honed, hand written Asm to deliver sufficient performance and now there's probably enough CPU to let them do it in C/C++ but I don't think you are going to have the additional headroom you need to give them even higher level concepts like "sprite building blocks" or whatever.

 

Have you prototyped any of this? What's the display device? How many sprites can you have in motion at once? What's the frame rate? Is it pixel accurate collision detection?

 

In fact Arduino is a good example of the issue. It tries to provide high level "building blocks" so those less knowledgeable in programming can still "bolt together" solutions but there's a huge expense involved in trying to provide such high level and easily understood interfaces - no one ever accused Arduino code of being efficient!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff , I was referring to the likes of Space Invaders and Space Wars from the 70's. I thought myself lucky to have a microprocessor. Assembler! That was for the well heeled. I hand assembled - not by choice.

 

Foxy, you've got yourself a few hurdles then. Best be getting to it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Yes, I have accused the Arduino code of being efficient.
Most libraries make the best use of the hardware peripherals. It is only when the punter is determined to bit bash SPI or UART on inappropriate pins that performance suffers. e.g. they are forced to use digitalWrite () and friends.
However, I would be very surprised if you would get a market for Game designers. Surely the average phone or Xbox is in a different league to AVR. Even the xmega.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:
But to even get to sell my product, it needs to be programmable in a user friendly way which people like.

But that is an entirely different thing from saying:

That can't be done without an IDE.

Clearly, it most certainly can be done without an IDE. It may not be "convenient" or "attractive" - but it most certainly can be done!

 

People like Arduino

But, surely, one of the key reasons why people like Arduino is because they can program it without having to worry about the details of the underlying processor?!

 

So why is it so important that it has to be an XMEGA??

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jun 29, 2015 - 11:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm 19 so I wasn't in the 8-bit era. I have no idea.

The building blocks will actually be the sprite rendering functions for the video buffer, loading bitmaps from SD card to places beyond 64kB (because avr-gcc can't go over 64kB in RAM), buffering the MP3 codec chip for music, date and time RTC, file system interface, etc. The user will be left with everything else. That's what people like.

 

I'm trying to build the prototype with a friend, but we're looking for a good SDRAM chip. When we find all the components, we'll make a board schematic and send it to a PCB company to make the PCB with those components. Everything else will be on breakout boards or breadboards. When we see how everything should be connected correctly by trying it on the breadboards, we'll make one schematic of one PCB with all components on it which will be the final product ready for Kickstarter.

I haven't worked with the external RAM so I have no idea. All this is blindly trying to guess so I'm here asking for help trying to check what can be possible so that I don't mistify too much in my imagination and then see it's impossible or buy something that doesn't work (happened to me already and I was really angry).

 

The display device will be either an ST or ILI chip with 320x240 resolution and 16-bit color. I have no idea how many sprites. All I know is that the sprites are rendered onto a video buffer and then every 50 or 60 frames per second the buffer bytes are sent to the display. When I get the PCB, then I'll measure the speed of the rendering and see how many sprites I can render in one frame and how many instructions will be left for the user if they're rendering a certain number of sprites like 64 for example. The sprites will be handled by the user's code and they just type a function call for rendering a X×Y sized sprite from a specific RAM address to the video buffer at X×Y.

 

The kernel with those rendering functions and etc. will be coded in assembler for bigger efficiency so there you have it. Maximum efficiency.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:
the little number of very scarce hardcore binary programmers

As opposed to the vast hordes of games developers wanting to use an 8-bit microcontroller ??!!

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think there are more people who like high-level everything-works-so-easily than people who really do low-level things like I want to make the kernel. If there are more low-level people, I'll be happy. If they crowdfund, I'll be even more happy!

Last Edited: Mon. Jun 29, 2015 - 12:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhh, more gems! The 64k limit is more due to the AVR's 16 bit pointers than gcc imposing a limit.
What defines a 'good' sdram chip vs a bad one?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A bad SDRAM chip could be only the chip that has a high frequency so much that when underclocked to 64MHz have too big delays than the EBI can be set to. This is what I'm afraid.

 

Also, the 64kB limit can be broken with RAMPs! If avr-gcc was made to support that, it'd be great, but noooooo. But still, my kernel would allow loading game resources into 64k+ space for rendering and manipulation and even copying it to the 64k- space and vice versa.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi !

 

Are you talking about the 64k barrier being in Flash ? or in RAM ? If the former, then I have to tell you that I'm using avr-gcc to access the whole 128k of my ATXmega128A1U/ATXmega128A4U without any problem.

If the later, then I would believe that this handled by the EBI, no ? (I should test this with the XPLAIN and its 8MB of external RAM)...

 

Good luck with your project, it is not an easy one !!

Have a nice day,
Kraal

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again !

 

I'm reading the app note AVR1312 (http://www.atmel.com/Images/doc8...) and it is seems that only CS0 can be used with SDRAM. The thing is that it says further that the maximum addressable space is 16M bytes for each chip select block... Does that mean that you can only add 16MB of external RAM to your application when you are using a SDRAM chip ? Is it possible to add more with other memory type ?

 

Edit: according to the AU manual, the maximum that can be supported is 16MB using 3-port EBI

Have a nice day,
Kraal

Last Edited: Mon. Jun 29, 2015 - 01:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Avr-gcc can't go over 64kB in RAM because of 16-bit pointers and the linker supporting only 64kB of RAM.

With assembler, this is far easier.

 

One RAMP page holds 64kB. 256 of those is 64kB*256=16MB. This means that the maximum addressable RAM is 16MB. Can't go anymore from that.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

because avr-gcc can't go over 64kB in RAM

I guess that depends on where you draw the line on what is actually called "avr-gcc".

 

avr-gcc is a compiler driver, cl1 is a compiler, avr-as is an assembelr,  avr-ld is a linker. Together they are collectively called "avr-gcc". You can use it to write code that addresses outside of 16 bit pointer spaces. Now either in the C you can use asm("any AVR code you like") or, more cosmetically you can write .S files to be passed to avr-as and they can contain any AVR code. That code can mess with RAMPD, RAMPX, RAMPY, RAMPZ, EIND and all that stuff to extend the address ranges of memory areas beyond the 16 bit width of an AVR index register. Whether one could call that a capability of "avr-gcc" I guess is another question. Personally I would claim that  - for example avr/pgmspace.h already has pgm_read_far*() routines which start with 32 bit addresses from pgm_get_far_address() and then use part of that for RAMPZ.

the linker supporting only 64kB of RAM.

Eh? This is GNU ld you are talking about - it can link Megabyte or even Gigabyte programs. The only limitation imposed on AVR code comes from the linker scripts.

This means that the maximum addressable RAM is 16MB. Can't go anymore from that.

But once again the limit is NOTHING to do with GCC (a compiler that can write huge software for ARM and x86). Again what you talk of is an Atmel AVR architecture limit. Yes the index registers are only 16 bits wide so yes they can only address 64K locations. And yes the RAMx registers that extend their width are ony 8 bits wide so yes the total addressable range of any RAMx+index is 24 bits or 16MB.

 

If you want to break those restrictions use an ARM - they have a linear 4GB address space that is usually split between some combination of RAM, ROM and IO.

 

Once again I know (like Atomic Zombies projects) that all this is "real clever stuff". Getting under-powered, under-resourced micros to do something clever is a real feat if engineering prowess and hats off to anyone who achieves such things. But think about your customer here. If they are someone interested in "console games" and perhaps the ability to author such things with some easy to use building block system then why will they be fussed whether you are delivering this on a 250kHz Intel 4004, a 20/32MHz 8bit micro, a 50/100MHz Cortex M or a 500Mhz..1GHz Cortex A? They will just want it to play the games and have a slick/easy to use IDE and won't care what a feat of technical excellence the design actually is.

 

Personally I'd just do it on a $25 single board Linux machine with HDMI and a 1 GHz Cortex A.

 

I'm not sure I'd even impose C on them - yes, it's a brilliant language at the systems engineering level. But for a high level object oriented, easy to use system I'd give them something more suited for the task. The possible obvious choice there being Java.

 

Now consider what the games/app environment on most mobile phones is ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If one guy could make Gamebuino and entertain people and succeed, then surely I can with my project.
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
think about your customer here

The very customers who you yourself said need it to be "programmable in a user friendly way" - so would not tolerate a non-IDE approach.

 

Quote:
If they are someone interested in "console games" and perhaps the ability to author such things with some easy to use building block system then why will they be fussed whether you are delivering this on a 250kHz Intel 4004, a 20/32MHz 8bit micro, a 50/100MHz Cortex M or a 500Mhz..1GHz Cortex A?

Exactly!

 

As you yourself said, they are not "hardcore binary programmers"

 

Quote:
They will just want it to play the games and have a slick/easy to use IDE and won't care what a feat of technical excellence the design actually is.

Indeed!

 

Quote:
I'm not sure I'd even impose C on them - yes, it's a brilliant language at the systems engineering level. But for a high level object oriented, easy to use system I'd give them something more suited for the task. The possible obvious choice there being Java.

Good point.

 

I understand that Lua is quite popular in gaming circles...?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

We're getting into the same loop we did in another of your threads - you make an unsubtantiated claim and we refute it only to be answered with another unsubstantiated claim. And so it goes.
As for your sdram problem, what brought you to the conclusion that it wouldn't work? You asked about the min clock frequency and i said there was none, but there were other spcs you needed to comply with - mainly refresh. At 64MHz that shouldn't be a problem. The -7 and -10 were speed grades. If you interpolated those values based on the clock, then that is not how it works.
As for management of banked ram, be it c or asm, you have to solve the same problem. Having a compiler that does it for you is handy, but it was not uncommon to have various bank schemes on old 8 bit micros with no direct compiler support.
If you don't want to mess with the grimy stuff, as Cliff says, go to a ARM device. Atmel have a sam4 xplained board with 8M sdram. The compiler supports the whole memory space. Problem solved.
If there is something you dont understand, do some research first then if you still have a question, ask here, but don't keep changing the subject and spouting trash. You waste our time and you get no closer to your goal. The old adage 'keep your eye on the ball'