flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] problem controlling pins RA4 and RB4 on PIC24FV16KM202

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

Did you try to clear the ODCB.4 and ODCA.4 bits ?
These should be cleared by default, but you never know ?

Strange that the C code did not touch the ANSEL registers.

The only other thing I can think of is if the pins are used for 
something else by FF.
Are those pins defined in the FF confuguration file for load led or 
flow control ?

BR Mike

[Flashforth-devel] problem controlling pins RA4 and RB4 on PIC24FV16KM202

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

Mike,
    I've not had much luck using pins RA4 and RB4 on a 
PIC24FV16KM202-I/SP from within FlashForth 5.0.  I've failed for both 
digital input and output.  Attached is an example that fails to control 
RA4 and RB4, but drives RB15 just fine.  Also, I've attached a C code 
that works the very same pins, so I'm reasonably sure that the MCU 
itself is fine.  Any hints for things that I should try with the 
configuration of FF, or should I look deeper within the assembly code 
for FF?
Regards,
Peter J.

Re: [Flashforth-devel] I2C word are not implemented in AVR but in PIC

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

Now that the teaching term is drawing to an end, I've had a chance to 
finally build a set of words for I2C master mode on AVR and PIC24.  
They're slightly different to Mike's PIC18 i2c-base words, in that some 
return flags, so I've built a corresponding new set for PIC18 as well.   
They're all in Forth since there doesn't seem to be much need for speed 
with an I2C device.  The i2c-detect word (adapted from amforth) runs on 
top of this base set, with no change for all chip architectures, as does 
the small application for reading a TC74 temperature sensor.

If these are of use to people, they might be included in the FF 
distribution.  I've tried to choose names that are similar to, but will 
not clash with, the original i2c words for the PIC18.
Cheers,
Peter J.


On 04/03/14 02:16, Mikael Nordman wrote:
> I have not used the Atmega I2C yet so I have not implemented any support
> for that.
>
> A contribution is  of course welcome. Either in Forth or assembly.
>
> BR Mike
>
> On 03/03/2014 10:39 AM, Peter Jacobs wrote:
>> My guess is that Mike had done the PIC18 i2c words as a demonstration
>> for the PIC18 assembler.  Building corresponding AVR words with his
>> recently-written AVR assembler would be a good exercise for someone
>> like you or me.  It's on my list of things to try but I haven't got to it.
>> Peter J.
>>
>>
>> On 03/03/14 17:54, rfr...@gm... wrote:
>>> Hallo
>>> I would like to know why the i2c words aren't implemented in the AVR
>>> Version.
>>> What should i do to implement them? Is there anything which can be
>>> reloaded?
>>> Mit freundlichem Gruss
>>>
>>> R.Freitag
>>>
>

[Flashforth-devel] USART2 INTERRUPT

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

FF 5.0 on a mega2560. Compiling, uploading, programming and execution 
all OK.

LCD working ok, interrupts as per irqAtmega2560.txt ok. Following code 
compiles OK. Upon receipt of a character on RX2 the computer hangs / WDT 
continually reboots. Never enters rds2 when the interrupt kicks - seems 
to go off to somewhere else???  Have tried other interrupts with 
identical code and all seem to work. With the interrupt disabled can 
receive chars on RX2 ok and all flags work as expected when data received!!

serial
marker serial
\ serial ports 2 and 3  - mega2560
$00d4 constant ubrr2l
$00d2 constant ucsr2c
$00d1 constant ucsr2b
#52   constant rx2compl

variable counter

: rds2      (  -- )    \ read & display serial 2 under interrupt
$00d6 c@ .
  1 counter +!            \ increment counter
;i

: init2    (  --  )    \ initialise serial port 2
['] rds2 rx2compl int!     \ store the interrupt vector
25 ubrr2l c!               \ set baud rate to 38400
6  ucsr2c c!               \  8 data, 1 stop bit
\24 ucsr2b c!               \ tx & rx enable - add 128 for RX intrup
152 ucsr2b c!               \ tx & rx enable - add 128 for RX intrup
;

: prq $d0 c@ . $d1 c@ . $d6 c@ . ;

init2

-- 
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] FF50-PIC18, using 2nd MSSP?

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

Unfortunately, that one bit me a couple of projects ago and zeroing all the ANSEL-s is the first line of my standard init-word (and called as turnkey).  That one clobbers bit-banging, too if I recall correctly.  Fortunately, I'm not scraping for milliwatts in this one so I've got the INTOSC cranked up to 64Mhz and have to slow down to 400Khz I2c for the digital pots' benefit.

