flashforth-devel — FlashForth users and developers

[Flashforth-devel] Flashforth new webpage

[Thomas <fla...@bu...>]

> I started to modernize the website. Anything people would like to see 
> there ?
> DS

Dear Mike,

The new design of the webpage is nice. What you think about add more tutorials and examples for practical use?

I wrote (for remember schematics myself :-) ) a page you can find here - its not error free and the scripts are doing by forth-gurus much better, but to illustrate what I mean:

http://www.buschhardt.de/heimnetz/flashforth/

Thank You
Thomas

PS: Its a Markdown page :-)

Re: [Flashforth-devel] FF5.0 shell

[Mikael N. <mik...@fl...>]

I tried it out and it worked for me on xubuntu 14.04.

More bling-bling could be added.
Configuration options of the serial interface would be nice.

Thanks /Mike

PS
I started to modernize the website. Anything people would like to see 
there ?
DS


On 06.04.2015 02:05, Peter Jacobs wrote:
> Attached is an alternative shell written in Tcl and based on the Tk text
> widget.
> Although the code is a bit longer than Mikael's Python shell, it does
> come with
> a GUI and might be a bit simpler for beginners.
>
> It seems to be fine on my Linux machine but could do with some exercise
> on a Microsoft-Windows machine and/or Mac.  If all is good, it can be
> added to
> the FlashForth distribution.
>
> Regards,
> Peter J.

Re: [Flashforth-devel] FF5.0 shell

[Peter J. <pe...@me...>]

Attached is an alternative shell written in Tcl and based on the Tk text 
widget.
Although the code is a bit longer than Mikael's Python shell, it does 
come with
a GUI and might be a bit simpler for beginners.

It seems to be fine on my Linux machine but could do with some exercise
on a Microsoft-Windows machine and/or Mac.  If all is good, it can be 
added to
the FlashForth distribution.

Regards,
Peter J.

On 10/09/14 06:10, Mikael Nordman wrote:
> The FF5.0 archive and git from today has now a simple shell
> that makes FlashForth a bit easier to use.
>
> It is written in python.
>
> It has command line history and edit.
> A directive for sending a file to FlashForth.
> And directive for warm start for a unresponsive FF.
> Exit from the shell with control-c.
>
> Some additional functionality could be added.
> I was at least thinking of file listings and maybe file name completions.
> Maybe also Forth word completions.
>
> Here is the help text:
> ------------------------------------------------------------------
> mikael@veriton:~/ff/shell$ ./ff-shell.py --help
> usage: ff-shell.py [-h] [--port PORT] [--rtscts] [--xonxoff] [--speed SPEED]
>
> Small shell for FlashForth
>
> optional arguments:
>     -h, --help            show this help message and exit
>     --port PORT, -p PORT  Serial port name
>     --rtscts              Serial port RTS/CTS enable
>     --xonxoff             Serial port XON/XOFF enable
>     --speed SPEED, -s SPEED
>                           Serial port speed
>
> Interact with FlashForth using commmand line editing and history. Send files
> to FlashForth with #send path/filename. Warm start with #warm.
>
> And Here is starts:
> -----------------------------------------------------------------
> mikael@veriton:~/ff/shell$ ./ff-shell.py --rtscts
> Port:/dev/ttyACM0 Speed:9600 rtscts:True xonxoff:False
> /home/mikael/.ff.history
>     ok<#,ram>
> Exiting ff-shell.py, goodbye...
> -----------------------------------------------------------------
>
> BR Mikael
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[craig b. <dab...@ya...>]

There is mud in Joyville...  The medieval solution seems to have glossed over the problem sufficiently for now.

Resolution:
    commented out all logical config setting lines
    after examining the Microchip p33ep128mc202.inc file to check syntax, added these lines to the p33e_config.inc:
;
; BRUTE-FORCE CONFIG-BITS in MPLAB v8.92
config __FICD, 0xFFCD	;157F0 = 
config __FPOR, 0xFFFF	;157F2 = 
config __FWDT, 0xFFFF	;157F4 = 
config __FOSC, 0xFFFF	;157F6 = 
config __FOSCSEL, 0xFFF9	;157F8 = FFF9
config __FGS, 0xFFFF	;157FA = 
;

    did a Make All.

