MY guess is the OP wants a parallel bus because he mistakenly thinks
it's faster, because he hasn't taken the time to analyse the various
options and determine what really works best for him. Of course I could
be wrong ;@}

Al

Donald H wrote:
>
> --- In m..., "CHAD" wrote:
>>
>> A29L160A uses a parallel bus interface and MSP430F5438 devices
>> are not designed to interface with such devices.
>
> Sure they are.
>
> The A29L160A needs 20 Address line and 16 Data line and 4 control lines, thats 40 pins on the MSP430F5438, its got .
>
> Bit Bang the control lines, no problem.
>
> Speed ? slow !
>
> SPI would be faster and easier, but the OP wants a parallel buss.
>
> Can be done, just read the fine manuals. ;-)
>
> don
> Start a New Thread

It's me again. I am not that familiar with MSP430 and C, that's why I gave only a hint, but I am programming microprocessors since thirty years, all projects with 6502 micros and one with an NXP ARM micro.
I was able to use the ARM micro without any special ARM knowledge because I used Forth as programming language. Forth deals with all the low level problems, and with using Forth it is very easy to emulate a memory bus. I did this several times to access RAM with a onechip micro. Works fine.

Anyway, when I checked the MSP430F5438 datasheet I recognized I/O named A0, A1,... up to A15 and my first idea was to suggest to use the external memory mode of the MSP430F5438 - but I did not find the data bus. May be the project assumed the same without recognizing that these I/O pins are Analog Inputs instead of adress lines. Things happen.

I personally would prefer a serial FLASH, not because there are Appnotes available, but because a serial FLASH is much smaller than a parallel FLASH, and much cheaper than a parallel FLASH - important if this part goes into production. I am pretty sure it is even cheaper to design an adaptor to put a serial FLASH in place if the PCB cannot be changed.

I myself would be happy to be allowed to have the MSP430F5438 with it's huge amount of FLASH and RAM and I would immediately load a Forth operating system on it which gives a quadrupling boost in developing software - especially for somebody who doesn't have a lot of experience in programming.

I have to deal with a MSP430F2012 because of pricing - too small for Forth, and I have to deal with C which totally slows me down.

Good luck!

Dirk

--- In m..., OneStone wrote:
>
> MY guess is the OP wants a parallel bus because he mistakenly thinks
> it's faster, because he hasn't taken the time to analyse the various
> options and determine what really works best for him. Of course I could
> be wrong ;@}
>
> Al
>
> Donald H wrote:
> >
> > --- In m..., "CHAD" wrote:
> >>
> >> A29L160A uses a parallel bus interface and MSP430F5438 devices
> >> are not designed to interface with such devices.
> >
> > Sure they are.
> >
> > The A29L160A needs 20 Address line and 16 Data line and 4 control lines, thats 40 pins on the MSP430F5438, its got .
> >
> > Bit Bang the control lines, no problem.
> >
> > Speed ? slow !
> >
> > SPI would be faster and easier, but the OP wants a parallel buss.
> >
> > Can be done, just read the fine manuals. ;-)
> >
> > don
> >
> >
> >
> >
> >
> >
> >
> >
> > Start a New Thread

Thanks for the feedbacks so far...

Can you guys propose serial Flash which operate between 12 - 15 MHz and can be accessed over SPI..

Start a New Thread

SST25VF016B - datasheet at http://www.sst.com/dotAsset/40371.pdf
I also use a SST25VF with my project, but a smaller SST25VF080B, never had a problem. I can send sample programs for the one I used.
Prices for single quantities at Digikey are:
SST25VF016B-50-4C-QAF (Consumer, $1.78USD) or SST25VF016B-50-4I-QAF (Industrial, $2.14USD)
Websites:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF016B-50-4C-QAF-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF016B-50-4I-QAF-ND

These are specified with 50MHz, but you can use them with 12 - 15 MHz, no problem.

Regards,
Dirk