I'll keep playing with it as I get time.  It's most likely just something that simple that I've overlooked.

Thanks for your time,
craig

Re: [Flashforth-devel] FF50-PIC18, using 2nd MSSP?

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

Hi Craig,

Did you try this ?

0 anseld c!

The I/Os are analog by default.

BR Mike

On 10/10/2014 06:31 PM, craig bair wrote:
> Been a little while since I've annoyed the community with my petty problems, so here I go again (grin).
>
> Did a program a few weeks back that used 2 SPI busses on a PIC18F45K22 (and the uart2 which worked just fine).  I didn't have any luck getting any action out of MSSP2, so (since I was in a hurry) I just knocked out a quick bit-banger to read what I needed out of the other chip.  Now I've got another board with the same processor pushing SPI speed to the hardware limit and an I2c bus wired to MSSP2.  Since Mike's I2c-base words have worked so well for me before, I changed the pin assignments to PortD, the interrupt lookup to PIR3, and switched all of the register references to ssp2xxxx (and got the addressing right as far as my one good eye can see).  All I get from any call is a timeout-reset whrn the watchdog runs out and no pin changes state, the 10K pullups just sit there high.
>
> It's really no big deal to whack out a bit-bang I2c but I'm getting really curious what I'm missing in the chip docs...  The hardware SHOULD work.  The only thing that I've noticed that I can imagine might be causing id the config-bit redirection of the CCP2 pins, but the more I blear at that, the less likely it seems.
>
> If anyone else has had problems with this or gotten it working, I could use the encouragement.
>
> Oh and if anyone's got a workaround to run the SPI CLK at 8 Mhz without slowing the Pic18 to 32Mhz (or get around the 30ns rise-time on the pin to use 16Mhz) I'ld love to hear about it.
>
> Thanks for your attention,
> craig bair
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] FF50-PIC18, using 2nd MSSP?

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

Hi Craig,

Did you try this ?

0 anseld c!

The I/Os are analog by default.

BR Mike

[Flashforth-devel] FF50-PIC18, using 2nd MSSP?

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

Been a little while since I've annoyed the community with my petty problems, so here I go again (grin).

Did a program a few weeks back that used 2 SPI busses on a PIC18F45K22 (and the uart2 which worked just fine).  I didn't have any luck getting any action out of MSSP2, so (since I was in a hurry) I just knocked out a quick bit-banger to read what I needed out of the other chip.  Now I've got another board with the same processor pushing SPI speed to the hardware limit and an I2c bus wired to MSSP2.  Since Mike's I2c-base words have worked so well for me before, I changed the pin assignments to PortD, the interrupt lookup to PIR3, and switched all of the register references to ssp2xxxx (and got the addressing right as far as my one good eye can see).  All I get from any call is a timeout-reset whrn the watchdog runs out and no pin changes state, the 10K pullups just sit there high.  

It's really no big deal to whack out a bit-bang I2c but I'm getting really curious what I'm missing in the chip docs...  The hardware SHOULD work.  The only thing that I've noticed that I can imagine might be causing id the config-bit redirection of the CCP2 pins, but the more I blear at that, the less likely it seems.

If anyone else has had problems with this or gotten it working, I could use the encouragement.

Oh and if anyone's got a workaround to run the SPI CLK at 8 Mhz without slowing the Pic18 to 32Mhz (or get around the 30ns rise-time on the pin to use 16Mhz) I'ld love to hear about it.

Thanks for your attention, 
craig bair

[Flashforth-devel] FF5.0 shell

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

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

Re: [Flashforth-devel] JY-MCU ATMEG16/32_DEMO atmega32l

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

I never got the Atmega32 to work with FlashForth.

I dont have that chip myself so I have not been able to debug it 
properly. I just did some changes based on the datasheet, and another 
guy did some testing.

BR Mike

