flashforth-devel Mailing List for FlashForth: for PIC and Atmega (Page 32)
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel — FlashForth users and developers
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
(22) |
Mar
(3) |
Apr
(4) |
May
(6) |
Jun
(8) |
Jul
|
Aug
(6) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(4) |
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(14) |
Nov
(1) |
Dec
|
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(4) |
Apr
(2) |
May
|
Jun
(29) |
Jul
(7) |
Aug
|
Sep
(20) |
Oct
(9) |
Nov
(2) |
Dec
(7) |
| 2014 |
Jan
|
Feb
(23) |
Mar
(113) |
Apr
(25) |
May
(31) |
Jun
(9) |
Jul
(47) |
Aug
(15) |
Sep
(1) |
Oct
(4) |
Nov
(8) |
Dec
(3) |
| 2015 |
Jan
(21) |
Feb
(1) |
Mar
(18) |
Apr
(16) |
May
(100) |
Jun
(33) |
Jul
|
Aug
(10) |
Sep
(8) |
Oct
(7) |
Nov
(5) |
Dec
|
| 2016 |
Jan
(12) |
Feb
(9) |
Mar
|
Apr
(7) |
May
(5) |
Jun
(9) |
Jul
(1) |
Aug
(2) |
Sep
(17) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
(6) |
Feb
(12) |
Mar
(9) |
Apr
(3) |
May
(7) |
Jun
|
Jul
(12) |
Aug
|
Sep
(13) |
Oct
|
Nov
|
Dec
(10) |
| 2018 |
Jan
(1) |
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(21) |
Oct
(3) |
Nov
|
Dec
|
| 2019 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(4) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
(7) |
| 2020 |
Jan
(2) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(8) |
Apr
(40) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
(3) |
Oct
(4) |
Nov
(10) |
Dec
(4) |
| 2022 |
Jan
(29) |
Feb
(7) |
Mar
(10) |
Apr
|
May
(3) |
Jun
(3) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(6) |
| 2023 |
Jan
(8) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(6) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(9) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Peter J. <pe...@me...> - 2014-04-17 22:23:27
|
Mike,
Yes
Yes
Don't know, but I don't think that the flash write is the problem.
Here is a transcript of some interaction. I should have included it
with the last note.
BPE Fahot I24 5.0
BPE Fahot I24 5.0
BPE Fahot I24 5.0
BPE Fahot I24 5.0
BPE Fahot ICt I24 5.0
ok<#rm>#rm
ok<#rm>#rm
2 3 * . 6 ok<,am<,a>
Characters are missing whenever a string is sent by the MCU. On the
last start-up message, you can also see out-of-order characters. I've
put a logic analyser on the pins and it looks consistent with the
picture of missing characters shown above (and there were no Xoff
characters in between).
I'm going to try a PIC24FV16KM202 (which fits the same minimal pin
layout) today and see if that behaves better.
Peter J.
On 18/04/14 00:23, Mikael Nordman wrote:
> I don't really understand why the UART silicon bug would cause a problem
> with
> the current FF5.0 code.
>
> The TX interrupt routine only writes one character to the TX FIFO
> if the TXFIFO and TX shift register are empty.
>
> In addition XOFF chars are written without checking if the TX FIFO has
> any space.
> If the PC that sends to the PIC
> reacts slowly on the XOFF, FF will send XOFF for every character
> received from the PC.
> But this should not fill the TX FIFO since it has 4 empty places and the
> RX interrupts
> which may send XOFF occur at the same pace that characters are sent out.
>
> Did you experience any real problem?
> Does the UART TX loose any characters ?
> Are characters lost during flash write ?
>
> BR Mike
>
> On 04/17/2014 03:10 PM, Peter Jacobs wrote:
>> (b) The more troublesome issue is the UART silicon bug in my revision 4
>> chips. There is a work-around of not completely filling the buffer but
>> I think that requires fiddling with the interrupt or queue code, which
>> is a bit beyond my capability at the moment. I added a little bit of
>> code to the main program, as shown below.
>>
>>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
|
|
From: Mikael N. <mik...@pp...> - 2014-04-17 14:23:31
|
I don't really understand why the UART silicon bug would cause a problem with the current FF5.0 code. The TX interrupt routine only writes one character to the TX FIFO if the TXFIFO and TX shift register are empty. In addition XOFF chars are written without checking if the TX FIFO has any space. If the PC that sends to the PIC reacts slowly on the XOFF, FF will send XOFF for every character received from the PC. But this should not fill the TX FIFO since it has 4 empty places and the RX interrupts which may send XOFF occur at the same pace that characters are sent out. Did you experience any real problem? Does the UART TX loose any characters ? Are characters lost during flash write ? BR Mike On 04/17/2014 03:10 PM, Peter Jacobs wrote: > (b) The more troublesome issue is the UART silicon bug in my revision 4 > chips. There is a work-around of not completely filling the buffer but > I think that requires fiddling with the interrupt or queue code, which > is a bit beyond my capability at the moment. I added a little bit of > code to the main program, as shown below. > > |
|
From: Peter J. <pe...@me...> - 2014-04-17 12:11:12
|
Gentlemen,
I've had some success getting FF5.0 to run on a PIC24FV32KA302 but
have a couple of issues.
(a) I can't seem to get the FRCPLL config option to behave as if the PLL
is actually on. I measure a very nice 4.00MHz CLK0 signal on the OSCO
pin whether I choose FRCDIV or FRCPLL. This is probably my simple bug
in the way I've set the config registers. Relevant bits from the config
file below.
(b) The more troublesome issue is the UART silicon bug in my revision 4
chips. There is a work-around of not completely filling the buffer but
I think that requires fiddling with the interrupt or queue code, which
is a bit beyond my capability at the moment. I added a little bit of
code to the main program, as shown below.
Suggestions for an easy fix (hopefully)?
The motivation for playing with this particular processor is that it
looked to be a nice 16-bit complement to the PIC18F26K22 and the
ATmega328P processors which I'm using for the rework the FF tutorial
documents. The FV32KA also runs nicely at 5V. If there's no simple
fix, I'll choose another processor.
Regards,
Peter J.
-----------------------------------------------------------
p24f16ka_config.incafter line 4
-----------------------------------------------------------
.ifdef __24F16KA102
;;; Below is the setting for max amount of ram for PIC24F16KA102
.equ FLASH_SIZE, 0x2C00 ; Flash size in bytes without the high byte
; See program memory size in the device
datasheet.
.equ RAM_SIZE, 0x0600 ; Ram size in bytes
.equ EEPROM_SIZE, 0x0200 ; Eeprom size
config FOSCSEL, FNOSC_FRCPLL
config FOSC, FCKSM_CSDCMD & SOSCSEL_SOSCLP & POSCFREQ_MS & OSCIOFNC_OFF
config FWDT, FWDTEN_ON
config FPOR, MCLRE_ON & BORV_V18 & I2C1SEL_PRI & PWRTEN_ON & BOREN_BOR3
.equ PROCESSOR_IS_SELECTED, 1
.endif
.ifdef __24FV32KA302
.equ FLASH_SIZE, 0x5800 ; Flash size in bytes without the high byte
; See program memory size in the device
datasheet.
.equ RAM_SIZE, 0x0800 ; Ram size in bytes
.equ EEPROM_SIZE, 0x0200 ; Eeprom size
config FOSCSEL, FNOSC_FRCPLL & SOSCSRC_ANA & LPRCSEL_HP & IESO_ON
config FOSC, POSCMOD_NONE & FCKSM_CSDCMD & SOSCSEL_SOSCLP & POSCFREQ_MS
& OSCIOFNC_ON
config FWDT, FWDTEN_ON & WDTPS_PS32768 & FWPSA_PR128 & WINDIS_OFF
config FPOR, MCLRE_ON & BORV_V20 & I2C1SEL_PRI & PWRTEN_ON & BOREN_BOR3
& LVRCFG_OFF
config FICD, ICS_PGx2
.equ PROCESSOR_IS_SELECTED, 1
.endif
.if PROCESSOR_IS_SELECTED < 1
.error "Did not select one of our known processor configurations."
.endif
.equ FREQ_OSC, (8000000) ; Clock (Crystal) frequency (Hz)
---------------------------------------------------------------------
ff-pic24-30-33.s after line 827
---------------------------------------------------------------------
; ---------------------------------------------------------
; Addition to get UART1 working PIC24FV32KA302.
; PJ 2014-04-17
.ifdef __24FV32KA302
bclr ANSB, #ANSB2 ; want U1RX as digital on pin 6
; To work around silicon issue 5 for revision 4 chips.
bclr U1STA, #UTXISEL0
bclr U1STA, #UTXISEL1
; Still need to work around issue 4 by not sending more
; than three bytes at a time.
; Maybe some fix can be made in __U1TXInterrupt0:
; around line 361 in this file.
.else
; As Mike had it: interrupt when last character is shifted out
; of Transmit Shift Register.
.ifdecl UTXISEL1
bset U1STA, #UTXISEL0
.else
bset U1STA, #UTXISEL
.endif
.endif
; ---------------------------------------------------------
|
|
From: Mikael N. <mik...@pp...> - 2014-04-05 05:24:27
|
Hello Pete, The status is that I have done nothing in this area. I think the math routines are written in assembly and have a C-interface description. Maybe also a assembly interface descriptio can be found. In general code in linked libraries is simplest to call from words defined when the FF core is compiled and linked to some library. C4add.c is a simple example of this. For example the following stuff could be described in the wiki. 1. The interface to the math libraries 2. Linking math routines to FlashForth words 3. Parse fixed point number 4. Print fixed point number 5. Parse floating point number 6. Print fixed point number 7. Linking C-routines to FF. BR Mike |
|
From: Pete Z. <pza...@pz...> - 2014-04-03 17:53:58
|
Hi Mikael and all, Where do we stand with interfacing the C Math Library Functions in the MPLAB XC16 Standard Compiler into FF for the PIC 16bit processors? Specifically, has anyone put together a template (register saves, fixed-point or floating-point interface, etc) for the use of some of these functions (e.g. log, exp, sin, cos, etc.)? Is this something we should get together and have a 'work group' address for the good of the FF community? Certainly a section in the wiki could focus on this FF and C interfacing and be a great place for folks to post their solutions, helpful hints and examples. Thoughts, comments......? Pete |
|
From: Mikael N. <mik...@pp...> - 2014-04-03 05:32:37
|
The 2.4.2014 contains some bugfixes and some other improvements. So I recommend using that one. I have a Olimex board (not Arduino) that has a 8 MHz crystal which is the main development board. I get the 7 warnings also. The compiler seems to produce correct code anyway. BR Mike |
|
From: craig b. <dab...@ya...> - 2014-04-02 20:17:24
|
Oh, I forgot to mention that AtmelStudio 6.1 gives me 7 warnings every run... 4 for register re-.DEF and 3 Unknown Foreward Ref-s on the selected serial. Don't have a clue why, yet. I added an Arduino Plugin for Visual Studio, could that be a problem? craig ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... |
|
From: craig b. <dab...@ya...> - 2014-04-02 20:09:07
|
Thanks for the info, Mike. I was able to latch onto an AVRISP-mkII that solved my code migration problem. I have no clue why the USB-Serial bridge doesn't want to work, it did just fine with the Arduino demos. I hung a home-brew RS232 converter on the Tx0 and Rx0 pins and my 15.11.2013 build burn seems to work ok. Is there a reason that the 5.0 source is set for 8Mhz xtal while the v4.8 code uses 16Mhz? I used 16 because that's what I read on the top of the xtal-can. Thanks again, craig ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... |
|
From: Mikael N. <mik...@pp...> - 2014-04-02 18:51:47
|
The latest FF (from today) in GIT contains the latest code in hex files for the ArduinoMega and ArduinoUno. These are in the avr/hex directory. Program the hex file into the ArduinoMega with a ICSP programmer. It will overwrite the the Arduino firmware and replace it with FlashForth. You can access the FF via the USB serial port. 38400 baud XON/XOFF. When dumping files to FF a 1 millisecond delay between characters will guarantee reliable operation. Regrettably the Arduino USB-serial bridge does not support low latency flow control. The queues are too long. When compiling from source in the atmel studio you need to define a project with the ff-atmega.asm. Select the right include file in config.inc and configure the rest of the parameters. Compile it and program the resulting hex file unto the Arduino. BR Mike |
|
From: craig b. <dab...@ya...> - 2014-04-02 12:42:09
|
I've just had an Arduino Mega 2560 board dropped into my lap. I've installed Atmel Studio 6.1 and Arduino 1.0.5-r2 both of which appear to be working (BLINK compiles and loads and even runs as a SKETCH in the Arduino IDE). I looked back and found the old posting that FF ran on a 2560 board, but I've got no clue about Atmels or Arduinos at this stage of the game. I'ld love to annoy another engineer here with an Arduino running FForth, Is there a walk-through for getting it up or at least a road-map of some sort for the Atmel-Impared to learn from? Thanks for your time, craig bair (binary behaviorist) ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... |
|
From: Pete Z. <pza...@pz...> - 2014-03-29 20:39:52
|
Thanks guys, Operator Error..... Sometimes you just have to PRINT out the config file on hard copy and go through it line...by...line. Pete On 3/28/2014 11:47 PM, Mikael Nordman wrote: > Look for Holger in Forum: Open Discussion ! > > He is using that chip. > > BR Mike > > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > |
|
From: Mikael N. <mik...@pp...> - 2014-03-29 04:47:50
|
Look for Holger in Forum: Open Discussion ! He is using that chip. BR Mike |
|
From: Mike M. <mi...@mo...> - 2014-03-29 00:21:21
|
Pete, Not quite. But we did bring up FF 4.8 on the PIC24FJ128GA010 on the Microchip Explorer 16 board last year. Most of the difficulty was in getting the config bits right. Also check PFLASH We are now using the PIC24FJ256GB110, FF 4.8 Michael: Yes, I will post the code for some FF utilities. We will also post some bug fixes soon. Mike Miller Moon Valley Circuits http://www.moonvalleycircuits.com/ 3/28/14 3:29 PM, Pete Zawasky wrote: > Has anyone gotten the DM300027 Demo Board with PIC24FJ64GA002 up and > running ? Especially with FF 5.0 . > > Have had good luck in the past with the dsPIC4012 on this demo Board, > but no communication when using the PIC24FJ64GA002. > Clock and UART pins have been edited to match the board schematic. > > Ideas? > > Pete > > ------------------------------------------------------------------------------ > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel > > |
|
From: Pete Z. <pza...@pz...> - 2014-03-28 21:29:36
|
Has anyone gotten the DM300027 Demo Board with PIC24FJ64GA002 up and running ? Especially with FF 5.0 . Have had good luck in the past with the dsPIC4012 on this demo Board, but no communication when using the PIC24FJ64GA002. Clock and UART pins have been edited to match the board schematic. Ideas? Pete |
|
From: pito <pi...@vo...> - 2014-03-28 13:17:10
|
Hi, maybe somebody interested in an 8MB large ramdisk (an external ram) which can be connected to an MCU with 11 lines only (8 data and 3 control signals) so easy to be connected to any MCU even a small 8bitter. The advantage over an Sdcard is it has no latencies and unlimited endurance, faster even with bitbanging. Good for swaps, buffers, caches, small ramdisks, when FF gets a small file system for it :). http://www.rlx.sk/sk/storage-boards-memorystorage-boards-memory/2559-ramdisk-8mb-8mx8-8mbytes-with-8bit-parallel-access.html Pito |
|
From: Mikael N. <mik...@pp...> - 2014-03-27 20:51:32
|
It's a bug in a FlashForth system. All stack manipulating words are written so that the stack can be anywhere. Let's say the word is used in one of many background tasks. It's a bit difficult to predict if the word will be used on a page boundary or not. If you don't use the word in a BG task you will in practice get away with it. But somebody else may not and be hit with a really subtle bug. Peace ! Mike On 03/27/2014 09:57 PM, craig bair wrote: > The way you wrote the initial stack allocation and the size limit you > specified won't allow it to cross a page boundry, therefore there's no > bug. (grin) Thought of that when reverse engineering the locations > the sp pointed at. Re-read the source to be sure. Actually, my first > try had the FSR0 inc and dec reversed with amusing results... > |
|
From: craig b. <dab...@ya...> - 2014-03-27 20:00:25
|
The way you wrote the initial stack allocation and the size limit you specified won't allow it to cross a page boundry, therefore there's no bug. (grin) Thought of that when reverse engineering the locations the sp pointed at. Re-read the source to be sure. Actually, my first try had the FSR0 inc and dec reversed with amusing results... craig ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... You cannot inc/dec the 12 -bit fsr pointer over a 256 byte page boundary :-) It will stay on the same page. You have to use the special registers that change the whole pointer, or deal with the carry status. |
|
From: Mikael N. <mik...@pp...> - 2014-03-27 19:46:26
|
You cannot inc/dec the 12 -bit fsr pointer over a 256 byte page boundary :-) It will stay on the same page. You have to use the special registers that change the whole pointer, or deal with the carry status. My comment about Atmel was only that since FlashForth supports three processor architectures I try to align the wordnames for those as much as possible. BR Mike On 03/27/2014 09:28 PM, craig bair wrote: > Well Mike, unless the Pic Wreg is a problem or there's some hidden > instruction assembled that you haven't warned us about, no, there > isn't. Never made any rash claims about Atmels... Never met up with > one. 8-bit Pic assembler is my playground for the last few decades, > though and if you see something I've missed in that word, I'll be > impressed (grin). > |
|
From: craig b. <dab...@ya...> - 2014-03-27 19:31:50
|
Well Mike, unless the Pic Wreg is a problem or there's some hidden instruction assembled that you haven't warned us about, no, there isn't. Never made any rash claims about Atmels... Never met up with one. 8-bit Pic assembler is my playground for the last few decades, though and if you see something I've missed in that word, I'll be impressed (grin). craig ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... That's great Craig, but can you spot the bug in your code ? It can also be done with temp registers, since FF has alot of interrupt safe temp registers, Tp(fsr1) in this case. |
|
From: Mikael N. <mik...@pp...> - 2014-03-27 19:30:38
|
Did you consider this ? \ i2c wakeslave \ NOTE: the 7 bit address is in bits 7-1. \ Bit 0 is the R/W bit. I dont know if it makes any difference, but are you using this latest version of sspbuf! ? : sspbuf! ( c -- ) \ sspbuf! takes 90 us @ 100 KHz sspbuf c! [ pir1 sspif a, bcf, ] [ begin, ] [ pir1 sspif a, btfss, ] [ again, ] ; On 03/27/2014 02:05 PM, Peter Jacobs wrote: > To me, this sounds like the slave is not acknowledging, the PIC is > waiting and the watch-dog timer expires. Hence, the reboot. Can you > put an oscilloscope or logic analyser on the I2C lines to see if the > slave is actually acknowledging the address byte on the 9th clock? > Peter J. > > > On 27/03/14 17:14, Thomas Buschhardt wrote: >> Hallo, >> >> I've problems to get my I2C-Master running. Here is my config: >> >> PIC18F2620 >> Clock 8MHz >> OSC = INTIO67 >> TemperaturSensor: DS1621 >> >> Here is what I do: >> I connect the sensor SDA with PIC.Pin 15 and the SCL with PIC.PIN 14. >> I tested different pullup-resistors on both lines (10K - 3.3K - 1.8K). >> I tested different sensor-addresses: 1001 000 (all AddressPINs GND) >> and 1001 100 (A2 with 10K resisitor to 5V, A1-A0 GND) >> >> I import i2c_base.txt (\flashforth\PIC18\forth) and use the example >> from ff-tutorial-guide.pdf. >> >> When I run the "init_(tempsensor)" the PIC reboot. I find out that >> ":i2cinit" come back with "OK", but when I run ":i2cws" (+ slaveaddr) >> the PIC reboot. >> >> I know the Sensors are ok, because I tested them in a selfmade >> heating control (since 2010 - written in Ruby - sorry :-)) and I have >> ca. 10 of these IC's there. >> >> If I can send any more informations please drop a mail :-) >> >> Thank you >> Thomas >> |
|
From: Mikael N. <mik...@pp...> - 2014-03-27 19:22:22
|
I plan now to do it like this Just one punctuation char for grouping digits. Single precision number #-10.345 %1011.1101.1111.0000 $fad.e Double precision numbers %1011.1101.1111.0000. #-10.345. $fade.babe. Mike Miller, Do you have some code you could share ? For instance on the FF Wiki. You can add new pages there, just a SF account is needed. It would be great to get more community contribution to this open source project. BR Mike On 03/27/2014 08:25 AM, Mike Miller wrote: > Forth typically converts a double number when there is ANY of the following punctuation chrs present anywhere in the number , . / - : > The exception is a leading - chr which indictes a negative number. See Starting Forth, Leo Brodie. > > These punctuations support European and US number and time formats, and many others. I see nothing wrong with adding the _ chr. > > FF 4.8 only recognizes a . chr at the end of the digits, so I needed to write my own number conversion word. > A double number format closer to the standard would be nice. > > > Mike Miller > Moon Valley Circuits > mi...@mo... > http://www.moonvalleycircuits.com/ > > > On 3/26/14 10:38 AM, Mikael Nordman wrote: >> I could easily extend the FF >number so that it >> would work as today but just ignore certain punctuation. >> >> What would be the best choice for punctuation ? >> Perhaps the comma character. >> >> Or use the period anywhere in number to indicate that it as double number. >> Not having any punctuation in single numbers. This is how >> it is described in Forth Programmers Handbook. >> >> Single precision number >> #10,345 >> %1011,1101,1111,0000 >> $fad,e >> >> Double precision numbers >> %1011_1101_1111_0000. >> #10,345. >> $fade,babe. >> $f,a,d,e,b,a,b,e. >> >> >> You proposal with separate parsing words can be implemented as an add-on >> if wanted. >> >> BR Mike >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Flashforth-devel mailing list >> Fla...@li... >> https://lists.sourceforge.net/lists/listinfo/flashforth-devel >> >> > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: Mikael N. <mik...@pp...> - 2014-03-27 19:15:47
|
That's great Craig, but can you spot the bug in your code ? It can also be done with temp registers, since FF has alot of interrupt safe temp registers, Tp(fsr1) in this case. Swapbytes is called '><' in the Atmega FF. It was needed there to manipulate return addresses. : >< [ Sminus, w, a, movf, ] [ Srw, Tp, movff, ] [ Splus, a, movwf, ] [ Tp, Srw, movff, ] ; BR Mike On 03/27/2014 08:18 PM, craig bair wrote: > I needed to swap bytes to send to another machine, so I implamented > one of my favorite tricks from "back in the day" when I was learning > MACRO-11 on the college PDP-11/40... Swapping register contents > without auxiliary storage. Mike's made it easy for us in the Pic18-s, > probably the rest of the chips, too. > > swapbytes ( xy -- yx ) \ reverses byte order on Top-Of-Stack > > craig bair > > --------------- > > \ Reverse ENDIAN-ness of 16-bit on Top Of Stack > \ i.e. Swap Bytes > \ ...minimalist approach, no temp storage loc > \ > \ needed constants (could be hardwired into code > $ffe9 constant fsr0 \ ; 0xFE9 FSR0L > \ $ffea constant fsr0h \ ; 0xFEA FSR0H > $ffef constant indf0 \ INDirect-by-FSR0 FileRegister > 1 constant f, \ Destination File > \ > \ needed assembler constructor > : as2 ( opcode "name" -- ) ( f a -- ) > co: > does> rot ic, or ic, ; > \ > \ needed assembler instructions > $04 as3 decf, ( f d a -- ) > $28 as3 incf, ( f d a -- ) > $18 as3 xorwf, ( f d a -- ) > $6e as2 movwf, ( f a -- ) > \ > \ actual word > : swapbytes ( xy -- yx ) \ swap Hi:Lo bytes on Top of Stack > [ indf0 w, a, movf, ] > [ fsr0 f, a, decf, ] > [ indf0 f, a, xorwf, ] > [ indf0 w, a, xorwf, ] > [ indf0 f, a, xorwf, ] > [ fsr0 f, a, incf, ] > [ indf0 a, movwf, ] > ; > > ...averaging may or may not help clarify data. > If Bill Gates walks into a bar, > the average patron becomes a millionaire... > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Flashforth-devel mailing list > Fla...@li... > https://lists.sourceforge.net/lists/listinfo/flashforth-devel |
|
From: craig b. <dab...@ya...> - 2014-03-27 18:21:58
|
I needed to swap bytes to send to another machine, so I implamented one of my favorite tricks from "back in the day" when I was learning MACRO-11 on the college PDP-11/40... Swapping register contents without auxiliary storage. Mike's made it easy for us in the Pic18-s, probably the rest of the chips, too. swapbytes ( xy -- yx ) \ reverses byte order on Top-Of-Stack craig bair --------------- \ Reverse ENDIAN-ness of 16-bit on Top Of Stack \ i.e. Swap Bytes \ ...minimalist approach, no temp storage loc \ \ needed constants (could be hardwired into code $ffe9 constant fsr0 \ ; 0xFE9 FSR0L \ $ffea constant fsr0h \ ; 0xFEA FSR0H $ffef constant indf0 \ INDirect-by-FSR0 FileRegister 1 constant f, \ Destination File \ \ needed assembler constructor : as2 ( opcode "name" -- ) ( f a -- ) co: does> rot ic, or ic, ; \ \ needed assembler instructions $04 as3 decf, ( f d a -- ) $28 as3 incf, ( f d a -- ) $18 as3 xorwf, ( f d a -- ) $6e as2 movwf, ( f a -- ) \ \ actual word : swapbytes ( xy -- yx ) \ swap Hi:Lo bytes on Top of Stack [ indf0 w, a, movf, ] [ fsr0 f, a, decf, ] [ indf0 f, a, xorwf, ] [ indf0 w, a, xorwf, ] [ indf0 f, a, xorwf, ] [ fsr0 f, a, incf, ] [ indf0 a, movwf, ] ; ...averaging may or may not help clarify data. If Bill Gates walks into a bar, the average patron becomes a millionaire... |
|
From: Peter J. <pe...@me...> - 2014-03-27 12:05:56
|
To me, this sounds like the slave is not acknowledging, the PIC is waiting and the watch-dog timer expires. Hence, the reboot. Can you put an oscilloscope or logic analyser on the I2C lines to see if the slave is actually acknowledging the address byte on the 9th clock? Peter J. On 27/03/14 17:14, Thomas Buschhardt wrote: > Hallo, > > I've problems to get my I2C-Master running. Here is my config: > > PIC18F2620 > Clock 8MHz > OSC = INTIO67 > TemperaturSensor: DS1621 > > Here is what I do: > I connect the sensor SDA with PIC.Pin 15 and the SCL with PIC.PIN 14. > I tested different pullup-resistors on both lines (10K - 3.3K - 1.8K). > I tested different sensor-addresses: 1001 000 (all AddressPINs GND) > and 1001 100 (A2 with 10K resisitor to 5V, A1-A0 GND) > > I import i2c_base.txt (\flashforth\PIC18\forth) and use the example > from ff-tutorial-guide.pdf. > > When I run the "init_(tempsensor)" the PIC reboot. I find out that > ":i2cinit" come back with "OK", but when I run ":i2cws" (+ slaveaddr) > the PIC reboot. > > I know the Sensors are ok, because I tested them in a selfmade heating > control (since 2010 - written in Ruby - sorry :-)) and I have ca. 10 > of these IC's there. > > If I can send any more informations please drop a mail :-) > > Thank you > Thomas > |
|
From: Thomas B. <bus...@gm...> - 2014-03-27 07:14:21
|
Hallo, I've problems to get my I2C-Master running. Here is my config: PIC18F2620 Clock 8MHz OSC = INTIO67 TemperaturSensor: DS1621 Here is what I do: I connect the sensor SDA with PIC.Pin 15 and the SCL with PIC.PIN 14. I tested different pullup-resistors on both lines (10K - 3.3K - 1.8K). I tested different sensor-addresses: 1001 000 (all AddressPINs GND) and 1001 100 (A2 with 10K resisitor to 5V, A1-A0 GND) I import i2c_base.txt (\flashforth\PIC18\forth) and use the example from ff-tutorial-guide.pdf. When I run the "init_(tempsensor)" the PIC reboot. I find out that ":i2cinit" come back with "OK", but when I run ":i2cws" (+ slaveaddr) the PIC reboot. I know the Sensors are ok, because I tested them in a selfmade heating control (since 2010 - written in Ruby - sorry :-)) and I have ca. 10 of these IC's there. If I can send any more informations please drop a mail :-) Thank you Thomas |
17 messages has been excluded from this view by a project administrator.