The config bit clearing that was occurring went away except for the FGS (0x157FA) which stubornly remains set at 0xFFCF...  Fortunately that doesn't seem to bother anything I can see yet, the chip immediately comes up and runs.

Many Thanks again for the assist.  Hopefully these chips will start to make more sense to me as I work with them more.

craig

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[craig b. <dab...@ya...>]

I had noticed the change (grin), but my high-end machine is a Centrino Core-Duo with 4 gig ram running XP...  Java based heavy programs could only run slower if they went backwards.  I'll have to "upgrade" at some point if I don't retire first.  Tough call, that.  I really hate wasting instruction cycles.

I'm not sure why the config-bits are genning up the way they do, so I'll just feed your numbers straight in and see what happens.

Once again, many thanks sir!  You are truely a gentleman and a scholar.
craig

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[Mikael N. <mik...@fl...>]

You mentioned earlier that you are using MPLAB 8.
I thought that these new chips are only supported by MPLABX.

I am using MPLABX and the XC16 compiler these days.

When I assemble with your chip selected, I get mostly FFFF in the config 
bits.

157F0 = FFCD
157F2 = FFFF
157F4 = FFFF
157F6 = FFFF
157F8 = FFF9
157FA = FFFF

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[craig b. <dab...@ya...>]

Mike,
Thanks again for the pointer, getting the right config file DOES make a difference (grin).
I've gotten the 33EP to program with a couple tweaks.  The flash size number didn't make sense to me so I cut the example in half on the theory that a 128 chip should use half of what was called out for a 256.  Memory size, ditto.  Since the baudrate was set down to 9600 for the console, I switched it to xon/xoff to simplify trying it out.  I also activated the CPU-Activity LED as an indicator that the processor was running.

Eventually, it proved to be a serious issue with a cheap breadboard that was causing much of my problems, but now that it appears to be running, I've hit another snag... I found the console pins with my trusty 3v-logic-FTDI cable and a systematic test of available pins and had communication with it.  Then I changed the baud-rate, re-assembled, and reprogrammed it and it stopped running entirely.  I put the code back and tried again, still nothing, not even the  CPU-blip.  I probably should have dumped the flash to a hex-file for reference, but appearently I got overconfident...  I can still read avd write it through PGEx3 pair so I'm still playing with it.  

Reloaded a fresh copy of p33e_config.exe and started tweaking from scratch.  Do these config bits look right?  All those Zeros bother me.

(attaching file)

Thanks for your patience,
craig

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[<mik...@fl...>]

OOPS,
Actually the 24E/33E version support was introduced in August 2014.

Anyway, you need to use the p33e_config.inc file for configuration.

On 23.03.2015 09:11, mik...@fl... wrote:
> The E version support was introduced early 2015.
>

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[craig b. <dab...@ya...>]

Yup, I missed that...  I'll give it a try right away.

Thanks Mike!

craig

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[<mik...@fl...>]

Forgot to mention that you need the latest FF version.

The E version support was introduced early 2015.

I have not stepped the FF version number but a the date of the change 
is visible in the startup.

To see what has changed it helps to browse the GIT version history 
which can be found here.

http://sourceforge.net/p/flashforth/code/ci/master/tree/

BR Mike


