Fan ... not Guru! Thanks for the reply Mattias and Enoch.
The ZH:ZL registers worked fine and moving my index into "unused" SRAM helped to! It works! And thanks for pointing out the push pop pair (duh!) I'll need that reminder since I think I'll wrap this into another loop needing an another index register. More hardware than software oriented - Forth fits my brain (such as it is!) I've played with a variety of embedded Forths - and also enjoyed tinkering with FPC. One of my favorites was Frank Sargent's pygmy Forth - and he wrote a 3 instruction Forth for the 'HC11 that was a lot of fun (pushing op codes into the chip with a DIY assembler!) Delving into Python, C, Javascript etc... I really missed a convenient Forth - then viola! Amforth. I am more a tinkerer than a serious programmer. Although it's fun jumping into the avr assembly - even if I am a bit lost at times. And Enoch - I also appreciate your response. You seem to have perceptive instincts about my challenge. When I started looking into this I was really discouraged about using the SPI because of the timing issues. And TWI is way too slow. There are three low level Python C wrappers to the linux spidev module - but how to configure the Raspberry Pi as a slave? I did find some info on rebuilding the kernel module and recompiling.... I'm reviving an old project using a 755 x 242 CCD array (TC245) for an astrograph. I need 9 clocks and pull the 12 bit ADC in as 3 nibbles - and ADC conversion needs about 10 microseconds. So... it gets busy. Here's where Amforth saved the day (together with a lot of reading on just how the SPI system works). Storing and fetching to the SPI while playing with a python spi module on the Pi side helped with my understanding of the atmega spi system (more than the docs or any posts). Imagine doing this with C. There are two ways to accomplish my task (one is tested). First, on the Raspberry Pi Master side, I enlarged the allotted buffer in the py-spidev module (and recompiled). Since I am reading each serial register of 242 + 10 pixels in 12 bits per "pass", I store that in SRAM (504 bytes) and "pull" it out between passes with a Python loop - testing for a null byte between passes. Since I can quickly block the SPI register in assembly this works well and the latency (when testing for null bytes) on the master side is minimal - and it appears that appending the resulting python list array is a shallow copy process! Using this approach I can transfer my 380520 bytes out of the CCD in under 1.5 seconds (this is a cooled transfer frame array) (The 328P clocked at 20 mhz and running the Pi SPI at 3 Mhz) - which is more than acceptable. And there is the second way: Since I only need 12 bits but transfer in bytes... do a bit shift and assure the LSB. Then just stream everything (nibbles as bit shifted bytes) to the buffer on the Pi, cull out the null bytes and bit shift back. If you don't put anything into the SPDR register, it goes back to the Pi as a null byte. And the Pi has 512 mb of ram most of which isn't doing anything! This approach might get the readout time under a second BUT generate "jitter" in the clock timing when checking the SPIF flag... not sure if this is an issue for the CCD. And to your point Enoch - the interrupts are off! I also have Amforth talking with a Pi - just using the UART - for an autoguider. Using a USB webcam on the Raspberry Pi for tracking, processing the image in Python and correcting my steppers for the equatorial drive of the telescope. I also plan on using this system to mosaic the CCD images. Sorry if I bored you guys. And again thanks for the help! Mark On Tue, Mar 12, 2013 at 7:14 PM, Enoch <i...@hotmail.com> wrote: > Matthias Trute <mtr...@web.de> writes: > > > PS: The atmega SPI system can do the slave work too. Did you > > check the datasheets? I've not used it myself however. > > Hello Mark & All, > > There is indeed a problem with the SPI functioning as a slave concerning > its transmitter, if the other side master cannot guarantee a time delay > between consecutive communication cycles. A hardware transmit buffer is > much needed... :-( > > If there is no guarantee of a time delay between communication cycles > not only you would have to go asm level you would also have to work with > the Interrupt system disabled. > > As you are responsible for the master firmware as well I suggest that > you find a way to delay successive communications on the master and on > the AVR slave stay high level (Forth). > > Regards, Enoch. > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