--- In m..., waqar.ahmed@... wrote:
>
> Thanks for the feedbacks so far...
>
> Can you guys propose serial Flash which operate between 12 - 15 MHz and can be accessed over SPI..
>

Start a New Thread

I have an image sensor operating at 12 MHz (Micron Digital Image sensor MT9V131).

The registers on image sensor are written from MSP430F5438 over I2C to get the desired output image quality.
The image sensor will then be activated from MSP430F5438 upon an interrupt from a sensor.

The outputs from Image sensor are: 8 bit parallel data i.e. 1 pixel , frame valid, pixel valid and PixClock. (15 frames per second at 12 MHz, 649x489 Pixel per frame)

Then I want to store (only 4th frame i.e. 2.538888 Mega Bits) from the output of image sensor to a FLASH. This is done by using a comparator controlled form MSP....
Once the 4th frame is stored on flash the image sensor is shutdown from MSP430....

MSP430F5438 will then access two frames (stored at different times) and check if there is any difference in these frames to detect intrusion.

Question:

The legacy image sensor I am using outputs a continuous stream of frames, but I only need one frame for my project. Can someone propose a very low power "still camera" image sensor which outputs only frame (thats what I need)??

If both read and writes on flash are from MSP430F5430 over SPI then this is simple but in my project image senor is writing and MSP is reading.
If I use serial flash (with SPI communication), how can I write the output form image sensor to flash and later read from MSP30F5438??

