Al,

I am delighted to read your lines. That's awesome!

The Jupiter Ace had some kind of lousy casing, but it had great concepts, you could change already defined words on the screen without recompiling. They had this character-oriented semi-graphics, and I saw somebody programming games with fishes swimming over the screen.

I helped Reflecta, the German importer, by adding a Centronics printer interface to the Jupiter Ace, but Reflecta's Marketing didn't work good enough. I still have some boards and cases for this Centronics Interface, and an original Jupiter Ace manual, written by Steven Vickers.

You are right, the 6502 is so easy to program with machine language that you didn't need high level programming. I wrote a relational data base with the 6502 using only the hex keypad and display with structured programming, and I didn't like to hit 7 keys for each gosub command - I had more than 200 subroutines - so I made a table with the subroutine start adresses and wrote a little parser parsing byte code and each subroutine was called by a bytecode, reducing the key strokes to three for programming, to less than 50%.

Worked really nice and with totally fast execution, it was a virtual machine, people would say today. My idea was to create a complete software development package out of this, and then I got the special BYTE magazine featuring Forth, 1978 IIRC. So I switched over to Forth, because it was ready to use and meanwhile I had a real keyboard, and Forth used words instead of bytes to call subroutines. Was much more pleasant.

Sorry, old story, but it is always a pleasure to meet somebody who could have been an old friend!

Cheers,
Dirk

--- In m..., OneStone wrote:
>
> 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

Hi Dirk, well the most fun with the 6502 was hunting down all the
undocumented instructions, there were a few of us doing it across the
world and communicating via nice high speed 1200/75 modems ;@}. Also in
those early days if it worked it was good, none of the current
semi-religious doctrine that pervades programming, like, "thou shalt not
write self modifying code". Why the hell not? it's one of the most
powerful tools around provided you know what you are doing. I remember
well my first 100k floppy. I had to buy 5 in a box, and I wondered how
on earth I was ever going to fill one, let alone 5. Lost innocence!

Cheers

Al

bluebee2010 wrote:
> Al,
>
> I am delighted to read your lines. That's awesome!
>
> The Jupiter Ace had some kind of lousy casing, but it had great concepts, you could change already defined words on the screen without recompiling. They had this character-oriented semi-graphics, and I saw somebody programming games with fishes swimming over the screen.
>
> I helped Reflecta, the German importer, by adding a Centronics printer interface to the Jupiter Ace, but Reflecta's Marketing didn't work good enough. I still have some boards and cases for this Centronics Interface, and an original Jupiter Ace manual, written by Steven Vickers.
>
> You are right, the 6502 is so easy to program with machine language that you didn't need high level programming. I wrote a relational data base with the 6502 using only the hex keypad and display with structured programming, and I didn't like to hit 7 keys for each gosub command - I had more than 200 subroutines - so I made a table with the subroutine start adresses and wrote a little parser parsing byte code and each subroutine was called by a bytecode, reducing the key strokes to three for programming, to less than 50%.
>
> Worked really nice and with totally fast execution, it was a virtual machine, people would say today. My idea was to create a complete software development package out of this, and then I got the special BYTE magazine featuring Forth, 1978 IIRC. So I switched over to Forth, because it was ready to use and meanwhile I had a real keyboard, and Forth used words instead of bytes to call subroutines. Was much more pleasant.
>
> Sorry, old story, but it is always a pleasure to meet somebody who could have been an old friend!
>
> Cheers,
> Dirk
>
> --- In m..., OneStone wrote:
>> 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

--- 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 Bill, it depends on what you need to do with the image. A few years
ago I found a need to try and recognise a fairly complex image.
basically a coloured label, and match it to a database of potentially
several thousand images, no motion video needed, simply grab a still
colour image and compare it against a library, and maintain the library
if this was a new type. The templates had to be transferable across the
internet from the sensor for that reason. The existing network was
implemented using MSP430F2121's and 2131's, so these were the obvious
choice of micro for the first look see. It proved both relatively simple
and was both fast and accurate. The limited RAM left few options other
than a slowish frame rate anyway, no RAM buffers. Had this been motion
video of course it would have been virtually impossible, but still the
solution was a $5 fix (with large memory for library) whereas the client
had originally been told he needed a Pc and commercial image recognition
software.

I'm currently investigating a similar concept for a friend, only this
time it needs to run at around 5-10fps for VGA colour video, and operate
in real time, ie take image, read to micro, translate the image then
feed the translated data back to the user before the next frame is
ready. I plan to use a 2274 for that one.

