Have the progmem and 64kb ptr problems been fixed or shall I stay with BASCOM?

Go To Last Post
85 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I quit avr-gcc and went to BASCOM and worked for one month and the results were awesome and I did well on another contest. However, there are little problems like I can't do A=1+B+3*D, but have to write A=1+B, then make a new global or local variable, NewVariable=3*D, a=a+NewVariable. And sometimes, the footprint seems bigger than in C because C uses registers unlike BASCOM that after every operation stores the variables into memory. So because of this, I'm thinking of going back to C for AVR, but I'm not sure if the problem with 24/32bit PROGMEM and PSTR pointers and going over 64kb in RAM and __memx functions, printf_PF, insertsomethinghere_PF has been fixed. Is it fixed? How is LLVM-AVR? Does it have the problem solved?

 

Please do NOT:

  1. Tell me to move to ARM
  2. Tell me to use inline ASM because it has a horrible syntax and writing "LDS R16, CPU_RAMPZ" gives me an error. I'd rather use full ASM (not for the current project, but another one which is an interpretter for video games and will have a >64kB video buffer for the screen)
  3. Tell me to buy IAR Embedded Workbench because I contacted the sellers and the price is horrible (I barely bought BASCOM only because one person on the internet donated money to me because I bored him with my famous seeking for free and alternative)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Foxcat385 wrote:
... and going over 64kb in RAM ...
Is XMEGA128A1U and ASF Huge Memory acceptable?

http://asf.atmel.com/docs/latest/doxygen_mainpage/images/atmel.png

Atmel Software Framework

Data in Huge Data Memory Space

http://asf.atmel.com/docs/latest/xmegaau/html/group__hugemem__group.html

Is Pascal acceptable?

An AVR Pascal IDE has a banked pointer type (use of one AVR port for additional address bits).

Pascal-scm for Atmel AVR

http://www.e-lab.de/AVRco/index_en.html

IIRC, somewhere at the above URL is a schematic for a megaAVR EBI (mega128, mega1280, mega2560).

Edit : added Pascal.

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

Last Edited: Fri. May 1, 2015 - 04:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

not sure if the problem with 24/32bit PROGMEM and PSTR pointers and going over 64kb in RAM and __memx functions, printf_PF, insertsomethinghere_PF has been fixed. Is it fixed? How is LLVM-AVR? Does it have the problem solved?

That surely depends what constitutes a "problem" in the first place? There is always going to be an issue where some flash based data straddles a 64K boundary because on one side it is RAMPZ=N and on the other it is RAMPZ=N+1. So as you read the data and cross the boundary you need to handle the RAMPZ increment.

 

The original pgmspace.h stuff has pgm*_far() versions and pgm_get_far_address() which can get a 32 bit address for the base of some data  there.

 

The replacement __flash also provides __memx which is a pointer that includes 7 bits of bank info for flash based data. As an alternative there are __flash1, __flash2, ... which are just 16 bit pointers but the '1', '2', etc. in the name says which flash bank it is in.

 

But I would have thought that __memx, if you don't mind using 24 bit pointers should be the solution for most eventualities.

 

Maybe start by reminding us what you thought the "problem" was in the first place?

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

Hi !

 

Maybe I missed something, but I thought that PROGMEM, PSTR(..) and __flash were only used for program space (i.e. flash on these uC), therefore not relevant for RAM accesses. Or am I wrong ?

 

Have a nice day,
Kraal

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

Well he said "progmem and 64KB" in the thread title - I assume he means flash.

 

i know he said:

LDS R16, CPU_RAMPZ

which mentions "LDS" which maybe implies RAM - but that's just part of the support required to handle 64K boundaries in flash - read/modify/write RAMPZ. The reason he got an error with that is that it should have been:

IN R16, _SFR_IO_ADDR(RAMPZ)

I have no idea why he'd be resorting to ASm for this anyway. The Asm you need is already built into the macros in <avr/pgmspace.h> (or the compiler's own code generator if you use __flash or __memx).

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

Yeah but OP mentions a >64kB video buffer which is for sure in RAM...

I never had a problem accessing tables in flash located way after the 64kB boundaries (in the application table space of a XMega256A3U to be precise, which puts it effectively right after the 256kB application space).

I'm currently using the GET_FAR_ADDRESS macro (which I believe is now implemented by default in avrlibc ? Yes it is now called "pgm_get_far_address(var)"). This macro is indeed in ASM, but does not produce any error and works very well...