On 22.03.2015 23:57, Mikael Nordman wrote:
> The pic33e series has its own config file.
>
> P33e_config.inc
>
> That would be a good place to start;-)
>
> Mike
>
> Sent from my LG Mobile
>
> ------ Original message------
>
> FROM: craig bair
>
> DATE: Sun, 22/03/2015 22:53
>
> TO: fla...@li...;
>
> SUBJECT:[Flashforth-devel] ...transition from PIC18 FlashForth to
> dsPIC33E, can I buy a clue?
>
> I dearly love the ease of development and performance on PIC18F 
> chips,
> especially the xxK22 series.
>
> I've been handed a dsPIC33EP128MC202 to drive a couple of sensors so
> of course the first thing I think of is "Why, toss FlashForth on it.
> This is what it's for." It didn't take too long to hook it up to the
> PICkit3 after finding the default PGMCLK & PGMDAT pins (even though
> they're not called that), find all of the power and ground pins
> scattered all around it, and figure out the right config file and how
> to invoke it with the trusty old MPLab-IDE (8.92 still works
> appearently). I did some scrounging through the widely scattered
> Microchip Docs, I decided that the settings called out for the
> dsPICFJ129GP802 at the top of the p33_config.inc file should be a
> close enough starting point. It assembled up, programmed up with no
> arguement, and it just sat there. Since it's quite likely that I 
> don't
> understand the pin-mapping mechanism, I started around the pins with 
> a
> scope looking for the Console Output hitting the MCLR and watching 
> for
> a few seconds
>  and not seeing anything that looked like a UART.
>
> Ok, next step... Since the FOSC stuff looks like what the dsPIC33E 
> FSM
> calls out for using the internal FastRC with PLL, I'm guessing that I
> don't need an external oscilator and I begin playing with the IDLE
> MODE and CPU LOAD settings to try and get the CPU LOAD LED to give me
> a heartbeat like I did when learning my way around the PIC18-s. No 
> joy
> in Mudville, I'm not seeing any activity on any pin.
>
> As usual, when I get desperate enough to post to the mailing list 
> I've
> concluded that I'm missing something basic that I probably should 
> see,
> but it's sitting in my blind-spot. I'm open to suggestions as to what
> to try. Can anyone help me get this thing off of ground zero? (The
> first chip is always the hardest...(grin)).
>
> Oh, if it makes a difference, I'm using the flashforth-master.zip 
> that
> I downoaded from Git-Hub on Nov 23, last year.
>
> Thanks for your attention,
> craig bair
>
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your 
> hub
> for all
> things parallel software development, from weekly thought leadership
> blogs to
> news, videos, case studies, tutorials and more. Take a look and join
> the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[Mikael N. <mik...@fl...>]

<div style="font-size:10pt;"><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">The pic33e series has its own config file.</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">P33e_config.inc</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">That would be a good place to start;-)</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">Mike</p><div><signature_tag><p style="margin-top:0;margin-bottom:0;">Sent from my LG Mobile</p></signature_tag></div><p id="last_enter" style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><p style="margin-top:0;margin-bottom:0;">------ Original message------</p> <p style="margin-top:0;margin-bottom:0;"><b>From:&nbsp;</b>craig bair<dab...@ya...></p><p style="margin-top:0;margin-bottom:0;"><b>Date:&nbsp;</b>Sun, 22/03/2015 22:53</p><p style="margin-top:0;margin-bottom:0;"><b>To:&nbsp;</b>fla...@li...;</p><p style="margin-top:0;margin-bottom:0;"><b>Subject:</b>[Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><pre>I dearly love the ease of development and performance on PIC18F chips, especially the xxK22 series.

I've been handed a &nbsp;&nbsp;dsPIC33EP128MC202 &nbsp;&nbsp;to drive a couple of sensors so of course the first thing I think of is &quot;Why, toss FlashForth on it. This is what it's for.&quot; &nbsp;It didn't take too long to hook it up to the PICkit3 after finding the default PGMCLK &amp; PGMDAT pins (even though they're not called that), find all of the power and ground pins scattered all around it, and figure out the right config file and how to invoke it with the trusty old MPLab-IDE (8.92 still works appearently). I did some scrounging through the widely scattered Microchip Docs, I decided that the settings called out for the dsPICFJ129GP802 at the top of the p33_config.inc file should be a close enough starting point. &nbsp;It assembled up, programmed up with no arguement, and it just sat there. &nbsp;Since it's quite likely that I don't understand the pin-mapping mechanism, I started around the pins with a scope looking for the Console Output hitting the MCLR and watching for a few seconds
 and not seeing anything that looked like a UART.

Ok, next step... &nbsp;Since the FOSC stuff looks like what the dsPIC33E FSM calls out for using the internal FastRC with PLL, I'm guessing that I don't need an external oscilator and I begin playing with the IDLE MODE and CPU LOAD settings to try and get the CPU LOAD LED to give me a heartbeat like I did when learning my way around the PIC18-s. &nbsp;No joy &nbsp;in Mudville, I'm not seeing any activity on any pin.

As usual, when I get desperate enough to post to the mailing list I've concluded that I'm missing something basic that I probably should see, but it's sitting in my blind-spot. &nbsp;I'm open to suggestions as to what to try. &nbsp;Can anyone help me get this thing off of ground zero? &nbsp;(The first chip is always the hardest...(grin)).

Oh, if it makes a difference, I'm using &nbsp;the &nbsp;flashforth-master.zip &nbsp;that I downoaded from Git-Hub on Nov 23, last year.

Thanks for your attention,
craig bair

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Flashforth-devel mailing list
Fla...@li...
https://lists.sourceforge.net/lists/listinfo/flashforth-devel

</pre></div>

[Flashforth-devel] ...transition from PIC18 FlashForth to dsPIC33E, can I buy a clue?

[craig b. <dab...@ya...>]

I dearly love the ease of development and performance on PIC18F chips, especially the xxK22 series.

I've been handed a   dsPIC33EP128MC202   to drive a couple of sensors so of course the first thing I think of is "Why, toss FlashForth on it. This is what it's for."  It didn't take too long to hook it up to the PICkit3 after finding the default PGMCLK & PGMDAT pins (even though they're not called that), find all of the power and ground pins scattered all around it, and figure out the right config file and how to invoke it with the trusty old MPLab-IDE (8.92 still works appearently). I did some scrounging through the widely scattered Microchip Docs, I decided that the settings called out for the dsPICFJ129GP802 at the top of the p33_config.inc file should be a close enough starting point.  It assembled up, programmed up with no arguement, and it just sat there.  Since it's quite likely that I don't understand the pin-mapping mechanism, I started around the pins with a scope looking for the Console Output hitting the MCLR and watching for a few seconds
 and not seeing anything that looked like a UART.

Ok, next step...  Since the FOSC stuff looks like what the dsPIC33E FSM calls out for using the internal FastRC with PLL, I'm guessing that I don't need an external oscilator and I begin playing with the IDLE MODE and CPU LOAD settings to try and get the CPU LOAD LED to give me a heartbeat like I did when learning my way around the PIC18-s.  No joy  in Mudville, I'm not seeing any activity on any pin.

As usual, when I get desperate enough to post to the mailing list I've concluded that I'm missing something basic that I probably should see, but it's sitting in my blind-spot.  I'm open to suggestions as to what to try.  Can anyone help me get this thing off of ground zero?  (The first chip is always the hardest...(grin)).

Oh, if it makes a difference, I'm using  the  flashforth-master.zip  that I downoaded from Git-Hub on Nov 23, last year.

Thanks for your attention,
craig bair

Re: [Flashforth-devel] FF for Raspberry Pi

[C. K. <ma...@ck...>]

gFORTH works very well on Raspberry Pi
http://ckuehnel.ch/dokuwiki/doku.php?id=forth

Dr. Claus Kühnel - Talstrasse 39a - CH-8852 Altendorf
-----Original-Nachricht----- 
> Von: mik...@fl... 
> An: fla...@li... 
> Datum: 20.03.2015 13:00 
> Betreff: Re: [Flashforth-devel] FF for Raspberry Pi 
> 
> Well,
> I think it would quite difficult since I have understood the RPI has 
> some
> closed drivers and the HW specs of the SOC are not published.
> I at least it used to be  like that.
> 
> The RPI is a linux platform, so there are many Forths and scripting 
> languages available
> that can utilize all the capabilities of Linux.
> My personal favourite is Python.
> 
> There are some native ARM Forths that could work on simpler ARM 
> platforms. Mecrisp comes to mind.
> 
> BR Mike
> 
> On 19.03.2015 23:49, Pete Zawasky wrote:
> > Hi Mikael,
> >
> > I was wondering if you have played with the Raspberry PI at all.   I
> > just got a RPI 2.  Wonder if you have any thoughts on a 'bare metal'
> > very FlashForth-like FORTH for the RPI.
> >
> > Pete
> >
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] FF for Raspberry Pi

