flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] FF and C interfacing

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

Hi Tovar,

On 19.9.2012 4:30, Tovar wrote:
> I read the posting about some of what's need to make C and FF co-exist.
> Let's see if i'm on the right track and that this won't be too complex.
>
> For my purposes, i am assume that FF is largely in control of the computing
> environment, the operating system, as you would say.  I want to have FF call
> C routines (probably via assembly hooks).  I assume then that the assembly
> hooks would preserve non-volatile registers that FF uses, and load up ones
> that C expects to find.  I assume that i only have limited use of the C
> library and need to be very careful what routines i used.  (If this were to
> prove to be feasible, i would probaly make up a separate library which only
> contain FF-safe routines.)
>
Sofar you are right. The only registers to be concerned about are the 
FSRn registers. FSRn is used by the C domain for stack handling. This 
means the all the interrupt code needs to be in the FF domain. No C 
interrupt code.

> I also recognize that for the C routines to do certain things, it will have
> to call at least FF internals to do things like acquire and release blocks
> of memory, get time of day and probably do I/O operations as well.  It would
> be nice if i could invoke Forth words from C, but that's less essential.
>
It's best to never access the FF environment from the C environment.
There is no heap support in FF. The C-lib would need to implement its 
own heap.
All the needed resources (memory and I/O) should be statically allocated 
to the C-lib.
The only thing that the C-lib could access from the FF domain is the 
TICKS counter for timeout support. Time of day support could be built
upon TICKS or on a separate RTC chip.

Any C-routines that regularly need to be executed can be called from the 
PAUSE word. At least the Microchip IP stack is polling the ethernet 
interface all the time. This can conviniently be done from PAUSE.

The other adaption needed is to let KEY and EMIT (ACCEPT?) use Telnet
for I/O. That is of course if you want to use Telnet for controlling the 
OPERATOR task.

BR Mike

Re: [Flashforth-devel] FF and C interfacing

[Tovar <tv...@se...>]

First, i got FlashForth to compile for a PIC18F2550 on MPLABX under Linux,
as well as the current MPLAB under Windows.  On MPLABX, it uses the C18
toolsuite, and with MPLAB under Windows, it currently uses the MPASM tools.
Different toolsuites seem to be problematic on each IDE.

It runs successfully on a homebrew card with a PICtail connector which was
originally intended as a rotor controller as well as providing serial I/O
and other access to hardward for USB only computers (such as Macintoshes). 
The current Debian Linux recognizes it and it shows up on /dev/ttyACM0 as
USB serial device.  I was very pleased that i could use the USB bootloader 
for this project.

I'm looking at extending FlashForth to allow it to make network connections,
initially via a WizNet evaluation board, but the code is being written to
be device independent.  So, for example, debugging of the networking code
could be done using DDD under Linux rather than trying to figure this stuff
out on a PIC without their fancy debugging tools (which might not even be as
informative).  An early non-FF version already executes the Microchip TCP
client example code under Linux.  The result, if it is useful, will probably 
be LGPL, as i don't share all of Stallman's philosophy.  (Hint: we go way 
back.)

I read the posting about some of what's need to make C and FF co-exist.
Let's see if i'm on the right track and that this won't be too complex.

For my purposes, i am assume that FF is largely in control of the computing
environment, the operating system, as you would say.  I want to have FF call
C routines (probably via assembly hooks).  I assume then that the assembly
hooks would preserve non-volatile registers that FF uses, and load up ones
that C expects to find.  I assume that i only have limited use of the C 
library and need to be very careful what routines i used.  (If this were to
prove to be feasible, i would probaly make up a separate library which only
contain FF-safe routines.)

I also recognize that for the C routines to do certain things, it will have
to call at least FF internals to do things like acquire and release blocks 
of memory, get time of day and probably do I/O operations as well.  It would
be nice if i could invoke Forth words from C, but that's less essential.

Am i on the right track and how difficult might this be?

			    -- Tovar  (on the 'Net for nearly 40 years)

Re: [Flashforth-devel] FlashForth

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

Thanks Mike,

WRT your questions.
1) I have only used the ASM30 and C30 suites.
The MPLAB project files tool paths may not agree with your installation.
Or was it some othet problem with ASM30 ?
2) I never quite figured what the Microchip logic is for defining  the 
processor family macros. I have noticed the same behaviour as you.
3) There could be a config option for selecting the OPERATOR UART.
The Atmega FF has that.
4) It would be possible to use EEPROM emulation or external EEPROM
for those 18F parts which do not have EEPROM. I actually
did a version for FF3.x with EEPROM emulation but it was never quite 
finalized.