On 28.08.2014 13:46, Neil Shuker-Harris wrote:
> Hi All
>
> Re
>
> http://www.ebay.co.uk/itm/Atmega32-Minimum-Development-Board-Core-Module-V1-4-Shield-ATMEL-Mega32-AVR-MCU-/271299268356?pt=LH_DefaultDomain_0&hash=item3f2ab24f04
>
> Some time back someone on this list mentioned the above board and I
> picked up a couple from ebay at the time for a completely separate
> purpose which as these things often do became a shove in the draw and
> forget project.
>
> I am currently laid up with a slipped disc and need something simple to
> do so I have compiled and loaded FF 5.0 into this board which went well.
> I used the m32def.inc file though the chip on the board is the L version
> but I thought what the heck if it blows up it blows up and that has not
> happened.
>
> So using avr 5.1 which is what I have I compiled the source and flashed
> it onto the board using an icsp and all seemed to go well.
>
> I have the board connected to putty via an ftdi cable which is also
> powering the board using a usb Y connector so it’s getting about 1 AMP.
> This is the set up I use for PIC which I am fairly comfortable running
> FF in.
>
> Pressing reset on the board returns. “EBM FlashForth Aÿ” to putty with
> nothing else, it does not respond to the keyboard.
>
> I have checked the ftdi cable with another device so I know that’s
> working and putty can see the com port it establishes when plugged in.
>
> I have checked all the setting for the serial connections and made sure
> they match what I compiled with. Any one got any ideas.
>
> On a side note when I compile FF in 5.1 I  get the same 7 errors ...  “4
> for register re-.DEF and 3 Unknown Forward Ref-s” that Craig is getting
> with his compile for mega 2560.
>
> Neil
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
>
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] New FF5.0

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

Hi,
The FF5.0 has been updated again with fixes for stable write to flash 
for the 24E/33E series chips.
These new chips have a new GIE bit for disabling interrupts, which seems 
to work during flash writes. The old style with raising the allowed 
interrupt priority level did not work for this purpose.

Also the IND variable used for DO LOOP was moved into the kernel so it 
can be guaranteed it is allocated to an address less than $2000.

BR Mike

[Flashforth-devel] New FF5.0

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

I just released a new version of FF 5.0 with updates for PIC24/30/33 
devices.

It contains support for the 24E and 33E devices. Interrupt routine 
support must still be checked.

There is a new flash write logic that compiles to a flash block buffer 
and only writes to flash after a idle timeout or if the flash block changes.

On devices with 128 Kbyte or more flash memory, the eeprom emulation is 
done in high memory which is not normally addressable by FlashForth.
This gives 4 (HJ FJ) or 8 (E) Kbytes more flash for use by FlashForth.

Another difference is also how the outgoing mappable pins are mapped.
You need to look into the datasheet to find out which field and which 
register needs to be updated and define them in the config file.

There is also a FIX for lost XOFF characters.

BR Mike

Re: [Flashforth-devel] Xon/Xoff how to

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

Actually I found a bug in the FF5.0 PIC24-30-33 XON/XOFF handling.
It only works with the unbuffered TX option.
.equ TX1_BUF_SIZE, 0  ; Use 0 for unbuffered TX.

It will release a fix in the near future.

BR Mike

Re: [Flashforth-devel] Xon/Xoff how to

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

On my 18f2620 board the XON/XOFF definetly works.
The serial line is connected to a real serial interface running on linux.

I tested it by disabling flow control in minicom, and then I get a lot 
of FF UART interrupt buffer overflows indicated by a | transmitted to 
the PC.

When I enable the xon/xoff flow control in minicom, then all works and 
nothing is lost.

Minicom is operating with 38400 baud and no delays configured.

I have the following configuration

constant RX1_BUF_SIZE = d'32'
constant RX1_OFF_FILL = d'4'
#define FC_TYPE_SW ENABLE    ; ENABLE OR DISABLE


BR Mike

Re: [Flashforth-devel] Xon/Xoff how to

[Herman A. <exp...@vn...>]

Mikael,

My thoughts with XON/XOFF topic come from experience of the earlier FF 
versions.
Thoroughgoing testing the FF5.0 with SW-FC, the trouble seems not a 
simple delay problem.
Using #define FC_TYPE_SW ENABLE in p18f-main.cfg the FF5.0 does not 
send or receive
XON/XOFF characters in any direction. I think so, it works without any 
flow control.
Maybe I failed, but please check it. I used 18F46K22@64MHz in test.
The HW-FC works fine.

BR
Attila



Sun, 03 Aug 2014 11:15:19 +0300
  Mikael Nordman <mik...@pp...> írta:
> I agree, with USB the best solution is to use HW flow control.
> I am using now a Microstick2 on a Microstickplus peripheral board.
> 
> The Microstickplus has a MCP2200 USB serial bridge.
> The CTS/RTS pins are not connected from the MCP2200, so some 
>soldering
> is required to connect the CTS (SOIC PIN13) to a free PIC pin.
> I connected it to the RB12 led pin so I get a nice flashing led each 
> time the CTS line is asserted from FlashForth.
> 
> The MCP2200 configuration utility (Windows) must be used to enable 
> CTS/RTS pins. These are not enabled by default on the Microstickplus 
>board.
> 
> Works a 100 % reliable without any delays configured in minicom.
> 
> BR Mike
> 
> On 20.07.2014 14:28, Herman Attila wrote:
>>
>> Hello Pito,
>>
>> Usually I use 38400 bps, but somtimes needed interchar and endline
>> delay for reliable upload, depending on speed and actual load of PC.
>> I don't know the CA-42, but e.g. the ATEN UC232 seems me unusable 
>>with
>> XON/XOFF. I use FÍT232RL, FT230XQ chips of FTDI.
>> However the most reliable solution the HW flow control, especially 
>>if
>> you want to use hi bitrate.
>>
>> BR
>> Attila Herman
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index 
>and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
>Flashforth-devel mailing list
>Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Re: [Flashforth-devel] Xon/Xoff how to

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

I agree, with USB the best solution is to use HW flow control.
I am using now a Microstick2 on a Microstickplus peripheral board.

The Microstickplus has a MCP2200 USB serial bridge.
The CTS/RTS pins are not connected from the MCP2200, so some soldering
is required to connect the CTS (SOIC PIN13) to a free PIC pin.
I connected it to the RB12 led pin so I get a nice flashing led each 
time the CTS line is asserted from FlashForth.

The MCP2200 configuration utility (Windows) must be used to enable 
CTS/RTS pins. These are not enabled by default on the Microstickplus board.

Works a 100 % reliable without any delays configured in minicom.

BR Mike

On 20.07.2014 14:28, Herman Attila wrote:
>
> Hello Pito,
>
> Usually I use 38400 bps, but somtimes needed interchar and endline
> delay for reliable upload, depending on speed and actual load of PC.
> I don't know the CA-42, but e.g. the ATEN UC232 seems me unusable with
> XON/XOFF. I use FÍT232RL, FT230XQ chips of FTDI.
> However the most reliable solution the HW flow control, especially if
> you want to use hi bitrate.
>
> BR
> Attila Herman

[Flashforth-devel] FF 5.0 and the DM300027 Demo Board with PIC24FJ64GA002 and the WIKI

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

Hi folks,

FF 5.0 is looking very good here on a 16-bit PIC with no eeprom.
I am using the the DM300027 Demo Board with PIC24FJ64GA002 for testing.

I have just posted 2 demo ff5.0 files on the WIKI to read the on-board 
variable resistor with the on-chip A/D and control the on-board leds on 
the DM300027 Demo Board.  These files are meant to be more tutorial than 
anything.

We really need more info posted on the WIKI.  Please contribute to it. 
Mikael has made it very easy to set up a page and post to it.


Pete

Re: [Flashforth-devel] FF5.0 on Arduino Uno R3

[Rob <rsc...@op...>]

Hi,

Excellent, thank you, it is now working.
I set the H fuse to 0xDA and L fuse to 0xFF.
Rob.


On 01-Aug-14 6:22 PM, Mikael Nordman wrote:
> The Hfuse needs to be 0xDA. Otherwise FF boots from the wrong starting
> address.
>
> For Lfuse and Efuse I use 0xFF.
>
> BR Mike
>
> On 01.08.2014 09:58, Rob wrote:
>> Hi,
>>
>> The fuses are set as:
>>
>> Lfuse: 0xFF
>>     Hfuse: 0xDE   BOOTSZ0=1 BOOTSZ1=1 BOOTRST=0
>> Efuse: 0x05
>> Lock Bits: 0x3f
>>
>> I used Teraterm with XON/XOFF and without. Both display "EBM lashForth
>> Atmega 5.0" when the Uno is reset.
>>
>> Flash contents read back match the original hex file.
>>
>> Thanks for your response.
>>
>> Rob Scholten.
>>
>>
>>
>>
>> On 01-Aug-14 4:38 PM, Mikael Nordman wrote:
>>> Hi Rob.
>>>
>>> Please reply to the list and no to me personally.
>>>
>>> How did you set the fuses on the chip ?
>>>
>>> Do you have XON/XOFF enabled in your terminal program ?
>>>
>>> BR Mike
>>>
>>> On 31.07.2014 15:10, Rob wrote:
>>>> Hi,
>>>> I programmed the Uno R3 via a UsbTiny program. No verification errors,
>>>> but a connected terminal returns
>>>> "EBM lashForth Atmega 5.0" . The Arduino does not respond to any key
>>>> input. The hex file is correct in that this line reads "ver 3.2
>>>> FlashForth Atmega 5.0".
>>>> I've tried two ATMega 328P chips.
>>>> Is anyone else getting this problem?
>>>> Thanks.
>>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Flashforth-devel mailing list
>>> Fla...@li...
>>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] FF5.0 on Arduino Uno R3

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