[<mik...@fl...>]

Well,
I think it would quite difficult since I have understood the RPI has 
some
closed drivers and the HW specs of the SOC are not published.
I at least it used to be  like that.

The RPI is a linux platform, so there are many Forths and scripting 
languages available
that can utilize all the capabilities of Linux.
My personal favourite is Python.

There are some native ARM Forths that could work on simpler ARM 
platforms. Mecrisp comes to mind.

BR Mike

On 19.03.2015 23:49, Pete Zawasky wrote:
> Hi Mikael,
>
> I was wondering if you have played with the Raspberry PI at all.   I
> just got a RPI 2.  Wonder if you have any thoughts on a 'bare metal'
> very FlashForth-like FORTH for the RPI.
>
> Pete
>

[Flashforth-devel] FF for Raspberry Pi

[Pete Z. <pza...@pz...>]

Hi Mikael,

Hope all is well.  Hope the Winter went well and you are looking forward 
to sailing again this Summer.

I was wondering if you have played with the Raspberry PI at all.   I 
just got a RPI 2.  Wonder if you have any thoughts on a 'bare metal' 
very FlashForth-like FORTH for the RPI.

Pete

[Flashforth-devel] A-D

[C. K. <ma...@ck...>]

Under http://sourceforge.net/projects/flashforthforarduino/ you will find some FF examples.
I have there a file adc_frm.ff as test program for the internal ADC in free running mode.
Important there is the initialization.