If you want, you could ship a container of wine to me, hi, hi.

And finally, please join and post to the mailing list. It spreads the 
information better.

Its been very quiet on the mailing list.
I assume there are no problems, or nobody is using FlashForth.

73s de Mikael

On 15.9.2012 2:03, Mike Miller wrote:
> Mikael,
>
> Thank you for creating FlashForth.
>
> I was delighted to find your FlashForth, as I find that PIC assembly is
> tedious, and the C is worse.
> I have used Forth for many years. I used FIG Forth (68HC11) and
> Win32Forth (PC) extensively in a commercial winery system I designed in
> the '80s and 90s.
>
> I have brought FlashForth up on the Microchip Explorer 16 development
> board with the PIC24FJ128GA010.
> I had issues getting it to work. Now that I do have it working, perhaps
> my experience will be useful for others.
>
> 1) It was not clear which assembler to use.  After experimentation, it
> became apparent that one must use the XC16 suite, NOT the ASM30 suite.
> 2) There is a problem with the includes, we think it is in the Microchip
> XC16 assembler.  With the PIC24FJ128GA010 selected, the code loads
> p24f_cinfig.inc, instead of the p24fj_config expected.  This occurred
> under both MPLAB 8.87 anf MPLABX 1.3. It caused a lot of frustration
> trying to change serial ports until it was figured out.
> 3) For others trying to load on the Explorer 16, the following changes
> are required:
>     A) In the file p24f_config.inc
>         1) change the config lines to read:
>             config __CONFIG2, 0x7B7E
>             config __CONFIG1, 0x3F3F
>         2) Remove the ; before the .equ BAURATE2 line, as we will be
> using UART2
>         3) change the .equ PFLASH to 0x2000 for 8K of RAM
>     B) In the file ff.s WARMLIT area, change the reference to TX1 to
> TX2, RX1 to RX2, and RX1Q to RX2Q
>
> I also brought FlashForth up on the PIC18F4510, which has no EEPROM. Of
> course, it cannot write to the dictionary.  Is it possible to run
> FlashForth in a PIC18F by disabling EEPROM in the code?
>
> Again, thanks!
>
> 73,
>
> Mike Miller WB6TMH
> Moon Valley Circuits
> mi...@mo...
> http://www.moonvalleycircuits.com/
> (707) 996-4157
> 12350 Maple Glen Rd.
> Glen Ellen, CA 95442  USA
>

Re: [Flashforth-devel] FF and C interfacing

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

Hi.
Yes it would be possible.
But since FF is the operating system, I would do it so that
FF is the main program and C library functions are linked to FF.

Then Forth words can be written to call the top-level C functions
in order to have a fat fs or ip stack or whatever.

This requires some research about how the C-stack frame looks like
and what register conflicts there are.

The C startup code from crt0.s must be included into WARM.
On the PIC18 that was almost nothing, since WARM did everything already 
from before.

The linker is then used to make an executable from ff.o and "c.o".

A call to a C function could always be a long call so that C code can be 
put outside the normal FF 64 Kb address range.

BR Mike



On 10.3.2012 22:46, om1zz wrote:
> Hi Mike,
> I've been playing with FatFs on dspic33fj. Still thinking how to use
> the FF as a "shell" or a "scripting language" for a bigger C chunks
> (libs). For example, to use C30 as the main language tool, with FF
> included as an asm library (ff.asm) into a C code. So we may have ie
> fatfs, floating point, dsp etc glued to FF. Would this be feasible?
> I.
>

[Flashforth-devel] FF and C interfacing

[om1zz <om...@vo...>]

Hi Mike,
I've been playing with FatFs on dspic33fj. Still thinking how to use
the FF as a "shell" or a "scripting language" for a bigger C chunks
(libs). For example, to use C30 as the main language tool, with FF
included as an asm library (ff.asm) into a C code. So we may have ie
fatfs, floating point, dsp etc glued to FF. Would this be feasible?
I.

