|
|
| Author |
Message |
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 13 January 2006, 17:06 PM Post subject: |
 |
|
| victorf wrote: | spamiam wrote:
| Quote: | Did you already test the existing API in a test circuit with the FRAM and have no success? If so, what error code did the "Success" variable return (if any)?
|
No, I haven't. I have incorporated the FRAM into the ExpressPCB board layout for my current project. This should go for fabrication next week after I give everything the once-over (for the 100th time - hundredth-over  ). Software writing is under way!
I like your idea of replacing the EEPROM with the FRAM. What is the application you intend for the ATMega/FRAM?
I appreciate your help with this. Thanks
Vic |
I know all about the Nth time of checking. WHen I get my PCB's back, I usually find a GLARING error (or several).
On the RTC/FRAM daughter board, I neglected to place a pull-up one of the clock's pins that needed it. It was easy to add a little resistor across two pins. Problem solved
On my big ATmega project, I neglected to place a resistor in line between the I/O pin of the uC, and a transistor which was used to amplify the signal for a buzzer. Toasted the transistor. So, I had to install a resistor between some SMT pads. Not as easy as between pins. I also had to cut the offending trace.
I also decided I would rather have a different order in the I/O pins going to one of the LCD screens. I saved that change for the inxt iteration of the board.
The application I am designing for the big project (not ZX), is a rally computer. Essentially it is a very very accurate odometer and clock so you can keep track of speed and distance. During a rally you get instructions to drive a certain section at a certain speed. The computer allows you to precisely measure your time errors and, hopefully, keep exactly on time (therefore exactly on speed too).
I am reverse engineering a device because I have a software modification which will compensate for the inaccuracies created by the person who had layed out the course. They usually truncate distances to the 1/100th of a mile, and the times are calculated methematically based on distances. Therefore each truncation they did creates a real-world time error if you are driving at the precise speed they require.
-Tony |
|
| Back to top |
|
 |
victorf
Joined: 01 Jan 2006
Posts: 342
Location: Schenectady, New York
|
|
Posted: 23 January 2006, 15:45 PM Post subject: |
|
|
Spamiam,
May I ask why you did not write the sub-routine FRAM_Write_Data as a function? I have redone it as a function and it seems to be a cleaner way to do things. I simply return the error/write count as an integer. I use exit function any time an error is detected with the idea that once an error occurs there is no sense in continuing.
Am I missing something here 
Any enlightenment will be appreciated.
Vic |
|
| Back to top |
|
|
victorf
Joined: 01 Jan 2006
Posts: 342
Location: Schenectady, New York
|
|
Posted: 15 February 2006, 12:17 PM Post subject: |
|
|
The subroutine FRAM_Write_Data opens the FRAM channel when called and closes it when done. If this is so, then what happens when the user wishes to read data from the FRAM using FRAM_Read_Data? The channel is no longer available for use until it is opened and initialized. The documentation in ZBasicSysRef for the I2CCmd shows a call to I2COpen (should read OpenI2C) before calling I2CCmd.
Am I missing something in reading the API code? 
Vic |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Posts: 2593
Location: Portland, OR
|
|
Posted: 15 February 2006, 16:49 PM Post subject: |
|
|
| Quote: | | The documentation in ZBasicSysRef for the I2CCmd shows a call to I2COpen (should read OpenI2C) before calling I2CCmd. |
Calling I2COpen() stores the channel data in an internal data structure where it is accessed by all subsequent I2CCmd() calls. The channel data remains valid until the chip resets or it is otherwise changed.
Other than a slight execution time penalty, there is no harm in calling OpenI2C multiple times with the same channel data. |
|
| Back to top |
|
|
spamiam
Joined: 13 Nov 2005
Posts: 689
|
|
Posted: 16 February 2006, 13:54 PM Post subject: |
|
|
| victorf wrote: | The subroutine FRAM_Write_Data opens the FRAM channel when called and closes it when done. If this is so, then what happens when the user wishes to read data from the FRAM using FRAM_Read_Data? The channel is no longer available for use until it is opened and initialized. The documentation in ZBasicSysRef for the I2CCmd shows a call to I2COpen (should read OpenI2C) before calling I2CCmd.
Am I missing something in reading the API code?
Vic |
Well, I certainly do not say that the code is effiecient as possible!!
I have not re-read my code as I write this, but my plan when writing this code was to have it as free from screw-ups as possible.
I was working under the assumption that there could be multiple I2C channels in use at one time. I also suipposed that maybe some other subrouting (or function!) might mess with the channels. So, I wanted to start with a clean, known-state for the I2C channel.
However, this is probably overkill.
Also, I bet there are some left-overs from the development stages in the code. This COULD be one of those left-overs. It may have escaped my eye and since it did not SEEM to cause problems (it was tested in an environment which only had 1 I2C channel in use and its parameters never changed), I may never have focused on it as a problem.
Feel free to clean/modify and post your improved versions. I had only intended this code to be a starting point and an example of something that works. More variations/improvements are excellent!!!
-Tony |
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register