Regards,
Claus

Dr. Claus Kühnel - Talstrasse 39a - CH-8852 Altendorf

Re: [Flashforth-devel] A-D

[GRAHAM B. <gw...@bi...>]

David - many thanks - I had not picked up on the prescaler - the a-d's 
are now working. I have read pages 275 to 295 repeatedly but did not 
realise the need to set the prescaler. It is there very clearly when you 
know what to look for. Hard to get good help these days!!!!!!!!!!!!!!!!!!

Graham Boyd
Managing Director
Geosolutions Pty. Ltd.
16 Centre Way
Belair, 5052
South Australia
Ph. 61 (0)407 563944
     61 (0)8 82786752
www.geosol.com.au

On 3/19/2015 2:43 PM, David Schweizer wrote:
> I'm a rank beginner with both Forth and Atmel processors, but I hacked 
> and thrashed my way through to produce the four attached files that do 
> work (on an Arduino R3 with FlashForth).
>
> There's no good reason the code is spread over four files...
>
> --dls
>
>
> On Wed, Mar 18, 2015 at 8:55 PM, GRAHAM BOYD <gw...@bi... 
> <mailto:gw...@bi...>> wrote:
>
>     Mikael - sorry to bother you with this one, but I really do need
>     help from a higher source.
>
>     Attached is simple code designed to do an A-D on channel zero.
>     Only two registers need to be set (ADMUX,ADCSRA)with one (ADCSRB)
>     left at default.
>
>     I have 2.65 volts on AD0 with AREF at 5.01 measured with a
>     voltmeter. Before initialising A-D system $78 @ returns 0.
>
>     Set ADEN to 1. With no interrupt ADIF bit always set, resetting it
>     to zero and it immediately resets to 1. $78 @ returns 1023.
>     Settting ADSC bit appears to do nothing.
>
>     Setting interrupt and continuous interrupts occur. Again 1023
>     returned in the two data registers.
>
>     Setting  the BG voltage ref as input still returns 1023.
>
>     Can change voltage selection using REFS1, REFS0 as per the
>     documentation and it measures correctly at AREF with a voltmeter.
>
>     Same result with two different MEGA boards - so not a faulty board.
>
>     Have had great success so far with this Forth - keypad,lcd, GPS,
>     battery backed clock, SDHC/ micro SDHC all functioning so I am
>     rather surprised that someting as simple as an A-D conversion failing.
>
>     Many thanks - Graham
>
>     -- 
>     Graham Boyd
>     Managing Director
>     Geosolutions Pty. Ltd.
>     16 Centre Way
>     Belair, 5052
>     South Australia
>     Ph. 61 (0)407 563944
>         61 (0)8 82786752
>     www.geosol.com.au <http://www.geosol.com.au>
>
>
>     ------------------------------------------------------------------------------
>     Dive into the World of Parallel Programming The Go Parallel
>     Website, sponsored
>     by Intel and developed in partnership with Slashdot Media, is your
>     hub for all
>     things parallel software development, from weekly thought
>     leadership blogs to
>     news, videos, case studies, tutorials and more. Take a look and
>     join the
>     conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     Flashforth-devel mailing list
>     Fla...@li...
>     <mailto:Fla...@li...>
>     https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>
>

