Activity for Amt
-
Amt modified a comment on discussion General Discussion
That makes a lot of sense, actually! I suppose the only advantage for the 805 parts is with marking their presence in the layout. At the moment, I just solder them on the final board without mentioning anywhere. On the actual board, there is some space savings because the SMT part can be inserted between the 2.54x2.54 mm grid. I'll try to help you add them and push the changes back. Let me see how the footprints are encoded.
-
That makes a lot of sense, actually! I suppose the only advantage for the 805 parts is with marking their presence in the layout. At the moment, I just solder them on the final board without mentioning anywhere. I'll try to help you add them and push the changes back. Let me see how the footprints are encoded.
-
I like how currently SOIC chips can be added into VeroRoute. Are there any plans to add support for more of the simple SMT footprints? (TSSOP, QFP, 0805, SMA etc). This would make the tool even more useful. Thanks in advance!
-
I tried to port it but it seems to use configs/code from both K42 and non-K42 sections and PPS settings are new. This chip has enough memory AFAIK for FF.
-
Chaning the stringlength to 37 from 38 resolved the issue! Ah, I see so the PICTYPE could arbitarily have a length of 10 or 11 depending on the chip and this causes the VER to mismatch and cause this issue, makes sense. I wonder if a macro could solve this issue.
-
Hi, Looks like the 2.40 version of PIC-AS aslo has this issue. Just tried rebuilding with it. Is there some way to detect these RJMPs ? It's funny how it worked well in some old version. XC8 is progressing backwards ! off-topic : Is there any benefit / issue with enabling the extended instruction set?
-
I flashed FF onto a PIC18F4520 today using AS from mplabX 6. Forth works on it but the warm word doesn't seem to do anything. Could you guide me on what might be wrong Several months ago I had flashed the same chip with an older version of FF using mplab 8 and that didn't have this issue. This is the output of warm ok<#,ram> ok<#,ram> warm & ok<#,ram> ok<#,ram> warm &
-
Thanks! will experiment with this soon. I'm trying to standardize on a one PIC device so got curious about a few things: What aspects of the K42 and Q41 series affect FF operations? I noticed a difference in the flash erase size. Other than not having EEPROM, shouldn't any PIC18 with flash > 8KB work ? What pic18 chips work best for FF? and I'm curious why. How about pic24 vs pic18 when it comes to FF? which one is better supported? or are there any caveats ?
-
Hi, Could you help guide me again on what things should be modified to enable FF on this chip: 1. What header file should I start with? (also curious why) 2. How do I set the flash size? (I remember being told to subtract the SFR range from the total flash size but the pre existing headers don't match this calculation) regards, LeS
-
the 'hi' word reports only about 18K. Shouldn't it be 64K? how could this be resolved? This is on a fresh setup with .equ FLASH_SIZE, 0x2a800 ok<#,ram> hi ok<#,ram> 18431 here ok<#,ram> 18431 5836
-
Seems like a good place to store font data with a custom flash routine written in Forth! So, there is no way to extend FF's address space limits? Also, is there an assembler for PIC24? I couldn't find one in the forth directory.
-
Seems like a good place to store font data with a custom flash routine written in Forth! So, there is no way to extend FF's address space limits?
-
Given how FF can't access beyond 64K (due to the 16 bit address size), can the FF code be loaded at locations beyond this range? This way the lower 64K can be used for user forth code.
-
I thought that define was set in the library, let me check it. Thanks!
-
I've pushed my changes to a fork of FF in github and did a pull request :) Should the boot flash protection be turned on? this device supports a maximum boot flash size of 8KB which I think is a bit less than what FlashForth uses. Also, can FF utilize flash regions larger than 64Kb? just asking because the pointer seems to be 16 bits.
-
The chip has 0x4000h bytes of ram but FF seem to hang if I use anything larger than 0x3800h. Is this expected?
-
Mikael, The new config works! I pulled the latest git master branch and tweaked the files to include the p24jf_ga_config.inc. Some minor changes had to be made in the inc file (frequency, rpo/rpin config etc). This has been tested on MPLABX v5.50 and XC16 v 1.70. I had to add in a c based configuration file. How shall I give you my local updated configs? I'm also happy to note that AVT can be enabled without any issues now. It seems that just having the config c file is sufficient to make it work....
-
hmm... this looks different from the one I'm using. I'll try this as soon as the uart works.
-
The UART seems to work fine with no issues in the sim, but on the real device it doesn't, for some reason. I'm also a bit surprised that the c UART code works fine, given how I'm doing the exact same thing in assembly. Maybe it inserts some init code when compiling the c code. It's weird.
-
"Apparently my website has become faulty over time. I mean about supporting all chips..." Nah, I wouldn't call it being faulty :) In fact it's a good thing cause we're getting FF to work on more chips. Let me compare the datasheets for the three chips, but I'll also test out the E series configs. Right now I'm validating the serial interface with a short code of my own (to confirm the pins and settings) What do these constants do btw? I can crosscheck the settings against the recommended flash erase...
-
There is something weird going on with the UART, maybe the part has some issue. I see that the UART code doesn't transmit anything if it's called after FILL_RAM. It doesn't make sense, the RAM range is within spec and it doesn't help even when I use a lower value like 0x2000. But, why would writing to user ram space affect the UART module at all? I don't get it
-
Oh, my bad! I've attached the FF config file that gets pulled for this chip.
-
Hi Makael, the spambot is deleting my messages. Here's an update on the UART issue: The asm equivalent of the working C uart code was inserted at different points in the FF code (not simultaneously) The UART transmitted data when the code was run right after reset, from inside __reset The same code when run from within .ifdecl RPINR18, doesn't transmit anything. My suspicion is on some initialization sequence between these two sections. Particularly the OSCCON writes in the __reset section which...
-
There is something wrong with the UART configuration in FF for this part. I don't see any toggles on the tx pin even after inserting an instruction to always write a random value to U1TXREG. Please find the attached c code where the TX pin was found to work correctly. Here are the things I checked in the FF code so far: 1. The baudrate generator register value [it's correct] 2. The RPO/RPI mapping [It's correct, matches the values in my sample code] 3. The RPO/RPI unlocking sequence [it's correc...
-
I've attached the config file with this message. It's a c file that needs to be added to the source tab in the project view. The link is very useful, I had gotten the same "couldn't find alternate vector table address" error initially. The AIVTDIS = OFF is what resolves it (AIVTDIS is for enabling the alternate vector table). Please also note that I've configured the oscillator settings to use an external 16MHz crystal. BTW the newer xc16 compilers do not let us use the config keyword to set config...
-
I'll post here with updates. Currently I'm validating the UART (did I connect the right pins? is the baud rate correct? etc) So far it looks like my UART dogle doesn't receive anything. Even a static letter transmitted right after the UART is brought up.
-
When I quit the debugger and restart it, the code runs till EEWRITE (called from within DP_COLD). My hunch is that it has something to do with the either the EEPROM emulation or the way flash memory is written. Is EEPROM emulation enabled by default on PIC24? if not, how'd I enable it? What additional configuration is needed to customize the flash write/erase to a chip? I suspect our issue is due to some mismatch in the erase page size.
-
I don't have a working FF commandline. The config file seems to map rp2 and rp3 for the UART. The listing option (XC16 > xc16-as > list to file) looks to be enabled already. Is there anything else that could be wrong?
-
It seems to build correctly, but when I debug with a PicKit, the code randomly jumps to __AltMathError and then just loops back to GOTO __reset,__main I'm trying to get FF working on a PIC24FJ256GA705 and also need to get the configuration right. It's set to not use alternative interrupt vectors and the clock source is set to internal RC @ 8MHz
-
Hi, Could you share details on the toolchain and IDE that was used to build a working FlashForth kernel for a PIC24? I have some strange behaviour on Mplab v5.50 with XC v 1.35
-
The support page says that "FlashForth should work on all 16-bit PIC chips with enough flash(>=24Kbytes) and enough ram." but I see assembly code for PIC24 that seems to use the EEPROM.
-
Hi, I'm somewhat new to Forth. The documentation says that a DUP before an IF would be optimized but I don't understand a situation where a DUP before an IF would be useful. Could you help me with some examples? The only situation where I'd use DUP before an IF would be to check for zero/non-zero, but this is already handled with the 0= condition.
-
This is on FF 5.0 on a PIC18F4520 chip. I tried creating a variable x and then wrote inline assembly to use it but it doesn't work. Could you advice on the right way to pass variables or the parameter stack to inline assembly? see test2 2fd8 51a6 movf a6 w b 2fda 0bfa andlw fa 2fdc 6fa6 movwf a6 b 2fde 0012 return
-
Cool, thanks!
-
Hi, I'm mostly curious why the PIC32 bit family is left out given that they'd have enough space and ram to run FF. Is there any plans to add support to them in the future? if not, why?
-
Thanks! that fixed it
-
Hi, I'm using Putty on Window10. The FF crc is (ab0bcdcfce8c26dac019b9d2187e177b82688d63). I'm able to correct typoes at the terminal using a backspace but FF doesn't recognize the newly corrected words. How do I fix this? e.g. The second 'warm' word was corrected from warr using backspace ok<$,ram> warm S FlashForth 5 PIC18F4520 26.11.2020 warm warm ? ~~~
-
This is from a local supplier in India ( USD 3). One board had STM32F as a separate word while the other one had STM32 The one with serial no. D1265A3E was from Amazon India (USD 3). The board quality was poor (plastic buttons, bad lettering and berg strips that cover the silkscreen). This one had STM32F as a single word. I'm surprised that they're being listed as genuine by your firmware. Think that they might have just improved the cloning process?
-
This is from a local supplier in India ( USD 3). One board had STM32F as a separate word while the other one had STM32 The one with serial no. D1265A3E was from Amazon India (USD 3). The board quality was poor (plastic buttons, bad lettering and berg strips that cover the silkscreen). This one had STM32F as a single word.
1