Cheers

Al

golfnut94952 wrote:
>
> --- 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

If parallel flash is a requirement - perhaps you
have 10,000,000 parts already in stock - then one
just designs a cheap serial to parallel
convertor, as any fule kno. Get a cheap counter
chain with parallel outputs, say 3x8-bit or 2x16
bit, and then you can set the address with just
the clock and clear lines. Accessing bytes at a
low address is pretty quick, though of course a
byte at address 20,000 would take 20,000 clock
cycles. Mind you, sequential memory access is a
breeze, just a single clock cycle. And what does
a classic image sensor require in terms of date
storage? Hmm .. sequential memory access. Now how
about making the clock dual control, the image
sensor clock does the increment for saving the
data, the MSP430 does the incrementing for
reading it out. Perfect application for a tiny
PLD, but normal digital parts are cheap and easy to use.

Also be aware that with image sensors that buffer
a full frame (or half-frame if interlaced), talk
of 30nsecs or whatever per byte is silly when you
only require a single frame. Electrically wipe
the sensor, take a single exposure and then read
out the results at whatever rate you like with
the MSP430. Thermal degradation and leakage are
your only enemies, so read out as fast as
possible, but the image will be fine on an
MSP430. You could even convert the serial ports
to capture the data at max speeds with an external shift register for the data.

I was writing this as a spoof reply to irritate
Al, but it is actually a perfectly valid and
applicable technique where sequential memory
access is the norm. If this is a student project,
you'd get extra marks for ingenuity.
:-)

At 11:20 PM 7/15/2010, you wrote:
>Why the fascination with parallel flash? Serial flash is much easier,
>and, because the interface is hardware, may actually be faster than
>parallel flash, especially one that requires address and data busses to
>be constructed across multiple ports. In this case the most efficient
>way to access the device is in 16 bit mode, so you need two data ports
>and 3 address ports for the 20 bit address, plus 3 extra pins for /CE,
>/WE and /OE, which could conceivably be part of the third address port,
>with care, thus potentially saving a few clocks per access.
>
>Anyway you still need to load data port 1 load data port 2
>load 3 address ports, then toggle the control pins to effect the write.
>
>Depending on how you structure your code this could take as many as 6
>cycles for each of the 5 port load operations, plus 5 clocks for each of
>the 4 control signal steps. So you're looking at around 50 clock cycles
>per byte of data, a few less if you judiciously apply the instruction
>set and registers, a few more if you structure your code inefficiently.
>
>Most modern serial flash can handle a clock rate up to 20MHz or even
>higher. The 5438 can operate up to 25MHz, and the SPI clock can be up to
>the value of BRCLK, which may be up to 25MHz, hence, given the right
>serial memory you could send an 8 bit command, followed by a 24 bit
>address, followed by a stream of data. Thus by sending data in, say
>pages of 1k, the total time would be 1056 bit clocks, or slightly over 1
>clock cycle per data bit sent.
>
>In the parallel mode you require 50 cycles per bit. Of course the gains
>aren't so great if you send a wrod at a time, in fact they are almost
>identical, at around 48 clock cycles.
>
>The calculations here are not 100% precise, but are given to illustrate
>a point. Not only can you save precious I/O bits with a serial flash,
>but, contrary to what might seem obvious, it is usually faster than
>using a parallel bus with microcontrollers (the opposite likely applies
>with microprocessors).
>
>Cheers
>
>Al
>
>w...@pera.com wrote:
> > thanks ..
> > @ Dirk
> > You wrote: ",,, and a little bit of software.
> Main thing is to send the addresses you need to
> the associated ports and use a few lines of
> code to switch CE, WE, and OE appropriately. You need five ports for this."
> >
> > I have enough numbers of ports available, but
> I am quite new to Device/Memory drivers world,
> a little bit of software can be a lot of
> software for me... can you refer to any example
> software, which I can adapt for this purpose,
> or at least can have a look for inspiration….
> >
> > Waqar
> >
> >
> > Subject: Interface between Flash (AMIC
> A29L160A Series, Boot Sector Flash) =
> >> and MCU (MSP430F5438IPZ)
> >>
> >> In my project I want to save an image on an external Flash.
> >> There will be a parallel connection between
> "Data and address busses" of Fl=
> >> ash and GPIO's of MCU.
> >>
> >> Initially I looked into available driver
> slaa281b for external flash interf=
> >> ace, but this is limited to serial communication (SPI).
> >>
> >> I wounded if any kind of drivers/guidelines
> are available for interfacing M=
> >> CU with flash of above specifications.
> >> Waqar Ahmed
> >