Have a nice day,
Kraal

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

The problem is that all pointers are not 24-bit or 32-bit unless I use these __memx tweaks. I want those to be native. That way every pointer to be 32-bit and linker to support 32-bit address space.

0x00------ Some address from data memory

0x01------ Some address from program memory

 

So my array would start at 0x00004000 and end at 0x000297FF. If I would need to get one graphic from app section and another from boot section, the addresses would be 0x01000345 and 0x0101089A.

 

So when there are const strings or const structs, their addresses must be in program memory which is from 0x01000000 to 0x01FFFFFF. No PROGMEM, no __flash, no __memx, just the standard C's const.

And what if I'm writing a bootloader? PSTR gives me strings in 16-bit pointered format! I want 24-bit so that RAMPZ knows where the code is.

BASCOM has a similar problem, but there are possible workarounds if you use a different function and use ASM to manipulate RAMPZ. Unfortunately, MACROs are useless because in BASCOM they have no arguments (at least not in the documentation).

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

The problem is that all pointers are not 24-bit or 32-bit unless I use these __memx tweaks.

Then use them.

No PROGMEM, no __flash, no __memx, just the standard C's const.

Then pick a device that actually has 32 bit addressing.

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi wrote:
Then pick a device that actually has 32 bit addressing.

If I choose UC3, I won't be able to use ASM because there's no asm for it. In Atmel Studio 6, I can't find UC3 when I choose assembler project.

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

But you should be able to use the GNU assembler which usually comes with GCC.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sat. May 2, 2015 - 02:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kraal wrote:

Yeah but OP mentions a >64kB video buffer which is for sure in RAM...

 

64K video buffer :O

 

Why not go the whole hog and put on a GeForce GTX 980.

 

I always thought 3K of video ram should be enough for anyone.

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

I have a question that is not completely on topic, but still highly related...

In order to use more than 16k of RAM on the XMega256A3U, we have to use an external RAM module with the EBI peripheral. How does it work code wise ? I suppose I have to initialize the hardware in the startup code, and then declare that added space in the linker script. But then are the accesses automagically handled by the compiler ? Or do we have to use special functions for this ?

Have a nice day,
Kraal

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

I won't be able to use ASM because there's no asm for it.

Sorry but how do you think a C compiler works? 

 

avr32-gcc just converts the C you write to Asm source code then that Asm source is passed to the avr32-as assembler to be assembled. You can either include asm("some code") in your C which is then just written directly into the asm file that is passed to avr32-as. Or you write separate Asm code in .S files which are built as standalone entities by avr32-as

 

This is no different to the 8bit avr-gcc/avr-as or the ARM based arm-gcc/arm-as etc. 

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

But why can't I find AVR 32-bit assembler in my list of assemblers in Atmel Studio?

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

why can't I find AVR 32-bit assembler in my list of assemblers in Atmel Studio?

Because  it is NOT an Atmel assembler as the one for the 8 bit chips. Never done a full GCC compiler project so can't really help much more with this, maybe you need to start the project as a GCC type but then add just assembler files of the .S types to the project??

 

A bit of a warning that the syntax is a bit different from the Atmel assembler and it is a linking assembler, but once you get the hang of things it should just work.

 

I had some docs on it but seem to be lost at the moment but this may help https://sourceware.org/binutils/...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

 maybe you need to start the project as a GCC type but then add just assembler files of the .S types to the project??

Exactly! 

 

(and exactly the same way you use avr-as in fact) 

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

Will I have those problems like that I need to write as in 8-bit SFRIO(_CPU_SREG_) something instead of CPU_SREG?

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

No. 

 

But you don't have to use _SFR_IO8() in avr-gcc anyway?!? You just "#define _SFR_OFFSET 0" before you include <avr/io.h> then you can use IN/OUT without the macro. 

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

Stay with BASCOM.

avrfreaks does not support Opera. Profile inactive.

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

Alright. And is there an alternative AVR compiler rather than BASIC, C, C++ and PASCAL?

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

Forth? Ada?

edit and by the way, unless you really must, don't waste time on UC3. Either stay with 8 bits or go to ARM (noises on grapevine) for future development.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Tue. May 5, 2015 - 02:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR-Ada does not meet the greater than 64kB RAM requirement; iow, AVR-Ada has 16-bit pointers.