-- 
- - Reklama - - - - - - - - - - - - - -
Přemýšlíte o novém autě? Díky nám ho seženete nejvýhodněji! K tomu
porovnání oblíbených vozů až podle 200 parametrů a 260
aktualizovaných testů. To vše a mnohem víc na http://bit.ly/zZWURn 

Re: [Flashforth-devel] ff4.8- dsPIC30F3011 - SFR r/w

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

After some thinking, it came to me.

At warm start FF disables all peripherals by setting
the PMDn registers.
For each peripheral you want to use you must first
enable the peripheral in PMDn registers by clearing the corresponding
peripheral enable bit.

This is a power save feature. Disabled peripherals draw less power.

BR Mike

Re: [Flashforth-devel] ff4.8- dsPIC30F3011 - SFR r/w

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

Hi Adam,
This is really a strange problem.

I have the same problem on my 30F4012.

I have no idea whats going on here.

BR Mike

On 10.3.2012 13:49, Adam wrote:
> Hi ,
>
> I'm trying the (super) FF4.8 on dsPIC unit 30F3011.
>
> Afters some (...) hours of tests - some thing is still 'unsolved':
> - SFR r/w works almost ok, but (for me) it is not beetween adresses  $011a (after TMR3) ..(TMR4/5,..PWM,ADC) ..till $02c6 (TRISB) - reads (@) but not write (!) (i.e. any value written is without effect on existing (read) value)
>
> So if any suggestion , probably something 'config/set' or simply my overlooking of sthg ?
>
>
> Regards
> Adam
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

[Flashforth-devel] ff4.8- dsPIC30F3011 - SFR r/w

[Adam <ge...@in...>]

Hi ,

I'm trying the (super) FF4.8 on dsPIC unit 30F3011.

Afters some (...) hours of tests - some thing is still 'unsolved':
- SFR r/w works almost ok, but (for me) it is not beetween adresses  $011a (after TMR3) ..(TMR4/5,..PWM,ADC) ..till $02c6 (TRISB) - reads (@) but not write (!) (i.e. any value written is without effect on existing (read) value)

So if any suggestion , probably something 'config/set' or simply my overlooking of sthg ?


Regards
Adam

Re: [Flashforth-devel] USB FF38 Win7-64

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

In power save mode the FF38 responds slower,
and on fast computers the USB protocol gets confused.

FF for PIC24 has no support for the integrated USB hardware.

BR Mike

On 31.1.2012 9:30, Kit Latham wrote:
> Thanks Mike, it does seem to work.
> Do you know why this is needed for the 64 bit version of Win7 and will it be needed for the PIC24 version of FF?
>
> BR
>
> Kit
>

Re: [Flashforth-devel] USB FF38 Win7-64

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

Try commenting out the IDLE_MODE in the configuration file (p18f-main.cfg).

;; #define IDLE_MODE

That has helped before.

Mike

On 30.1.2012 14:59, Kit Latham wrote:
> Hello
>
> I can run ff38 fine on XP, but Win7-64 will not accept the driver.
>
> I noticed some discussion which seemed to suggest that this has been
> fixed – have I missed something?
>
> Sorry if I am being stupid.
>
> Kit
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

[Flashforth-devel] USB FF38 Win7-64

[Kit L. <Ki...@fo...>]

Hello

I can run ff38 fine on XP, but Win7-64 will not accept the driver.
I noticed some discussion which seemed to suggest that this has been fixed - have I missed something?
Sorry if I am being stupid.

Kit

[Flashforth-devel] Compiling FlashForth 3.8 with gputils

[Paulo F. <pa...@ke...>]

This may be useful to someone. 

Target:  A 18f4520 PIC Board 
	
Machine: A macbook running OSX 10.6 (Snow Leopard) 

Compiling tools:  gputils 0.13.7  ( installed through MacPorts ) 


I could not compile, with errors on the RX_FULL_BIT and TX_FULL_BIT macros. 

My kludge: 

On the ff18_usb.asm file, change  line 73:       
		btfss   RXcnt, #v(bitno), A
            to:  
               btfss   RXcnt, bitno, A
 
And also change line 83:       
		btfss   TXcnt, #v(bitno), A
            to:  
                btfss   TXcnt, bitno, A
 


 

Don't really know what I have done,  but now it compiles, it links and it runs on the target board.
:-) :-) :-) 

Greetings to all of you

Paulo Ferreira 



	