The Hfuse needs to be 0xDA. Otherwise FF boots from the wrong starting 
address.

For Lfuse and Efuse I use 0xFF.

BR Mike

On 01.08.2014 09:58, Rob wrote:
> Hi,
>
> The fuses are set as:
>
> Lfuse: 0xFF
>    Hfuse: 0xDE   BOOTSZ0=1 BOOTSZ1=1 BOOTRST=0
> Efuse: 0x05
> Lock Bits: 0x3f
>
> I used Teraterm with XON/XOFF and without. Both display "EBM lashForth
> Atmega 5.0" when the Uno is reset.
>
> Flash contents read back match the original hex file.
>
> Thanks for your response.
>
> Rob Scholten.
>
>
>
>
> On 01-Aug-14 4:38 PM, Mikael Nordman wrote:
>> Hi Rob.
>>
>> Please reply to the list and no to me personally.
>>
>> How did you set the fuses on the chip ?
>>
>> Do you have XON/XOFF enabled in your terminal program ?
>>
>> BR Mike
>>
>> On 31.07.2014 15:10, Rob wrote:
>>> Hi,
>>> I programmed the Uno R3 via a UsbTiny program. No verification errors,
>>> but a connected terminal returns
>>> "EBM lashForth Atmega 5.0" . The Arduino does not respond to any key
>>> input. The hex file is correct in that this line reads "ver 3.2
>>> FlashForth Atmega 5.0".
>>> I've tried two ATMega 328P chips.
>>> Is anyone else getting this problem?
>>> Thanks.
>>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

[Flashforth-devel] Interpreted mode vs turnkey mode

[Rüdiger E. <Rue...@gs...>]

Hallo Mikael,

you are right.

After creating the numberarray in flash, it works fine.

Many thanks,

Rüdiger

Re: [Flashforth-devel] FF5.0 on Arduino Uno R3

[Rob <rsc...@op...>]

Hi,

The fuses are set as:

Lfuse: 0xFF
  Hfuse: 0xDE   BOOTSZ0=1 BOOTSZ1=1 BOOTRST=0
Efuse: 0x05
Lock Bits: 0x3f

I used Teraterm with XON/XOFF and without. Both display "EBM lashForth 
Atmega 5.0" when the Uno is reset.

Flash contents read back match the original hex file.

Thanks for your response.

Rob Scholten.




On 01-Aug-14 4:38 PM, Mikael Nordman wrote:
> Hi Rob.
>
> Please reply to the list and no to me personally.
>
> How did you set the fuses on the chip ?
>
> Do you have XON/XOFF enabled in your terminal program ?
>
> BR Mike
>
> On 31.07.2014 15:10, Rob wrote:
>> Hi,
>> I programmed the Uno R3 via a UsbTiny program. No verification errors,
>> but a connected terminal returns
>> "EBM lashForth Atmega 5.0" . The Arduino does not respond to any key
>> input. The hex file is correct in that this line reads "ver 3.2
>> FlashForth Atmega 5.0".
>> I've tried two ATMega 328P chips.
>> Is anyone else getting this problem?
>> Thanks.
>>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
>

Re: [Flashforth-devel] FF5.0 on Arduino Uno R3

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

Hi Rob.

Please reply to the list and no to me personally.

How did you set the fuses on the chip ?

Do you have XON/XOFF enabled in your terminal program ?

BR Mike

On 31.07.2014 15:10, Rob wrote:
> Hi,
> I programmed the Uno R3 via a UsbTiny program. No verification errors,
> but a connected terminal returns
> "EBM lashForth Atmega 5.0" . The Arduino does not respond to any key
> input. The hex file is correct in that this line reads "ver 3.2
> FlashForth Atmega 5.0".
> I've tried two ATMega 328P chips.
> Is anyone else getting this problem?
> Thanks.
>