May be, I can use 8 bit parallel to serial converter for converting the 8 bit output of image sensor then save it on Flash, but I am not clear how the communication will be handled, as the MOSI input to Flash is coming from MSP...., any ideas how output from image sensor can be integrated to MOSI?
{my idea is to retrieve output from image senor at MSP430F5438 over SPI, and then from MSP.... save this on external serial flash over SPI, but Pixel clock form MSP is 12 MHz and MSP430F5438 clock frequency is max 8 MHz, so there is a speed mismatch, don't know if I a right!}

Please bear with me if I am asking too many basic questions!

Thanks in advance

WA
From: m... [mailto:m...] On Behalf Of bluebee2010
Sent: 16 July 2010 10:45
To: m...
Subject: [msp430] Re: Interface between Flash (AMIC A29L160A Series, Boot Sector Flash) and MCU (MSP430F5438IPZ)

SST25VF016B - datasheet at http://www.sst.com/dotAsset/40371.pdf
I also use a SST25VF with my project, but a smaller SST25VF080B, never had a problem. I can send sample programs for the one I used.
Prices for single quantities at Digikey are:
SST25VF016B-50-4C-QAF (Consumer, $1.78USD) or SST25VF016B-50-4I-QAF (Industrial, $2.14USD)
Websites:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF016B-50-4C-QAF-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF016B-50-4I-QAF-ND

These are specified with 50MHz, but you can use them with 12 - 15 MHz, no problem.

Regards,
Dirk

--- In m..., waqar.ahmed@... wrote:
>
> Thanks for the feedbacks so far...
>
> Can you guys propose serial Flash which operate between 12 - 15 MHz and can be accessed over SPI..
>
Pera Innovation Ltd. Company registered in England and Wales, No.01941113. Registered address Nottingham Road, Melton Mowbray LE13 0PB. Pera Innovation Ltd may monitor email traffic data and also the content of email for the purposes of security.


Start a New Thread

Microprocessors are a world of difference from microcontrollers. You
have hit one of the issues I personally have against the concept that
you can design good systems with separate people doing the hardware and
software, or with software guys who no no hardware. Sure C hides a lot
of the hardware from you. That doesn't make it a good thing. And this is
one of the places where it falls down badly. I'm not having a go
personally at you, but you have been tasked with a design for which you
lack the necessary skills to totally analyse it, despite 30 years
programming. The reason is simply that this isn't a programming issue,
unlike most things in the microprocessor world, where a knowledge of the
hardware can regularly be bypassed. In the microcontroller domain good
design requires hardware knowledge.

You may have been able to emulate a memory bus in Forth, you can do it
in most languages, but could you, at the outset, evaluate the
performance of that bus? how long each memory access took, whether that
timing was constant or varied with address, data size, etc, before ever
writing code to test. ie could you determine before hardware was built,
at cost whether or not a given microcontroller and memory combination
would meet the design requirements. Again without hardware knowledge
this can't be done.

Why are you stuck with C. putting this application into a 2012 is
probably more in the domain of assembler. I don't know how much more
there is to the system than obviously reading an image from somewhere
and then writing it to a memory chip, and then, I presume, somehow
downloading or retrieving that data. This can certainly be done with a
2012, but without intimate knowledge of the compiler, how to order
instructions or which instructions or forms to use to get the best out
of the compiler I think you're going to struggle. The same goes if you
don't understand enough about the hardware to optimise the I/O
distribution. And if a hard ware specialist is doing this, unless he has
a thorough understanding of how the software will need to be implemented
then you may be fighting a far from optimal configuration.

For a suitable paret you could try the M25PE16 from Numonyx, or the
M45PE16 from ST, both work at well over 25MHz.

Cheers

Al

bluebee2010 wrote:
> It's me again. I am not that familiar with MSP430 and C, that's why I gave only a hint, but I am programming microprocessors since thirty years, all projects with 6502 micros and one with an NXP ARM micro.
> I was able to use the ARM micro without any special ARM knowledge because I used Forth as programming language. Forth deals with all the low level problems, and with using Forth it is very easy to emulate a memory bus. I did this several times to access RAM with a onechip micro. Works fine.
>
> Anyway, when I checked the MSP430F5438 datasheet I recognized I/O named A0, A1,... up to A15 and my first idea was to suggest to use the external memory mode of the MSP430F5438 - but I did not find the data bus. May be the project assumed the same without recognizing that these I/O pins are Analog Inputs instead of adress lines. Things happen.
>
> I personally would prefer a serial FLASH, not because there are Appnotes available, but because a serial FLASH is much smaller than a parallel FLASH, and much cheaper than a parallel FLASH - important if this part goes into production. I am pretty sure it is even cheaper to design an adaptor to put a serial FLASH in place if the PCB cannot be changed.
>
> I myself would be happy to be allowed to have the MSP430F5438 with it's huge amount of FLASH and RAM and I would immediately load a Forth operating system on it which gives a quadrupling boost in developing software - especially for somebody who doesn't have a lot of experience in programming.
>
> I have to deal with a MSP430F2012 because of pricing - too small for Forth, and I have to deal with C which totally slows me down.
>
> Good luck!
>
> Dirk
>
> --- In m..., OneStone wrote:
>> MY guess is the OP wants a parallel bus because he mistakenly thinks
>> it's faster, because he hasn't taken the time to analyse the various
>> options and determine what really works best for him. Of course I could
>> be wrong ;@}
>>
>> Al
>>
>> Donald H wrote:
>>> --- In m..., "CHAD" wrote:
>>>> A29L160A uses a parallel bus interface and MSP430F5438 devices
>>>> are not designed to interface with such devices.
>>> Sure they are.
>>>
>>> The A29L160A needs 20 Address line and 16 Data line and 4 control lines, thats 40 pins on the MSP430F5438, its got .
>>>
>>> Bit Bang the control lines, no problem.
>>>
>>> Speed ? slow !
>>>
>>> SPI would be faster and easier, but the OP wants a parallel buss.
>>>
>>> Can be done, just read the fine manuals. ;-)
>>>
>>> don
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Start a New Thread

Ahmed,

I believe your timing is way off.

Having found a data sheet for this image sensor:
http://www.aptina.com/assets/downloadDocument.do?idX4

At 12Mhz you will need to capture a byte every 83 nanoseconds !!
At 27Mhz you will need to capture a byte every 37 nanoseconds !!!!

There is no MSP43 part that will keep up with that data rate.

I do not believe _any_ single chip processor can keep up with that data rate, MSP430 or not.

Also, sending data to the FLASH chip at 83nSec per byte, will not work. Writing to a FLASH chip is even slower.