[Flashforth-devel] FlashForth for Atmel Atmega

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

There is now a version in git which has the kernel
write protection.
It does not allow writing to the adress space
between 0xe000-0xffff.
These addresses are virtual byte addresses as seen by
the FlashForth users.

For example on the Atmega328 the corresponding physical flash word 
address range is 0x3000-0x3fff.
On the Atmega128 the corresponding physical flash word
address range is 0xf000-0xffff.

BR Mike

Re: [Flashforth-devel] FlashForth for Atmega128

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

The plan is to prevent all writes to the kernel area.
You should be able to reset the cpu and give the empty and warm
commands now matter how bad you screw up the system.

This is how it works on the PICs.

I did the tail call optimisation a few days ago.
The kernel write protection is next on the list.

Mike

On 8.12.2011 16:20, om1zz wrote:
>> - kernel write protection
> For example amforth is quite sensitive on overwriting the code, a
> reflashing the whole flash is a standard maintenance operation
> basically. It would be interesting to know how FF on avr will cope
> with that..
> I.

Re: [Flashforth-devel] FlashForth for Atmega128

[om1zz <om...@vo...>]

> - kernel write protection
For example amforth is quite sensitive on overwriting the code, a
reflashing the whole flash is a standard maintenance operation
basically. It would be interesting to know how FF on avr will cope
with that..
I.

----- PŮVODNÍ ZPRÁVA -----
Od: "Mikael Nordman" <mik...@pp...>
Komu: fla...@li...
Předmět: Re: [Flashforth-devel] FlashForth for Atmega128
Datum: 4.12.2011 - 21:09:38

> Hi all,
> The Atmega FF is now tested both on the atmega 328
> and 128.
> It should work out of the box with other atmegas
> like 168 or 644.
> 
> The functionality includes now also multitasking,
> inlining, user defined 
> interrupts, turnkey support and double numbers.
> 
> What is still missing is
> - tail call optimisation
> - load measurement
> - assembler
> - kernel write protection
> 
> So its pretty complete.
> 
> /Mike
> 
> ------------------------------------------------------------------------------
> > All the data continuously generated in your IT
> infrastructure 
> contains a definitive record of customers,
> application performance, 
> security threats, fraudulent activity, and more.
> Splunk takes this 
> data and makes sense of it. IT sense. And common
> sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 


-- 
Tradiční i moderní adventní a novoroční zvyky, sváteční jídlo a
pití, výzdoba a dárky... - čtěte vánoční a silvestrovský speciál
portálu VOLNÝ.cz na http://web.volny.cz/data/click.php?id=1301

Re: [Flashforth-devel] FlashForth for Atmega128

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

Hi all,
The Atmega FF is now tested both on the atmega 328 and 128.
It should work out of the box with other atmegas like 168 or 644.

The functionality includes now also multitasking, inlining, user defined 
interrupts, turnkey support and double numbers.

What is still missing is
- tail call optimisation
- load measurement
- assembler
- kernel write protection

So its pretty complete.

/Mike

Re: [Flashforth-devel] FlashForth for Atmega128

[om1zz <om...@vo...>]

..and for programming my favorite

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=811028

It is a gui for avrdude, it works with all possible programmers..
There is maybe a newer avrdude 5.11:

http://download.savannah.gnu.org/releases/avrdude/




-- 
Jak co nejlépe přichystat automobil na provoz v nadcházející zimní
sezóně? Čtěte speciál Příprava auta na zimu na
http://web.volny.cz/data/click.php?id=1292

Re: [Flashforth-devel] FlashForth for Atmega128

[om1zz <om...@vo...>]

..or simply a "parallel port programmer" done in 5minutes (provided
you have a LPT port handy):

http://circuitgizmos.com/wordpress/?p=272

or 

http://elecrom.wordpress.com/2007/10/15/make-your-own-ultra-simple-universal-avr-programmer/

etc.



----- PŮVODNÍ ZPRÁVA -----
Od: mik...@pp...
Komu: fla...@li...
Předmět: Re: [Flashforth-devel] FlashForth for Atmega128
Datum: 8.11.2011 - 11:41:38

> >1 vote for atmega328p - today's mainstream ..
> 
> I have  some 328p chips but no 
> programmer...
> With the 128 I can use my JTAG programmer /
> debugger.
> 
> Mike
> 
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 