http://sourceforge.net/p/avr-ada/code/ci/master/tree/gcc-4.9-rts/adainclude/system.ads#l88

For Ada a relatively easy alternative is to port the application to ARM Cortex-M or Cortex-R.

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

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

IIRC for a Pascal variant there's LunaAVR; do not know if LunaAVR meets your requirements.

http://avr.myluna.de/doku.php?id=en:about

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

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

I downloaded LunaAVR. I don't know will it count as commercial use if my software is free and open source, but running on my hardware and PCB which I will make and sell for money.

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

Foxcat385 wrote:

I downloaded LunaAVR. I don't know will it count as commercial use if my software is free and open source, but running on my hardware and PCB which I will make and sell for money.


I would say yes, it's commercial ("free software" doesn't mean it's non-commercial).

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

There are a number of embedded Linux and uClinux boards where the PCB layout files are closed source.

Transparency - I have not read the LunaAVR copyright.

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

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

Foxcat385 wrote:

Alright. And is there an alternative AVR compiler rather than BASIC, C, C++ and PASCAL?

 

Let's poke at that for a moment.

 

The way the quoted question is written, it appears that you are asking about computer >>languages<< that might have a compiler that supports an AVr target.  Is that correct?

 

Re the mention of C in your language list...since ONE PARTICULAR FLAVOUR of C compiler that supports an AVR target doesn't have the facility you desire, the entire option of programming in that language is discarded?

 

If indeed your target app is a single 64KB buffer in volatile storage, then what is the problem to work on the simple read and write access primitives?  _memx or whatever, won't they be very localized?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Yes, I discarded C. I had so many problems. Now I'm going to try LunaAVR. BASCOM still works for my school project, though. But when I'll need a video buffer for a touch screen drawing/animating AVR device, I'll use LunaAVR. Hopefully it will have 24/32-bit pointers.

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

BASCOM still works for my school project,

Of course it will not work for anything other than an 8051 or an AVR. When you talk about "video buffer" an image of a 32bit machine comes to mind with enough horse power to process such video.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

But having an AVR as a little device with a screen and external RAM for drawing pixel art and animating is what I've always wanted to have.

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

Foxcat385 wrote:

But having an AVR as a little device with a screen and external RAM for drawing pixel art and animating is what I've always wanted to have.

Why ?

Smarter to find a MCU with enough internal ram for a little device with a screen, and work from there.

Any 8 bit mcu is going to struggle with any Colour display, and drawing pixel art and animating will never be swift.

Only if there were no 32b alternatives for the task, would the idea makes any sense.

 

 

A few moments with google finds

STM32F429I-DISCO, for $24.00, with

• 2.4" QVGA TFT LCD
• 64-Mbit SDRAM

 

or STM32L0538-DISCO  for $23.38, with

• 2.04” E-paper display, 172x72 pixels

 

Not sure if Atmel have anything similar (moderate LCD included ? ) in their xPlained series ?

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

How much time do I need to learn about ARM's context switching, kernel mode, user mode, malloc mechanism, etc.?

Is there an RTOS for C or C++ which I can use? And when I go to ST site to see if there are development programs, none was found for STM32F4. That's weird. Does anyone know if there is a free C/C++ compiler for it? When I searched for more, I saw 3-digited prices of development kits. I barely got BASCOM. I think I should stay with XMEGA with EBI.

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

How much time do I need to learn about ARM's context switching, kernel mode, user mode, malloc mechanism, etc.?

Eh? He's suggesting Cortex-M not Cortex-A. 

 

A Cortex-M is just like an AVR but 32bits not 8bits and usually more RAM and flash for the same money. 

 

There are two main compilers for ARM (well especially now that ARM own Keil). Either the ARM compiler or arm-gcc/arm-g++. 

 

If you use Studio6 and switch between AVR or AVR32 or ARM you almost cannot spot the difference as the compile and link options are virtually identical for all 3 compilers because they're basically all exactly the same compiler. This is the joy of using GCC. Once you know how to use it for one CPU you know how to use it for the 30 or more different architectures it supports. 

 

So a switch from AVR to ARM should be virtually invisible if you are a GCC user. 

 

Of course the peripherals dotted around the CPU core are likely to be different - usually more complex and feature rich than found in AVR (though perhaps not a lot more complex if you are familiar with Xmega). 

 