Re: [Flashforth-devel] A-D

[David S. <dav...@co...>]

-adcconsts
marker -adcconsts

$007c constant ADMUX
$007a constant ADCSRA
$0064 constant PRR

$0079 constant ADCH
$0078 constant ADCL


$80 constant ADEN \ bit 7 of ADCSRA
$40 constant ADSC \ bit 6 of ADCSRA
$20 constant ADLAR \ bit 5 of ADMUX

[Flashforth-devel] A-D

[GRAHAM B. <gw...@bi...>]

Mikael - sorry to bother you with this one, but I really do need help 
from a higher source.

Attached is simple code designed to do an A-D on channel zero. Only two 
registers need to be set (ADMUX,ADCSRA)with one (ADCSRB) left at default.

I have 2.65 volts on AD0 with AREF at 5.01 measured with a voltmeter. 
Before initialising A-D system $78 @ returns 0.

Set ADEN to 1. With no interrupt ADIF bit always set, resetting it to 
zero and it immediately resets to 1. $78 @ returns 1023. Settting ADSC 
bit appears to do nothing.

Setting interrupt and continuous interrupts occur. Again 1023 returned 
in the two data registers.

Setting  the BG voltage ref as input still returns 1023.

Can change voltage selection using REFS1, REFS0 as per the documentation 
and it measures correctly at AREF with a voltmeter.

Same result with two different MEGA boards - so not a faulty board.

Have had great success so far with this Forth - keypad,lcd, GPS, battery 
backed clock, SDHC/ micro SDHC all functioning so I am rather surprised 
that someting as simple as an A-D conversion failing.

Many thanks - Graham

-- 
Graham Boyd
Managing Director
Geosolutions Pty. Ltd.
16 Centre Way
Belair, 5052
South Australia
Ph. 61 (0)407 563944
     61 (0)8 82786752
www.geosol.com.au

Re: [Flashforth-devel] newbee to Flashforth

[Mikael N. <mik...@fl...>]

Hi Christian,
I can think of two things to check.

1. The fuses on the Atmega chip. These are set by the ICSP programmer.
Look in the config.inc file for fuse values.

2. The eeprom is not programmed by AvrAsp
if your serial connection works, giving EMPTY as the first command will 
fix the problem

3. Send some more info about your problem

BR Mike

[Flashforth-devel] ATmega Interrupt Examples

[C. K. <ma...@ck...>]

Hi there

I evaluated FF for interactive programming of Arduino Uno.
Here are some samples for external interrupt, timer and adc interrupt: https://sourceforge.net/projects/flashforthforarduino/


Claus

Dr. Claus Kühnel - Talstrasse 39a - CH-8852 Altendorf

[Flashforth-devel] newbee to Flashforth

[christian r. <chr...@gm...>]

Hi Mike,

I am newbee to FlashForth, and I like very much hybrid programming allowed
by your program.

I flashed correctly Arduino Nano with FlashForth, using AvrAsp tthrough ICSP
I did the same with Arduino Uno and Mega, and it is impossible
to get the same result as with Nano.