Start a New Thread

Ahmed, Waqar wrote:
> Subject: Interface between Flash (AMIC A29L160A Series, Boot Sector Flash) and MCU (MSP430F5438IPZ)
>
> In my project I want to save an image on an external Flash.
> There will be a parallel connection between "Data and address busses" of Flash and GPIO's of MCU.
>
> Initially I looked into available driver slaa281b for external flash interface, but this is limited to serial communication (SPI).
>
> I wounded if any kind of drivers/guidelines are available for interfacing MCU with flash of above specifications.
>
>
Hay,
I have been following this thread with iterest. I've looked over cameras
and such in the past. The old stuff had ram to buffer the flash. This
seemed to be done with dedicated silicon or fpga(?). Unless this is
something on the line that Al is talking about, I'd guess the 430 would
not be adequate. On the other hand, if it might be use in a supervisory
roll, external buss control. I can imagine where fast data on a dumb
buss controlled by the likes of the 430. I have not looked into what pal
to fpga looks like today, but I'd think miracles with a minimum of real
estate and cost. I'd say it is the wrong way around this is to say, 'I
want to us the msp430 to do...' Better is, 'What is required to meet the
end result of my challenge with a minimum of development/cost?'

As mentioned, TI has neat products for image processing.

Best, Dan.

Start a New Thread

Just another drop in the pond: in the old times, with much slower
microcontroler, one of the techniques to grab an image was using the
pixel clock as microcontroler's clock source (just to sinch
evrything) then use the very predictive video timing to read each
pixel every few microseconds, skiping some and reading again till the
end of the line. Then in the next frame wait one (or more) pixels and
start grab-skip-grab sequence again. Doing something like
interleaving. With faster microcontroler fewer frames would be needed
to grab a whole image.
Of course, to do it is necessary understand how microcontroler bus
work, calculate how many clocks all instructions will take, etc.
I am sure this technique is well known by many people in this list
and I was wondering why it was not mentioned yet.
A mutant code could work well in this job, using part of the SRAM to
run the frame grab program. It would save code space. I was used to
write mutant coding because of the small EPROMs I could get my hands
on. A 2764 did cost like gold in that era. 2716 was the "regular"
stuff.
Using a FPGA or CPLD to handle the memory data/address would save a
lot of work but also spoil the fun.... too easy.
-Augusto
.
On Dom 18/07/10 00:18 , Dan Bloomquist y...@lakeweb.net sent:
Ahmed, Waqar wrote:
> Subject: Interface between Flash (AMIC A29L160A Series, Boot
Sector Flash) and MCU (MSP430F5438IPZ)
>
> In my project I want to save an image on an external Flash.
> There will be a parallel connection between "Data and address
busses" of Flash and GPIO's of MCU.
>
> Initially I looked into available driver slaa281b for external
flash interface, but this is limited to serial communication (SPI).
>
> I wounded if any kind of drivers/guidelines are available for
interfacing MCU with flash of above specifications.
>
>
Hay,
I have been following this thread with iterest. I've looked over
cameras
and such in the past. The old stuff had ram to buffer the flash.
This
seemed to be done with dedicated silicon or fpga(?). Unless this is
something on the line that Al is talking about, I'd guess the 430
would
not be adequate. On the other hand, if it might be use in a
supervisory
roll, external buss control. I can imagine where fast data on a dumb

buss controlled by the likes of the 430. I have not looked into what
pal
to fpga looks like today, but I'd think miracles with a minimum of
real
estate and cost. I'd say it is the wrong way around this is to say,
'I
want to us the msp430 to do...' Better is, 'What is required to meet
the
end result of my challenge with a minimum of development/cost?'
As mentioned, TI has neat products for image processing.
Best, Dan.



Start a New Thread

Hello,

I'm working on a project with the MSP430F1611 and Chipcon transceiver.
Currently, my SMCLK is at 4MHz and the SPI is running at about 2MHz since
the code sets.

UBR01 = 0x02; // UCLK/2

The MSP430F1611 User's Guide states that:
Unpredictable SPI operation occurs if UxBR < 2

Therefore, I'm unable to get 4MHz UCLK with 4MHz SMCLK. Is there a way around
this without increasing SMCLK to 8MHz?

Thank you



Start a New Thread