See that data sheet to understand why.
Good Luck on this project.

don

PS: There are no bad questions, there are only bad assumptions.
If you would have made it clear what you were doing from the first post, we could have steered you in another direction sooner.

--- In m..., "Ahmed, Waqar" wrote:
>
> I have an image sensor operating at 12 MHz (Micron Digital Image sensor MT9V131).
>
> The registers on image sensor are written from MSP430F5438 over I2C to get the desired output image quality.
> The image sensor will then be activated from MSP430F5438 upon an interrupt from a sensor.
>
> The outputs from Image sensor are: 8 bit parallel data i.e. 1 pixel , frame valid, pixel valid and PixClock. (15 frames per second at 12 MHz, 649x489 Pixel per frame)
>
> Then I want to store (only 4th frame i.e. 2.538888 Mega Bits) from the output of image sensor to a FLASH. This is done by using a comparator controlled form MSP....
> Once the 4th frame is stored on flash the image sensor is shutdown from MSP430....
>
> MSP430F5438 will then access two frames (stored at different times) and check if there is any difference in these frames to detect intrusion.
>
> Question:
>
> The legacy image sensor I am using outputs a continuous stream of frames, but I only need one frame for my project. Can someone propose a very low power "still camera" image sensor which outputs only frame (thats what I need)??
>
> If both read and writes on flash are from MSP430F5430 over SPI then this is simple but in my project image senor is writing and MSP is reading.
> If I use serial flash (with SPI communication), how can I write the output form image sensor to flash and later read from MSP30F5438??
>
> May be, I can use 8 bit parallel to serial converter for converting the 8 bit output of image sensor then save it on Flash, but I am not clear how the communication will be handled, as the MOSI input to Flash is coming from MSP...., any ideas how output from image sensor can be integrated to MOSI?
> {my idea is to retrieve output from image senor at MSP430F5438 over SPI, and then from MSP.... save this on external serial flash over SPI, but Pixel clock form MSP is 12 MHz and MSP430F5438 clock frequency is max 8 MHz, so there is a speed mismatch, don't know if I a right!}
>
> Please bear with me if I am asking too many basic questions!
>
> Thanks in advance
>
> WA
> From: m... [mailto:m...] On Behalf Of bluebee2010
> Sent: 16 July 2010 10:45
> To: m...
> Subject: [msp430] Re: Interface between Flash (AMIC A29L160A Series, Boot Sector Flash) and MCU (MSP430F5438IPZ)
> SST25VF016B - datasheet at http://www.sst.com/dotAsset/40371.pdf
> I also use a SST25VF with my project, but a smaller SST25VF080B, never had a problem. I can send sample programs for the one I used.
> Prices for single quantities at Digikey are:
> SST25VF016B-50-4C-QAF (Consumer, $1.78USD) or SST25VF016B-50-4I-QAF (Industrial, $2.14USD)
> Websites:
> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF016B-50-4C-QAF-ND
> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=SST25VF016B-50-4I-QAF-ND
>
> These are specified with 50MHz, but you can use them with 12 - 15 MHz, no problem.
>
> Regards,
> Dirk
>
> --- In m..., waqar.ahmed@ wrote:
> >
> > Thanks for the feedbacks so far...
> >
> > Can you guys propose serial Flash which operate between 12 - 15 MHz and can be accessed over SPI..
> >
> Pera Innovation Ltd. Company registered in England and Wales, No.01941113. Registered address Nottingham Road, Melton Mowbray LE13 0PB. Pera Innovation Ltd may monitor email traffic data and also the content of email for the purposes of security.
>
>

Start a New Thread

--- In m..., OneStone wrote:
>
> Microprocessors are a world of difference from microcontrollers.
> You have hit one of the issues I personally have against the
> concept that you can design good systems with separate people
> doing the hardware and software, or with software guys who no no
> hardware. Sure C hides a lot of the hardware from you. That
> doesn't make it a good thing. And this is one of the places
> where it falls down badly. I'm not having a go personally at you,
> but you have been tasked with a design for which you lack the
> necessary skills to totally analyse it, despite 30 years
> programming. The reason is simply that this isn't a programming
> issue, unlike most things in the microprocessor world, where a
> knowledge of the hardware can regularly be bypassed. In the
> microcontroller domain good design requires hardware knowledge.
>
> You may have been able to emulate a memory bus in Forth, you can
> do it in most languages, but could you, at the outset, evaluate
> the performance of that bus? how long each memory access took,
> whether that timing was constant or varied with address, data
> size, etc, before ever writing code to test. ie could you
> determine before hardware was built, at cost whether or not a
> given microcontroller and memory combination would meet the
> design requirements. Again without hardware knowledge this
> can't be done.
>
> Why are you stuck with C. putting this application into a 2012
> is probably more in the domain of assembler. I don't know how
> much more there is to the system than obviously reading an
> image from somewhere and then writing it to a memory chip, and
> then, I presume, somehow downloading or retrieving that data.
> This can certainly be done with a 2012, but without intimate
> knowledge of the compiler, how to order instructions or which
> instructions or forms to use to get the best out of the
> compiler I think you're going to struggle. The same goes if
> you don't understand enough about the hardware to optimise the
> I/O distribution. And if a hard ware specialist is doing this,
> unless he has a thorough understanding of how the software will
> need to be implemented then you may be fighting a far from
> optimal configuration.
>
> For a suitable paret you could try the M25PE16 from Numonyx,
> or the M45PE16 from ST, both work at well over 25MHz.
>
> Cheers
>
> Al
>

Some of those who can't understand hardware want want others to send them samples in c.

Start a New Thread

Hi Al,

I am the one who wrote about his experience about Forth, and Ahmed is the one with the project in question.

Ahmed's question was "Can you guys propose serial Flash which operate between 12 - 15 MHz and can be accessed over SPI....." and so I suggested a reliable serial SPI FLASH, adding prices and webaddresses to order.

Last night when I wrote these lines you are questioning, only Ahmed did know the other parts of his project. If I would have known that there is an image sensor involved, my answer would have been nearly the same Donald gave. I used one of the first Fairchild image sensors long ago, the frame grabber was on S100 bus cards. To analyze the pictures, my customer at the EMBL used a Rockwell AIM 65 computer, emulating the S100 bus.

I appreciate your opinion that in this business you need to have knowledge in hardware a n d software. This belongs to my knowledge, too. I started my career with hardware, and when I got my first microprocessor to work with, I recognized immediately that the right mix between hardware and software is the most important point in microprocessor system design. A lot of managers did not understand this, and a lot of money on projects has been wasted ever since because of dividing development in hardware and software issues. You only get an optimum when having both in mind, hardware and software.

Everything you are putting in hardware, you have to pay for with each manufactured piece. The cost of software per piece will go lower with each. That's why in all my projects I did as much as possible in software. Of course, nowadays you do not need software for a lot of things which are incorporated into a microcontroller. That's the beauty of it. That means with every generation of microprocessors / microcontrollers you have to rethink, of course, may be even with each project.

When mentioning that I could use the ARM micro with Forth, I wrote "without any s p e c i a l A R M knowledge" - but hardware knowledge was essential, of course. I supposed everybody knows this. Did you ever program in Forth?

Cheers!
Dirk

P.S.: Using Forth to emulate a bus system is much easier than in any other programming language, and the behavior is predictable. When coded, the read- and write-commands are added to the existing Forth commands, because Forth is extensible. When done, you use these new read- and write-commands and never have to think about it again.
Of course you may have to use different programming styles depending on speed restraints, you even may need assembly language for this.
The best thing with emulating was when using Harris/Intersils RTX2000. It's a pity that this microprocessor, specially designed for Forth, based on a design by Chuck Moore, the inventor of Forth, is only used in its radiation hardened version in space applications.

--- In m..., OneStone wrote:
>
> Microprocessors are a world of difference from microcontrollers. You
> have hit one of the issues I personally have against the concept that
> you can design good systems with separate people doing the hardware and
> software, or with software guys who no no hardware. Sure C hides a lot
> of the hardware from you. That doesn't make it a good thing. And this is
> one of the places where it falls down badly. I'm not having a go
> personally at you, but you have been tasked with a design for which you
> lack the necessary skills to totally analyse it, despite 30 years
> programming. The reason is simply that this isn't a programming issue,
> unlike most things in the microprocessor world, where a knowledge of the
> hardware can regularly be bypassed. In the microcontroller domain good
> design requires hardware knowledge.
>
> You may have been able to emulate a memory bus in Forth, you can do it
> in most languages, but could you, at the outset, evaluate the
> performance of that bus? how long each memory access took, whether that
> timing was constant or varied with address, data size, etc, before ever
> writing code to test. ie could you determine before hardware was built,
> at cost whether or not a given microcontroller and memory combination
> would meet the design requirements. Again without hardware knowledge
> this can't be done.
>
> Why are you stuck with C. putting this application into a 2012 is
> probably more in the domain of assembler. I don't know how much more
> there is to the system than obviously reading an image from somewhere
> and then writing it to a memory chip, and then, I presume, somehow
> downloading or retrieving that data. This can certainly be done with a
> 2012, but without intimate knowledge of the compiler, how to order
> instructions or which instructions or forms to use to get the best out
> of the compiler I think you're going to struggle. The same goes if you
> don't understand enough about the hardware to optimise the I/O
> distribution. And if a hard ware specialist is doing this, unless he has
> a thorough understanding of how the software will need to be implemented
> then you may be fighting a far from optimal configuration.
>
> For a suitable paret you could try the M25PE16 from Numonyx, or the
> M45PE16 from ST, both work at well over 25MHz.
>
> Cheers
>
> Al
>
> bluebee2010 wrote:
> >
> >
> > It's me again. I am not that familiar with MSP430 and C, that's why I gave only a hint, but I am programming microprocessors since thirty years, all projects with 6502 micros and one with an NXP ARM micro.
> > I was able to use the ARM micro without any special ARM knowledge because I used Forth as programming language. Forth deals with all the low level problems, and with using Forth it is very easy to emulate a memory bus. I did this several times to access RAM with a onechip micro. Works fine.
> >
> > Anyway, when I checked the MSP430F5438 datasheet I recognized I/O named A0, A1,... up to A15 and my first idea was to suggest to use the external memory mode of the MSP430F5438 - but I did not find the data bus. May be the project assumed the same without recognizing that these I/O pins are Analog Inputs instead of adress lines. Things happen.
> >
> > I personally would prefer a serial FLASH, not because there are Appnotes available, but because a serial FLASH is much smaller than a parallel FLASH, and much cheaper than a parallel FLASH - important if this part goes into production. I am pretty sure it is even cheaper to design an adaptor to put a serial FLASH in place if the PCB cannot be changed.
> >
> > I myself would be happy to be allowed to have the MSP430F5438 with it's huge amount of FLASH and RAM and I would immediately load a Forth operating system on it which gives a quadrupling boost in developing software - especially for somebody who doesn't have a lot of experience in programming.
> >
> > I have to deal with a MSP430F2012 because of pricing - too small for Forth, and I have to deal with C which totally slows me down.
> >
> > Good luck!
> >
> > Dirk
> >
> > --- In m..., OneStone wrote:
> >> MY guess is the OP wants a parallel bus because he mistakenly thinks
> >> it's faster, because he hasn't taken the time to analyse the various
> >> options and determine what really works best for him. Of course I could
> >> be wrong ;@}
> >>
> >> Al
> >>
> >> Donald H wrote:
> >>> --- In m..., "CHAD" wrote:
> >>>> A29L160A uses a parallel bus interface and MSP430F5438 devices
> >>>> are not designed to interface with such devices.
> >>> Sure they are.
> >>>
> >>> The A29L160A needs 20 Address line and 16 Data line and 4 control lines, thats 40 pins on the MSP430F5438, its got .
> >>>
> >>> Bit Bang the control lines, no problem.
> >>>
> >>> Speed ? slow !
> >>>
> >>> SPI would be faster and easier, but the OP wants a parallel buss.
> >>>
> >>> Can be done, just read the fine manuals. ;-)
> >>>
> >>> don
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Start a New Thread