STM32 CPUs are,  like most Cortex, supported by arm-gcc . 

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

clawson wrote:
If you use Studio6 and switch between AVR or AVR32 or ARM you almost cannot spot the difference as the compile and link options are virtually identical for all 3 compilers because they're basically all exactly the same compiler. This is the joy of using GCC. Once you know how to use it for one CPU you know how to use it for the 30 or more different architectures it supports.

Yeah with progmem and 16-bit pointers *rolls eyes sarcastically*. I hope ARM doesn't have those and that it supports 32-bit pointers natively.

 

I hope there's an RTOS and that STM32 has an MMU so I can have multitasking and virtual memory and that fun stuff. However, I'd also need a good documentation on how exactly low-level-multitasked-kernel-MMU-style-malloc works in ARM operating systems. And I also hope that all applications need just simple malloc usage like in Windows executables so that I don't need to learn anything too complex.

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

How much time do I need to learn about ARM's context switching, kernel mode, user mode, malloc mechanism, etc.?

??? Yet, the effort to incorporate proven get/put "memx" primitives in one particular brand of AVR8 C compiler is too daunting.

 

I'm out.  One model of Chevrolet has 14" wheels, therefore I will never buy or drive a Chevrolet again. 

also there are Ford and Chrysler models with 14" wheels, so they are rejected as well.  That is all models of those brands.  Don't question my logic; just recommend other automobile brands that have no models using 14" wheels.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Foxcat385 wrote:
However, I'd also need a good documentation on how exactly low-level-multitasked-kernel-MMU-style-malloc works in ARM operating systems. And I also hope that all applications need just simple malloc usage like in Windows executables so that I don't need to learn anything too complex.
One possible RTOS, amongst a plethora of RTOS for Cortex, is NuttX.

Its libc has the usual allocators and such; there are options for newlib (maybe others), C++, and Pascal.

NuttX has significant board support for Atmel boards; competitors too.


http://nuttx.org/Documentation/NuttxPortingGuide.html#DirStructLib

http://nuttx.org/doku.php?id=wiki:howtos:newlib-integration

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

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

Foxcat385 wrote:
And when I go to ST site to see if there are development programs, none was found for STM32F4. That's weird.
Maybe STM32Cube.

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1743/LN1897

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

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

Foxcat385 wrote:

How much time do I need to learn about ARM's context switching, kernel mode, user mode, malloc mechanism, etc.?

Is there an RTOS for C or C++ which I can use? And when I go to ST site to see if there are development programs, none was found for STM32F4. That's weird. Does anyone know if there is a free C/C++ compiler for it? When I searched for more, I saw 3-digited prices of development kits. I barely got BASCOM. I think I should stay with XMEGA with EBI.

 

I gave you a part code for a $24 system - you could always actually buy one, and run it up to answer your questions, instead of making wild guesses ?

Clearly, ST are not selling a Board with no means of having it work.

Usually, such board include plenty of reference examples.

 

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

Foxcat385 wrote:
if there is a free C/C++ compiler for it?

You mean "free" as in "free beer" or as in "free software"?

 

avrfreaks does not support Opera. Profile inactive.

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

Free as in you downloaded it and you can do with it whatever you want and there's no strings attached.

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

Foxcat385 wrote:

But having an AVR as a little device with a screen and external RAM for drawing pixel art and animating is what I've always wanted to have.

 

Why do you need to have more than 64K then.

 

Several systems do this just fine with a ATMega644 or less

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

My drawing is a 16-bit bitmap with a resolution of 320×240. That is 153600 bytes which is 2,34375 kBytes. However, that's only one frame of the animation. I need more. I can get that from either external SDRAM/SRAM or a serial RAM which is very slow. I found a VLSI audio chip with an OS and lots of stuff called VS1005 http://www.vlsi.fi/en/products/v... and it has 256 kBytes of RAM and 256 kBytes of ROM. I think it's an 8/32-bit hybrid. It also has a resistive touch screen controller and a LCD screen bus. That might work out. It's just one chip. Plays audio files. The only downside is that it doesn't play MIDI files like VS1053, but hopefully I can get it to use sound effects written in an external flash storage chip as a MIDI soundfont.

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

That is 153600 bytes which is 2,34375 kBytes.

 No, that is 153.6kBytes.

 

