amforth-devel

[Amforth] where to save the IP

[Mark M. <m.m...@gm...>]

Hi Matthias!

First of all - thanks to you and all your cohorts for Amforth!  I have been
using Forth for 30 years (F83 ... ) for a variety of projects and Amforth
(since 4.2) with the 328P as my current platform.

A quick question: for timing purposes, I have dropped into assembly
(driving the SPI system as a slave to a Raspberry Pi since the Pi isn't
easy to slave! BTW, the Pi is my ISP too, fun!) I'm trashing the X register
r26 & r27 to index into SRAM - so when I exit my code via 'JMP_ DO_NEXT'
I'm back at the interpeter prompt (surprise!). Where... and how.. is the
safest way to save the IP ... and what else might I be trashing? (I am
using temp0 thru 7 (except for temp5))

My thinking is to use r31:r30 in place of r27:r26 .

Thanks.
Mark Malmros

Re: [Amforth] where to save the IP

[Matthias T. <mt...@we...>]

Hi Mark,

> First of all - thanks to you and all your cohorts for Amforth!  I have been
> using Forth for 30 years (F83 ... ) for a variety of projects and Amforth
> (since 4.2) with the 328P as my current platform.

Wow. A Forth Guru. Welcome!

> A quick question: for timing purposes, I have dropped into assembly
> (driving the SPI system as a slave to a Raspberry Pi since the Pi isn't
> easy to slave! BTW, the Pi is my ISP too, fun!) I'm trashing the X register
> r26 & r27 to index into SRAM - so when I exit my code via 'JMP_ DO_NEXT'
> I'm back at the interpeter prompt (surprise!). Where... and how.. is the
> safest way to save the IP ... and what else might I be trashing? (I am
> using temp0 thru 7 (except for temp5))

There a few occasions, where I need two index registers. placing them
on the (CPU-) stack within one assembler word works fine:

push xl
push xh
... do some work with XH:XL, but no jmp DO_NEXT
pop xh
pop xl

> 
> My thinking is to use r31:r30 in place of r27:r26 .

The ZH:ZL is fine. Keep in mind that no CPU register is
guaranteed to survive the inner interpreter (aka a jmp DO_NEXT).
(the currently unused CPU registers are reserved for
future use, not that I have an actual use for them, but...).

Matthias

PS: The atmega SPI system can do the slave work too. Did you
check the datasheets? I've not used it myself however.

Re: [Amforth] where to save the IP

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> 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.

Re: [Amforth] where to save the IP

[Mark M. <m.m...@gm...>]

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 <ix...@ho...> wrote:

> Matthias Trute <mt...@we...> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] where to save the IP

[Matthias T. <mt...@we...>]

Hi Mark,

> Sorry if I bored you guys. And again thanks for the help!

You told a fascinating story. Are there any pictures
of the project/results available?

Matthias

Re: [Amforth] where to save the IP

[Enoch <ix...@ho...>]

Mark Malmros <m.m...@gm...> writes:
> Sorry if I bored you guys. And again thanks for the help!

Absolutely not, Forth & Astronomy go hand in hand!

By the way, when I need a "little Linux" I choose an OpenWRT based
solution using a converted commodity router.

Catch a falling star!

Regards, Enoch.