Re: [Flashforth-devel] Fwd: PWM at PIC18F2620

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

It is not possible to change configuration bits from within flashforth.

You have to do it in configuration file.

Re: [Flashforth-devel] Interpreted mode vs turnkey mode

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

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} .ms-cui-menu {background-color:#ffffff;border:1px rgb(171, 171, 171) solid;font-family:'Segoe UI WPC','Segoe UI',Tahoma,'Microsoft Sans Serif',Verdana,sans-serif;font-size:10pt;color:rgb(51, 51, 51);} .ms-cui-menusection-title {display:none;} .ms-cui-ctl {vertical-align:text-top;text-decoration:none;color:rgb(51, 51, 51);} .ms-cui-ctl-on {background-color:rgb(225, 235, 242);opacity: 0.8;} .ms-cui-img-cont-float {display:inline-block;margin-top:2px} .ms-cui-smenu-inner {padding-top:0px;} .ms-owa-paste-option-icon {margin: 2px 4px 0px 4px;vertical-align:sub;padding-bottom: 2px;display:inline-block;} .ms-rtePasteFlyout-option:hover {background-color:rgb(225, 235, 242) !important;opacity:1 !important;} .ms-rtePasteFlyout-option {padding:8px 4px 8px 4px;outline:none;} .ms-cui-menusection {float:left; width:85px;height:24px;overflow:hidden}.wf {speak:none; font-weight:normal; font-variant:normal; text-transform:none; -webkit-font-smoothing:antialiased; vertical-align:middle; display:inline-block;}.wf-family-owa {font-family:'o365Icons'}@font-face {  font-family:'o365IconsIE8';  src:url('prem/15.0.913.22/resources/styles/office365icons.ie8.eot?#iefix') format('embedded-opentype'),         url('prem/15.0.913.22/resources/styles/office365icons.ie8.woff') format('woff'),         url('prem/15.0.913.22/resources/styles/office365icons.ie8.ttf') format('truetype');  font-weight:normal;  font-style:normal;}@font-face {  font-family:'o365IconsMouse';  src:url('prem/15.0.913.22/resources/styles/office365icons.mouse.eot?#iefix') format('embedded-opentype'),         url('prem/15.0.913.22/resources/styles/office365icons.mouse.woff') format('woff'),         url('prem/15.0.913.22/resources/styles/office365icons.mouse.ttf') format('truetype');  font-weight:normal;  font-style:normal;}.wf-family-owa {font-family:'o365IconsMouse'}.ie8 .wf-family-owa {font-family:'o365IconsIE8'}.ie8 .wf-owa-play-large:before {content:'\e254';}.notIE8 .wf-owa-play-large:before {content:'\e054';}.ie8 .wf-owa-play-large {color:#FFFFFF/*$WFWhiteColor*/;}.notIE8 .wf-owa-play-large {border-color:#FFFFFF/*$WFWhiteColor*/; width:1.4em; height:1.4em; border-width:.1em; border-style:solid; border-radius:.8em; text-align:center; box-sizing:border-box; -moz-box-sizing:border-box; padding:0.1em; color:#FFFFFF/*$WFWhiteColor*/;}.ie8 .wf-size-play-large {width:40px; height:40px; font-size:30px}.notIE8 .wf-size-play-large {width:40px; height:40px; font-size:30px}--></style>
</head>
<body dir="ltr">
<div style="font-size:10pt;"><p style="margin-top:0;margin-bottom:0;">You need to create the numbers in flash, now you are creating them in ram which is cleared at warm start.</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p><div><signature_tag><p style="margin-top:0;margin-bottom:0;">Mike</p><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>R&uuml;diger Ehret<Rue...@gs...></p><p style="margin-top:0;margin-bottom:0;"><b>Date:&nbsp;</b>Mon, 28/07/2014 17:20</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] Interpreted mode vs turnkey mode</p><p style="margin-top:0;margin-bottom:0;">&nbsp;</p>
<div style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:HyphenationZone>21</w:HyphenationZone>
  <w:PunctuationKerning/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
   <w:DontGrowAutofit/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<p class="MsoNormal">Hallo Mikael,</p>