320x240 => 76800 pixels.  16-bit color means two bytes per pixel. 

 

7 frames per megabyte.

 

I'd think most animations would not try to re-paint the entire frame.  But that is a big topic.

 

If indeed you are using AVR8, then external memory is limited to 64KB with tricks, or less with "normal" configuration.  That is less than one frame buffer.

 

Indeed, if at a minimum of 15 frames per second (full paint) that would be over 2MB/second needed transfer rate.  For a better 30 or 60 fps, multiply that.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Sorry, I divided by 65536 for some reason instead of 1024. I wasn't even concentrated.

I'll see if VS1005 will work for me. It has 256kB of RAM as I said. The LCD module hopefully has its own RAM and blitting the picture from the internal RAM to the LCD shouldn't be a problem.

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

theusch wrote:
If indeed you are using AVR8, then external memory is limited to 64KB with tricks, or less with "normal" configuration.
For "abnormal" configurations, try XMEGA! cheeky

OOTB, Atmel has a 512kB SRAM XMEGA128A1U board and there are a few third party XMEGA boards that have SRAM (1MB, etc.).

The XMEGA EBI app note mentions the 4 port SDRAM interface if need up to 16MB of RAM; that's only in XMEGA64A1U and XMEGA128A1U.

For GCC and XMEGA, might be easier to use the XMEGA DMA controller to block move data.


http://www.atmel.com/devices/ATXMEGA128A1U.aspx?tab=documents (search for "AVR1312: Using the XMEGA External Bus Interface")

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

Last Edited: Wed. May 13, 2015 - 05:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For "abnormal" configurations, try XMEGA!

Well, we are going full circle here.  OP has discarded any architecture other than AVR8, and also discarded many programming languages as he is not fond of _memx .

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Even more odd, __memx has nothing to do with his requirement as it doesn't support RAM > 64 KiB.  Used on RAM, __memx is just an efficient way to get inefficient code.

avrfreaks does not support Opera. Profile inactive.

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

theusch wrote:

For "abnormal" configurations, try XMEGA!

Well, we are going full circle here.  OP has discarded any architecture other than AVR8, and also discarded many programming languages as he is not fond of _memx .

 

 

No I haven't. I only discarded languages that don't have full 24-bit address space access. I didn't discard other architectures because I said I can use VS1005 or an ARM MPU/MCU that has a RTOS and a free compiler+IDE.

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

How can an 8 bit micro with just 16 address lines ever hope to address more than 64K at a time? There's always going to be some form of bank switching and "64K boundary issues" involved isn't there? The 8088 (and then 8086) are a perfect example of how frustrating this is! The real solution if you want 24+ bit addressing is to pick a CPU that has 24 or more address lines isn't it? (Intel/IBM even got this wrong in the 80286 with the A20 problem - it was only when they reached the 80386 that it offered true linear addressing of large data regions).

 

In the case of the AVR (well mega at least) it's not the supporting languages that are imposing the limits its the CPU architecture. Even the AVRs with an external RAM interface only have 16 address lines (actually 8+8 multiplexed in fact).

 

I just don't understand your reluctance to look at 32bit micros. ARMs have 4GB linear address spaces!

Last Edited: Thu. May 14, 2015 - 02:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought I was out.

 

I only discarded languages that don't have full 24-bit address space access.

What does a language have to do with the size of an address space?  [As I've repeatedly responded, with analogies, is that you are lumping "language" with the capabilities of a particular implementation.]

 

No I haven't. I only discarded languages that don't have full 24-bit address space access. I didn't discard other architectures because I said I can use VS1005 or an ARM MPU/MCU that has a RTOS and a free compiler+IDE.

<eye roll>

Post #1:

 

Please do NOT:

  1. Tell me to move to ARM...

 Post #30:

But having an AVR as a little device with a screen and external RAM for drawing pixel art and animating is what I've always wanted to have.

Couple that with the large frame buffers and the desire for animation -- I'm out.  [even on a decent Android tablet we use support chips and codecs for video capture/annotation/playback]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I'm sorry, but I keep forgetting what I previously said so I've been changing my mind all over. Mostly because I have little money and I'd like to take a one-shot on purchasing a dev board or a PCB that can fit in my pocket like a finished product (and there's a 3D printer in school so I can model the case myself easily. I've been 3D modelling throughout 4 years of high school in AutoCAD and CATiA).

Pages