| View previous topic :: View next topic |
| Author |
Message |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
| Typemod limitations? |
 Posted: Mon Feb 27, 2006 12:08 pm |
 |
|
18F452 @40MhZ CCS 3.242
Does anyone know the limitations of typemod?
Is it the limit of the chip? 16 bit addresses?
I have 4 frams that address from 0x0 to 0x1FFFF
thats bigger than the int16 address.
When I use my own functions it works.
When I use typemod, It fails.
http://www.ccsinfo.com/faq/?57 |
|
 |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Mon Feb 27, 2006 2:01 pm |
|
|
CCS reply
This message is a reply to CCS e-mail id: 6B6505
The address can be 24 bits but the range needs to be 16 bits. So you can do 0x10000 to 0x1ffff. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Mon Feb 27, 2006 4:05 pm |
|
|
I don't think CCS has this correct.
This code works.
| Code: | #include <18F452.H>
#use delay(clock=40000000)
#fuses h4,nowdt,noprotect,nolvp
#use rs232(baud=19200,xmit=PIN_C0,invert,stream=DEBUG,disable_ints) // stderr(same as debug)
#case
#zero_ram
int8 ERRORS;
#define FRAM_CHIPS 4
#include "FM24C256.C"
#include <74595.C>
#define def_size 2700
//----------prototypes--------
void init_fram();
multi_read_fram (int32 address,int8 *data,int8 size);
multi_write_fram(int32 address,int8 *data,int8 size);
typemod <,multi_read_fram, multi_write_fram,0x00000,0x07FFF>fram_a;//24 bit address ,16 bit range
typemod <,multi_read_fram, multi_write_fram,0x07FFF,0x0FFFF>fram_b;
struct a_struc
{ int32 a;
int32 b;
int32 c;
}fram_a AA[def_size];//2700 12 byte objects
struct b_struc
{ int32 a;
int32 b;
int32 c;
}fram_b BB[def_size];
//============== MAIN =============//
void main(void)
{
int16 cnt;
struct a_struc local_a;//local to main
struct b_struc local_b;//local to main
setup_adc_ports(NO_ANALOGS);
set_tris_a(0);set_tris_b(0);set_tris_c(0);set_tris_d(0);set_tris_e(0);
output_low(PIN_C5);//tx enable
output_high(PIN_C6);
fprintf(DEBUG,"Start\n\r");
init_fram();
//----------------------//
for (cnt=0;cnt<def_size;cnt++){
local_a.a=cnt+0;
local_a.b=cnt+1;
local_a.c=cnt+2;
//=========//
local_b.a=cnt+3;
local_b.b=cnt+4;
local_b.c=cnt+5;
//=========//
AA[cnt]=local_a;//write to fram
BB[cnt]=local_b;//write to fram
}
for (cnt=0;cnt<def_size;cnt++){
local_a=AA[cnt];//read from fram
local_b=BB[cnt];//read from fram
if (local_a.a!=cnt+0)fprintf(DEBUG,"a[%lu].a=%ld\n\r",cnt,local_a.a);
if (local_a.b!=cnt+1)fprintf(DEBUG,"a[%lu].b=%ld\n\r",cnt,local_a.b);
if (local_a.c!=cnt+2)fprintf(DEBUG,"a[%lu].c=%ld\n\r",cnt,local_a.c);
//=======//
if (local_b.a!=cnt+3)fprintf(DEBUG,"b[%lu].a=%ld\n\r",cnt,local_b.a);
if (local_b.b!=cnt+4)fprintf(DEBUG,"b[%lu].b=%ld\n\r",cnt,local_b.b);
if (local_b.c!=cnt+5)fprintf(DEBUG,"b[%lu].c=%ld\n\r",cnt,local_b.c);
}
fprintf(DEBUG,"DONE !\n\r");
while(1)
{
}
}
|
The above code works. Change these 2 lines below and it fails. Steping through with debugger show the same address used for both.
| Code: | typemod <,multi_read_fram, multi_write_fram,0x00000,0x0FFFF>fram_a;//24 bit address ,16 bit range
typemod <,multi_read_fram, multi_write_fram,0x10000,0x1FFFF>fram_b;
|
I did follow the rules, ??right?? 24 bit address(I used 20) and 16 bit range.
?why did it fail? |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Tue Jul 25, 2006 5:37 pm |
|
|
Does multi_write_fram() need to halt while the chip is busy?
I just thought about to use it with a big external buffered flash memory. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Wed Jul 26, 2006 8:12 am |
|
|
I'm not sure what your asking.
A busy signal seems logical, yet there is no mention in spec of FRAM for busy. Perhaps the read/write are set faster that I2C data can come in/out.
| Quote: | Unlike other nonvolatile memory technologies,
there is essentially no write delay with FRAM. |
These FRAMs are very fast.
BTW...I wouldn't use the FRAM firmware for a different chip(external flash chip). if that is what you wanted to do ??? |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Wed Jul 26, 2006 10:01 am |
|
|
I meaned to use the first kilobytes of a 32megabit flash.
They are buffered, so the writes can be fast... but aren't saved every time.
How big FRAM's can grow? |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Thu Jul 27, 2006 7:37 pm |
|
|
I have an application that mirrors the eeprom contents to a ram struct at boot up. I can change data and burn back via rs232 commands.
When I drew the board I left an i2c header plus +5 and gnd signals near the pic. It can be used, but will be the last alternative.
With the current hardware, if I am changing the data and power fails I loose all changes. This struct is the heart of the product.
I could map this struct to the eeprom and save changes in realtime and save near 256 bytes of ram ( the mirror ).
The drawback is the 2mS write delay of the eeprom (the app can't hang for so long). I dont know how the compiler deals with asynch writes... I'd have to make sure to not write 2 bytes in a row.
There is the overhead to access the data, a few instructions... I know.
You seem more experienced than me, maybe you could help me to see a light.
Thank you. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Jul 28, 2006 7:23 am |
|
|
I think I would have started with FRAMs and not used the EPROM at all.
I do know about FRAMs. But I know very little about eproms.
I don't know of a solution to your problem. I'm not sure I understand
the entire problem yet. If your eproms are I2C eproms and DIP8 pkg perhaps you can just swap them out with the FRAMs. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Jul 28, 2006 7:31 am |
|
|
After re-reading, Are you simply saying that you don't have backup power
that will last long enough to write changes to an EPROM?? |
|
|
future
Joined: 14 May 2004
Posts: 330
|
|
| Posted: Fri Jul 28, 2006 10:48 am |
|
|
| Yes, and I am using the internal eeprom. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Jul 28, 2006 11:52 am |
|
|
You could use the FRAM for "save work when loss of power" option.
keep your data there, and in/out count ((like a buffer))
Then if power goes out you can find out where you stopped.
Find out if you were still writting somthing (in!=out) then
roll the count back a little and restart the writing of internal EPROM |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