-- 
Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném
podzimním období? Čtěte speciál Zdraví na podzim na
http://web.volny.cz/data/click.php?id=1290

Re: [Flashforth-devel] FlashForth for Atmega128

[om1zz <om...@vo...>]

I am using home made

http://www.fischl.de/usbasp/

but you can get for few$

http://www.ebay.com/sch/i.html?_from=R40&_trksid=p5197.m570.l1313&_nkw=avr+usb+programmer&_sacat=See-All-Categories

i.

----- PŮVODNÍ ZPRÁVA -----
Od: mik...@pp...
Komu: fla...@li...
Předmět: Re: [Flashforth-devel] FlashForth for Atmega128
Datum: 8.11.2011 - 11:41:38

> >1 vote for atmega328p - today's mainstream ..
> 
> I have  some 328p chips but no 
> programmer...
> With the 128 I can use my JTAG programmer /
> debugger.
> 
> Mike
> 
> ------------------------------------------------------------------------------
> > RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 


-- 
Jak se vyhnout nachlazení a dalším zdravotním potížím v nepříjemném
podzimním období? Čtěte speciál Zdraví na podzim na
http://web.volny.cz/data/click.php?id=1290

Re: [Flashforth-devel] FlashForth for Atmega128

[<mik...@pp...>]

>1 vote for atmega328p - today's mainstream ..

I have  some 328p chips but no 
programmer...
With the 128 I can use my JTAG programmer / debugger.

Mike

Re: [Flashforth-devel] FlashForth for Atmega128

[om1zz <om...@vo...>]

1 vote for atmega328p - today's mainstream ..

> Initially its for the Atmega 128. When thats ready
> I guess its a small thing to add configuration for
> various ATmega parts.
> Mike



-- 
Jak co nejlépe přichystat automobil na provoz v nadcházející zimní
sezóně? Čtěte speciál Příprava auta na zimu na
http://web.volny.cz/data/click.php?id=1292

Re: [Flashforth-devel] FlashForth for Atmega128

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

On 7.11.2011 23:52, Doug Jackson wrote:
> Cool - is it limited to the 128 part, or will it play nicely with the 168/32
> Doug
>
Initially its for the Atmega 128. When thats ready
I guess its a small thing to add configuration for various
ATmega parts.
Mike

Re: [Flashforth-devel] FlashForth for Atmega128

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

On 7.11.2011 22:34, om1zz wrote:
> Mike, great! So the amforth people will watch you!
> As far as I can remember the amforth 4.2 on an atmega1284p @22MHz
> did Sieve (the slowest version) in 1300ms.
> I.
>
Yepp, its the slow version with the slow bit handling primitives.

Mike

Re: [Flashforth-devel] FlashForth for Atmega128

[om1zz <om...@vo...>]

Mike, great! So the amforth people will watch you!
As far as I can remember the amforth 4.2 on an atmega1284p @22MHz
did Sieve (the slowest version) in 1300ms.
I.

----- PŮVODNÍ ZPRÁVA -----
Od: "Mikael Nordman" <mik...@pp...>
Komu: fla...@li...
Předmět: [Flashforth-devel] FlashForth for Atmega128
Datum: 7.11.2011 - 21:23:23

> For those interested,
> there is now a pretty well working FF for
> ATmega128 in git.
> 
> XON/XOFF works, so it should be possible to send
> the provided
> sieve2.txt file to FF and run the bench2 test.
> 
> 1 bench2 1899 primes
> 646 milliseconds
> ok
> Fcy . 16000  ok
> 
> Not yet ready is PAUSE and tasking words.
> Only UART1 is implemented sofar.
> 
> Mike
> 
> ------------------------------------------------------------------------------
> > > RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 




-- 
Jak co nejlépe přichystat automobil na provoz v nadcházející zimní
sezóně? Čtěte speciál Příprava auta na zimu na
http://web.volny.cz/data/click.php?id=1292

[Flashforth-devel] FlashForth for Atmega128

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

For those interested,
there is now a pretty well working FF for ATmega128 in git.

XON/XOFF works, so it should be possible to send the provided
sieve2.txt file to FF and run the bench2 test.

1 bench2 1899 primes
646 milliseconds
  ok
Fcy . 16000  ok

Not yet ready is PAUSE and tasking words.
Only UART1 is implemented sofar.

Mike