<p class="MsoNormal">&nbsp;</p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">thank you for your great FF, thanks to P. Jacobs for the Tutorial Guide/Hitchhiker's Guide and Pete Zawasky&nbsp;<span style="mso-spacerun:yes">&nbsp;</span>for Elements of FF.</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">I am a hobbyist, new to FF and PIC. Playing with FF on an 18f2550 a problem occurs.</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">After downloading my program with minicom, it works fine in the interpreted mode starting word main, but after &lt;Ctrl&gt; -&lt;o&gt; or warm or downloading it as a turnkey application, only portb has a malfunction.</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">No bit banging on portb is done to select the particular digits.</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">Bit banging on porta for select the segments is ok.</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">Do you have any idea what/where the problem could be???</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">&nbsp;</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">Greetings
</span></p>
<p class="MsoNormal"><span style="mso-ansi-language:EN-GB" lang="EN-GB">R&uuml;diger</span></p>
<!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState="false" LatentStyleCount="156">
 </w:LatentStyles>
</xml><![endif]--><!--[if gte mso 10]>
<style>
 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Normale Tabelle";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-ansi-language:#0400;
	mso-fareast-language:#0400;
	mso-bidi-language:#0400;}
</style>
<![endif]-->
<p><br>
</p>
</div>

</div></body>
</html>

[Flashforth-devel] Interpreted mode vs turnkey mode

[Rüdiger E. <Rue...@gs...>]

\ **********************************************************************
\    Filename:      7seg.txt                                           *
\    Date:          26.07.2014                                         *
\    FF Version:    5.0                                                *
\    Copyright:     Mikael Nordman                                     *
\    Author:        Rüdiger Ehret                                      *
\ **********************************************************************
\    FlashForth is licensed acording to the GNU General Public License *
\ **********************************************************************
\ pic18f2550, 
\ Xtal 4MHZ, PLLDIV = 1, CPUDIV = OSC1_PLL2, clock=d'2000000' ; Hz 
\ minicom over usb /dev/ttyACM0
\ 7 segment countdown on 4 digits

-7seg
marker -7seg

hex ram

\ The needed PIC registers
$ff80 constant porta
$ff81 constant portb
$ff89 constant lata
$ff8a constant latb
$ff92 constant trisa
$ff93 constant trisb
$fff1 constant intcon2

#0 constant bit0
#1 constant bit1
#2 constant bit2
#3 constant bit3 

$0100 as1 movlb, ( k -- )  

: (bit)
  :
  over $f040 $ff60 within
  if
    over #8 rshift $f and movlb, 
    1    \ Banked ram 
  else
    0    \ Access ram
  then
;

: bit0:
  (bit) bcf, $12 i, postpone [
;

: bit1:
  (bit) bsf, $12 i, postpone [
;

porta bit0 bit0: digit0_on inlined
porta bit0 bit1: digit0_off inlined
porta bit1 bit0: digit1_on inlined
porta bit1 bit1: digit1_off inlined
porta bit2 bit0: digit2_on inlined
porta bit2 bit1: digit2_off inlined 
porta bit3 bit0: digit3_on inlined
porta bit3 bit1: digit3_off inlined

create number $3f c, $06 c, $5b c, $4f c, $66 c, $6d c, $7d c, $07 c, $7f c, $6f c, 

: init 
     cwd
     $0f trisa mclr  \ for digit enabling
     $ff trisb mclr  \ for 7 segments 
     $ff porta c!    \ digits all off / low aktiv
     $00 portb c!    \ segments all off / high aktiv
;

: dispDigit ( n --- )
     number + c@ portb c! 
;

: digit_countdown ( -- )
     #10	
	begin
	   1-
	   dup .
	   dup dispDigit
	   500 ms
	   dup 0=
	until
     drop
;	

: digits_all ( -- )
           cr ." countdown digit one position" cr 
	   digit0_on
	   digit_countdown
	   digit0_off
	   
 	   cr ." countdown digit ten position" cr
	   digit1_on
	   digit_countdown
	   digit1_off
	   
 	   cr ." countdown digit hundred position" cr
           digit2_on
	   digit_countdown
	   digit2_off
	   
           cr ." countdown digit thousand position" cr
           digit3_on
	   digit_countdown
	   digit3_off  
;

: main ( -- )
    init
    digits_all
;

' main is turnkey 
warm

\ ?????
\ - interpreted main start 
\   works correct

\ - after modifying and sending 
\   as a turnkey application
\   or 
\   using warm
\   portb doesn't work correct
\   no bit banging will shown 
\ ?????