I have read all documentation, and I feel that I missed something,
but I really don't know what ?


Thanks for your help,

Christian

Re: [Flashforth-devel] ff on the microstick 2 / microstick plus development board

[<mik...@fl...>]

I leave PIN 11 (RTS !) disconnected.
/Mike

On 26.01.2015 19:56, Mark Goldman wrote:
> When you soldered pin 13 (CTS) on the MCP2200 to RB12, did you leave
> pin 10 (RTS) connected?
>
> -mdg
>
> On Sun, Jan 11, 2015 at 3:12 AM,
> <fla...@li...> wrote:
>> You need to configure the UART pins in config file p33_config.inc.
>> .equ RPINR18VAL, 11     ; U1RXPIN RP43 PB11 pin22 microstick2
>> .equ U1TXPIN, 10        ; PB10 pin21 microstick2
>>
>> If you use HW flow control you need the separate the CTS RTS pins on 
>> the
>> MCP2200
>> and connect RB12 to the CTS pin13 on the MCP2200.
>> And define the RTS pin in the FF config file.
>> .equ U1RTSPIN, 12       ; Solder to MCP2200 CTS pin13 on 
>> microstickplus if
>> HW flow control

Re: [Flashforth-devel] ff on the microstick 2 / microstick plus development board

[Mark G. <bit...@gm...>]

When you soldered pin 13 (CTS) on the MCP2200 to RB12, did you leave
pin 10 (RTS) connected?

-mdg

On Sun, Jan 11, 2015 at 3:12 AM,
<fla...@li...> wrote:
> You need to configure the UART pins in config file p33_config.inc.
> .equ RPINR18VAL, 11     ; U1RXPIN RP43 PB11 pin22 microstick2
> .equ U1TXPIN, 10        ; PB10 pin21 microstick2
>
> If you use HW flow control you need the separate the CTS RTS pins on the
> MCP2200
> and connect RB12 to the CTS pin13 on the MCP2200.
> And define the RTS pin in the FF config file.
> .equ U1RTSPIN, 12       ; Solder to MCP2200 CTS pin13 on microstickplus if
> HW flow control
>
> Attached is the config file I just tried with my dsPIC33FJ128MC802.
>
> BR Mike
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>



-- 
Our problems are mostly behind us, now all we have to do is fight the solutions.

Re: [Flashforth-devel] atmega assembler

[<mik...@fl...>]

Graham,
The square brackets are needed to compile inline assembler code.

Without square brackets you will compile code that compiles assembler 
when the code is executed.

Here are some examples for Atmega I just put together.

You can use SEE to see the generated code and compare it with the FF 
words.

/Mike

-asmexamples
marker -asmexamples

\ Top of stack is always cached in R24:R25

\ duplicate top of stack
\ identical to DUP on FlashForth
: _dup ( n -- n n )
   [ R25 -Y st, ]
   [ R24 -Y st, ]
; inlined

\ drop top of stack
\ identical to DROP on FlashForth
: _drop ( n -- )
   [ R24 Y+ ld, ]
   [ R25 Y+ ld, ]
; inlined

\ Load constant $1234 to top of stack
: a-number ( -- 1234 )
   dup                  \ Make space for new TOS value
   [ R24 $34 ldi, ]
   [ R25 $12 ldi, ]
;

\ Pop the top of stack to registers R18:R19
\ R18 and R19 are free to use unless DO..LOOP is used
: tos-to-r18-r19 ( n -- )
   [ R18 R24 movw, ]  \ Move TOS to R18:R19
   drop               \ load R24:R25 with new TOS
;


On 23.01.2015 10:46, GRAHAM BOYD wrote:
> Mikael - I am trying to get started with the assembler. I have 
> compiled
> asm.txt and asmtest.txt. testif0,testif1 and testuntil appear to 
> work.
>
> Could you give some more examples - load a register with a constant 
> and
> push to stack, pop from stack to a register, pop from stack-2 to a
> register would help me get started.
>
> I am not understanding why the square brackets ( enter interpreter
> state) is required???
>
> --
> Graham Boyd