Hi Dirk, well the various emails on this seemed written in first person,
so my impression was that the OP was sending under different names, No
slight meant.

I programmed in Forth on the Jupiter Ace many years ago, I also had a
Forth implementation for the Acorn Model B, but assembler for the 6502
was so easy it made no sense using anything else. Then there were many
of the early casio programmable Pocket calculators which also used a
Forth like syntax, but I was never a big fan, to me Forth is a bit like
dyslexia, speaking words out of sequence, whereas well written code
reads linearly like natural language.

Cheers

Al

bluebee2010 wrote:
>
> Hi Al,
>
> I am the one who wrote about his experience about Forth, and Ahmed is the one with the project in question.
>
> Ahmed's question was "Can you guys propose serial Flash which operate between 12 - 15 MHz and can be accessed over SPI....." and so I suggested a reliable serial SPI FLASH, adding prices and webaddresses to order.
>
> Last night when I wrote these lines you are questioning, only Ahmed did know the other parts of his project. If I would have known that there is an image sensor involved, my answer would have been nearly the same Donald gave. I used one of the first Fairchild image sensors long ago, the frame grabber was on S100 bus cards. To analyze the pictures, my customer at the EMBL used a Rockwell AIM 65 computer, emulating the S100 bus.
>
> I appreciate your opinion that in this business you need to have knowledge in hardware a n d software. This belongs to my knowledge, too. I started my career with hardware, and when I got my first microprocessor to work with, I recognized immediately that the right mix between hardware and software is the most important point in microprocessor system design. A lot of managers did not understand this, and a lot of money on projects has been wasted ever since because of dividing development in hardware and software issues. You only get an optimum when having both in mind, hardware and software.
>
> Everything you are putting in hardware, you have to pay for with each manufactured piece. The cost of software per piece will go lower with each. That's why in all my projects I did as much as possible in software. Of course, nowadays you do not need software for a lot of things which are incorporated into a microcontroller. That's the beauty of it. That means with every generation of microprocessors / microcontrollers you have to rethink, of course, may be even with each project.
>
> When mentioning that I could use the ARM micro with Forth, I wrote "without any s p e c i a l A R M knowledge" - but hardware knowledge was essential, of course. I supposed everybody knows this. Did you ever program in Forth?
>
> Cheers!
> Dirk
>
> P.S.: Using Forth to emulate a bus system is much easier than in any other programming language, and the behavior is predictable. When coded, the read- and write-commands are added to the existing Forth commands, because Forth is extensible. When done, you use these new read- and write-commands and never have to think about it again.
> Of course you may have to use different programming styles depending on speed restraints, you even may need assembly language for this.
> The best thing with emulating was when using Harris/Intersils RTX2000. It's a pity that this microprocessor, specially designed for Forth, based on a design by Chuck Moore, the inventor of Forth, is only used in its radiation hardened version in space applications.
>
> --- In m..., OneStone wrote:
>> Microprocessors are a world of difference from microcontrollers. You
>> have hit one of the issues I personally have against the concept that
>> you can design good systems with separate people doing the hardware and
>> software, or with software guys who no no hardware. Sure C hides a lot
>> of the hardware from you. That doesn't make it a good thing. And this is
>> one of the places where it falls down badly. I'm not having a go
>> personally at you, but you have been tasked with a design for which you
>> lack the necessary skills to totally analyse it, despite 30 years
>> programming. The reason is simply that this isn't a programming issue,
>> unlike most things in the microprocessor world, where a knowledge of the
>> hardware can regularly be bypassed. In the microcontroller domain good
>> design requires hardware knowledge.
>>
>> You may have been able to emulate a memory bus in Forth, you can do it
>> in most languages, but could you, at the outset, evaluate the
>> performance of that bus? how long each memory access took, whether that
>> timing was constant or varied with address, data size, etc, before ever
>> writing code to test. ie could you determine before hardware was built,
>> at cost whether or not a given microcontroller and memory combination
>> would meet the design requirements. Again without hardware knowledge
>> this can't be done.
>>
>> Why are you stuck with C. putting this application into a 2012 is
>> probably more in the domain of assembler. I don't know how much more
>> there is to the system than obviously reading an image from somewhere
>> and then writing it to a memory chip, and then, I presume, somehow
>> downloading or retrieving that data. This can certainly be done with a
>> 2012, but without intimate knowledge of the compiler, how to order
>> instructions or which instructions or forms to use to get the best out
>> of the compiler I think you're going to struggle. The same goes if you
>> don't understand enough about the hardware to optimise the I/O
>> distribution. And if a hard ware specialist is doing this, unless he has
>> a thorough understanding of how the software will need to be implemented
>> then you may be fighting a far from optimal configuration.
>>
>> For a suitable paret you could try the M25PE16 from Numonyx, or the
>> M45PE16 from ST, both work at well over 25MHz.
>>
>> Cheers
>>
>> Al
>>
>> bluebee2010 wrote:
>>>
>>> It's me again. I am not that familiar with MSP430 and C, that's why I gave only a hint, but I am programming microprocessors since thirty years, all projects with 6502 micros and one with an NXP ARM micro.
>>> I was able to use the ARM micro without any special ARM knowledge because I used Forth as programming language. Forth deals with all the low level problems, and with using Forth it is very easy to emulate a memory bus. I did this several times to access RAM with a onechip micro. Works fine.
>>>
>>> Anyway, when I checked the MSP430F5438 datasheet I recognized I/O named A0, A1,... up to A15 and my first idea was to suggest to use the external memory mode of the MSP430F5438 - but I did not find the data bus. May be the project assumed the same without recognizing that these I/O pins are Analog Inputs instead of adress lines. Things happen.
>>>
>>> I personally would prefer a serial FLASH, not because there are Appnotes available, but because a serial FLASH is much smaller than a parallel FLASH, and much cheaper than a parallel FLASH - important if this part goes into production. I am pretty sure it is even cheaper to design an adaptor to put a serial FLASH in place if the PCB cannot be changed.
>>>
>>> I myself would be happy to be allowed to have the MSP430F5438 with it's huge amount of FLASH and RAM and I would immediately load a Forth operating system on it which gives a quadrupling boost in developing software - especially for somebody who doesn't have a lot of experience in programming.
>>>
>>> I have to deal with a MSP430F2012 because of pricing - too small for Forth, and I have to deal with C which totally slows me down.
>>>
>>> Good luck!
>>>
>>> Dirk
>>>
>>> --- In m..., OneStone wrote:
>>>> MY guess is the OP wants a parallel bus because he mistakenly thinks
>>>> it's faster, because he hasn't taken the time to analyse the various
>>>> options and determine what really works best for him. Of course I could
>>>> be wrong ;@}
>>>>
>>>> Al
>>>>
>>>> Donald H wrote:
>>>>> --- In m..., "CHAD" wrote:
>>>>>> A29L160A uses a parallel bus interface and MSP430F5438 devices
>>>>>> are not designed to interface with such devices.
>>>>> Sure they are.
>>>>>
>>>>> The A29L160A needs 20 Address line and 16 Data line and 4 control lines, thats 40 pins on the MSP430F5438, its got .
>>>>>
>>>>> Bit Bang the control lines, no problem.
>>>>>
>>>>> Speed ? slow !
>>>>>
>>>>> SPI would be faster and easier, but the OP wants a parallel buss.
>>>>>
>>>>> Can be done, just read the fine manuals. ;-)
>>>>>
>>>>> don
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Start a New Thread