Thread: [Flashforth-devel] free flash memory on atmega devices
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Ronny S. <man...@te...> - 2015-11-14 11:39:09
|
Hi I'm new to flashforth , but not new to forth. I have this question: I have downloaded the 'free.txt' program included in the forth directory. I notice on an atmega2560 that there is only about 45kbytes free , and on the mega1284p only 35kbytes (approx.) This is strange to me because the atmega2560 has 256kbytes flash and the atmega1284 has 128kbytes flash. The ram and eeprom free spaces look correct. What am I overlooking ??? Kind regards , Ronny Suy |
|
From: Mikael N. <mik...@fl...> - 2015-11-14 16:08:14
|
By design FlashForth can only address 64 Kbytes of memory. FF maps flash, ram and eeprom into one 16-bit address space. @ and ! can then be used with all types of memory. The free flash should be about 45 Kbytes on chips that have 8 K ram and 4 K eeprom. The FF kernel size is 8,5 Kbytes. The mega1284 has 16 K of ram so only 36 K is left as free flash memory. BR Mikael |
|
From: Donald G. <dgo...@sb...> - 2015-11-15 17:54:49
|
You should have an extended memory word to address all of memory, right?
Since this is a 16 bit Forth implementation, it is understandable that it can only address 64K words. However, we should be able to address all of the memory for data in the processor.
I haven't started using FlashForth yet, so my comments are not based on knowledge of FlashForth.
Don
On Saturday, November 14, 2015 8:08 AM, Mikael Nordman <mik...@fl...> wrote:
By design FlashForth can only address 64 Kbytes of memory.
FF maps flash, ram and eeprom into one 16-bit address space.
@ and ! can then be used with all types of memory.
The free flash should be about 45 Kbytes on chips that have 8 K ram and
4 K eeprom.
The FF kernel size is 8,5 Kbytes.
The mega1284 has 16 K of ram so only 36 K is left as free flash memory.
BR Mikael
------------------------------------------------------------------------------
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2015-11-15 19:00:09
|
You are right that extended memory words could be made for data storage or even for code in flash. But I have chosen not to implement that, since there has been no demand. All my FF programs have been fairly compact fitting well within the 16-bit limits. One reason to support the larger chips is to get access to the peripherals, even if all memory cannot be adressed. Another alternative would be to implement a 32-bit FF. Then all memory would be adressable. BR Mikael On 15.11.2015 19:41, Donald Golding wrote: > You should have an extended memory word to address all of memory, > right? > > Since this is a 16 bit Forth implementation, it is understandable > that > it can only address 64K words. However, we should be able to address > all of the memory for data in the processor. > > I haven't started using FlashForth yet, so my comments are not based > on knowledge of FlashForth. > > Don > |
|
From: Donald G. <dgo...@sb...> - 2015-11-16 16:47:54
|
I don't think a 32 bit version of FlashForth would be necessary. You can build a very complex application in Forth just using the 16 bit implementation.
If you need a request for extended memory words, I will vote yes they are needed. Users can then put arrays, small databases of sensor data logging, etc. in this space...
I will need these words in the future, myself.
Great job on the design of FlashForth, keep up the good work!Don
On Sunday, November 15, 2015 11:00 AM, Mikael Nordman <mik...@fl...> wrote:
You are right that extended memory words could be made
for data storage or even for code in flash.
But I have chosen not to implement that, since there has been no
demand.
All my FF programs have been fairly compact fitting well within the
16-bit limits.
One reason to support the larger chips is to get access to the
peripherals, even if
all memory cannot be adressed.
Another alternative would be to implement a 32-bit FF. Then all memory
would be adressable.
BR Mikael
On 15.11.2015 19:41, Donald Golding wrote:
> You should have an extended memory word to address all of memory,
> right?
>
> Since this is a 16 bit Forth implementation, it is understandable
> that
> it can only address 64K words. However, we should be able to address
> all of the memory for data in the processor.
>
> I haven't started using FlashForth yet, so my comments are not based
> on knowledge of FlashForth.
>
> Don
>
------------------------------------------------------------------------------
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@fl...> - 2016-04-05 20:05:16
|
So now FlashForth has extended memory fetch and store words. X@ and X! These can fetch and store 16-bit cells from/to any address in flash. Except the kernel cannot be stored to. The address is a direct unmapped address. Tested on Atmega and PIC24. Some testing still required on PIC18, but since I don't have any chips with large memory I cannot test. BR Mikael On 16.11.2015 19:33, Donald Golding wrote: > I don't think a 32 bit version of FlashForth would be necessary. You > can build a very complex application in Forth just using the 16 bit > implementation. > > If you need a request for extended memory words, I will vote yes they > are needed. Users can then put arrays, small databases of sensor data > logging, etc. in this space... |
|
From: <zd...@al...> - 2016-04-06 21:09:18
|
If you send me a test program, I can try it on 18F66K22. |
|
From: Mikael N. <mik...@fl...> - 2016-04-07 05:14:36
|
On 06.04.2016 23:29, zd...@al... wrote: > If you send me a test program, I can try it on 18F66K22. > If you send me your configuration files I can compile a hex file. Or you can pull it from git, and compile it yourself. You need to configure #define IDLE_MODE DISABLE ; ENABLE or DISABLE #define XSTORE ENABLE To fit the code using the default linker file you need to disable some functionality so that the X! X@ gets some room. Mike |
|
From: <zd...@al...> - 2016-04-07 13:52:19
|
Sure, I get the part with compiling. What i didn't get is that the last version is on git, while on sourceforge it is not updated. 'Test program' that I've been talking about should be a few lines in forth. I guess it means to try reading & writing FLASH locations which are now mapped as RAM and EEPROM. Zdravko |
|
From: Mikael N. <mik...@fl...> - 2016-04-07 14:05:20
|
I did not update the ZIP file yet in SF. Only the GIT is updated on SF and GITHUB Testing is basically #send pic18/forth/xdump.txt hex 1234 07020. x! 07000. 30 xdump dead 0f010. x! 0f010. 10 xdump f010 10 dump \ Check that the data does not go ram, but flash babe 0fff0. x! 0fff0. 10 xdump fff0 10 dump \ check that the kernel is write protected 4567 ' marker 0 x! \ shud cause an address error. BR Mike |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X