Hi Mike!
Many thanks for the USB self-powered mode support. It was working fine with the version of FF38 aug 30.
Unfortunately I can not use the USB mode in the latest versions. The MPLAB says "build succeeded" but the Windows can not detect the controller as an USB device. I am sure the hardware is good, because the earlier versions are running on it with same configuration. I tried the FF with 18F2550 and 18F14K50, but USB mode doesn't work. The UART mode is good. Have you got any idea?
Other things:
- The 8-bit character mode with USB ( FF37, FF38) is not perfect, because the rx0 eats the zeros. In my experince the following modification fixed the problem:
RX0:
rcall PAUSE
call keyQUSBUSART
addlw 0
bz RX0
RX0_1:
call keyUSBUSART
movwf plusS, A
clrf plusS, A
return
- If the controller sends a character through USB to PC, I can not detect at the PC side the received character in the buffer before reading it, but it readable succesfully. The buffer always seems empty. I tested it only in Rebol, but I think it is a language independent problem, because same test works well using both native RS232 port and USB virtual comport with FT232R. Is it a fixable problem?
Regards:
Attila
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The linker files were not upto date.
Now they should be working.
The 14k50 does work yet because TX0 has some hardcoded addresses
to the 2550 USB buffers.
After I fix that I hope you can test it. I have no 14k50 board .
The filtering of the null chars should be removed.
Regarding the last problem I dont know what could cause that.
I am using an older version of the Microchip USB library code.
Maybe it has that problem.
Does it work better if you send more than 16 characters ?
The USB packet size is 16 bytes.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Attila,
Now there is a version that actually works.
RX0 should now be able to receive null characters.
Please try the FF for USB on 14k50.
There is a chance it could work. You have to check the configuration bits,
and set them for your oscillator.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the fast reply! Already the Windows recognised the device and created a comport, but it is unable to open.
Naturally I ready to test the FF with 14k50.
I have tested the buffer checking problem up to 40 characters, but doesn't work.
Another question.
Somtimes it would be fine to modify the turnkey delay according to the application. Usually a shorter time is enough at the final state of development. Is it possible to determine it in the config file or a FF system variable?
Attila
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The 14K50 still doesn't work.
The Mplab gives the folllowing message with 2550:
Error - could not find definition of symbol 'keyCHAR' in file './ff18_usb.o'.
Attila
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The last version working on win7-64 was 2011-09-18 19:19:46 CEST .
All the newer versions work on win7-32 and win-XP only
If I comment the #define IDLE_MODE line, then the win7-64 recognize the device and creates a comport, but the FF doesn't work properly. using even win7-64, win7-32 or XP. Pressing a key on the terminal, the FF send lot of zeros as echo, and hang up.
Attila
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But why does not win7-64 not work with the FF IDLE_MODE ?
At least its different driver in 64 bit windows and 32 bit windows.
Maybe FF polls too slowly in IDLE_MODE.
I'll have to see if some USB interrupts could be used in FF.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The tx1 works, but rx1 doesn't work on 14K50. The RB5/AN11/RX/DT pin is an analog input after reset. The ANS11 of ANSELH (bit3 of ff7f) must be cleared at initiation.
Attila
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is not important to connect the UART to PC for test. Connect the TX pin to RX for loopback, and try tx1 rx1 sequence. (Using USB as terminal port.) Now it works only if you say before try: 8 anselh mclr
Attila
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mikael,
FF 3.8 is up and running pretty well here…Minor edits to cfg files.etc.
USB - PICDEM FSUSB Demo Board PIC18F4550, 20MHz xtal.
UART - In-house prototyping board PIC18F6527, 32MHz internal oscillator.
Testing and porting of code from past projects continues…
Thanks for FalshForth.
Pete
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm having trouble with the PAD location start and ram Variable definitions colliding.
When I start FF3.8 'pad' and 'ram here' report the same address.
Any thoughts on this?
Pete
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no space alloted for PAD by FlashForth. You have to do it yourself.
FF core does not use PAD
Instead WORD writes the length byte straight into the TIB.
This is OK as long as there are no files or blocks used as input streams.
I made it like this to save ram.
I'll have to clarify the wordlist and user guide.
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Mike!
Many thanks for the USB self-powered mode support. It was working fine with the version of FF38 aug 30.
Unfortunately I can not use the USB mode in the latest versions. The MPLAB says "build succeeded" but the Windows can not detect the controller as an USB device. I am sure the hardware is good, because the earlier versions are running on it with same configuration. I tried the FF with 18F2550 and 18F14K50, but USB mode doesn't work. The UART mode is good. Have you got any idea?
Other things:
- The 8-bit character mode with USB ( FF37, FF38) is not perfect, because the rx0 eats the zeros. In my experince the following modification fixed the problem:
RX0:
rcall PAUSE
call keyQUSBUSART
addlw 0
bz RX0
RX0_1:
call keyUSBUSART
movwf plusS, A
clrf plusS, A
return
- If the controller sends a character through USB to PC, I can not detect at the PC side the received character in the buffer before reading it, but it readable succesfully. The buffer always seems empty. I tested it only in Rebol, but I think it is a language independent problem, because same test works well using both native RS232 port and USB virtual comport with FT232R. Is it a fixable problem?
Regards:
Attila
Hi Attila.
The linker files were not upto date.
Now they should be working.
The 14k50 does work yet because TX0 has some hardcoded addresses
to the 2550 USB buffers.
After I fix that I hope you can test it. I have no 14k50 board .
The filtering of the null chars should be removed.
Regarding the last problem I dont know what could cause that.
I am using an older version of the Microchip USB library code.
Maybe it has that problem.
Does it work better if you send more than 16 characters ?
The USB packet size is 16 bytes.
Mike
Hi Attila,
Now there is a version that actually works.
RX0 should now be able to receive null characters.
Please try the FF for USB on 14k50.
There is a chance it could work. You have to check the configuration bits,
and set them for your oscillator.
Mike
Hi Mike
Thanks for the fast reply! Already the Windows recognised the device and created a comport, but it is unable to open.
Naturally I ready to test the FF with 14k50.
I have tested the buffer checking problem up to 40 characters, but doesn't work.
Another question.
Somtimes it would be fine to modify the turnkey delay according to the application. Usually a shorter time is enough at the final state of development. Is it possible to determine it in the config file or a FF system variable?
Attila
Hi Mike
Sorry, my last reply belongs to the previous version. I try the latest one soon.
Attila
Hi Mike
The 14K50 still doesn't work.
The Mplab gives the folllowing message with 2550:
Error - could not find definition of symbol 'keyCHAR' in file './ff18_usb.o'.
Attila
You must use the lib from late yesterday evening.
Otherwise it will not link (or work).
I quess I will have to build a 14k50 board.
I have some chips, just not any board.
/Mike
I have just pushed to git code that is working with USB on the 18f14k50 and the 2550 family.
I have tested it on my new 14k50 board.
Note the changed setup of the compilation. Read install.txt.
I also put in the turnkey delay parameter in the config file.
/Mike
Thanks Mike! Everything works well.
Attila
Hello Mike!
The last versions of FF3.8 result "unknown device" in Win7 64bit system, but no problem under Win7 32bit.
I have tried it with 18F4550 and 18F14K50.
Attila
Did win7-64 work in some earlier version?
Did you try to disable the idle mode powersaving in FF?
Mike
The last version working on win7-64 was 2011-09-18 19:19:46 CEST .
All the newer versions work on win7-32 and win-XP only
If I comment the #define IDLE_MODE line, then the win7-64 recognize the device and creates a comport, but the FF doesn't work properly. using even win7-64, win7-32 or XP. Pressing a key on the terminal, the FF send lot of zeros as echo, and hang up.
Attila
I just pushed the correction for the non-IDLE_MODE problem.
There was a return statement missing due to a wrongly placed #endif.
Does it now work with win7-64 without idle mode support ?
BR Mike
Already the FF with non-idle mode works also with win7-64.
Attila
Good that it works.
But why does not win7-64 not work with the FF IDLE_MODE ?
At least its different driver in 64 bit windows and 32 bit windows.
Maybe FF polls too slowly in IDLE_MODE.
I'll have to see if some USB interrupts could be used in FF.
Mike
The 18F4553.lib has processor type problem too.
Otherwise thanks for the 512byte extra free space, it is beneficial especially at the 14K50.
Attila
The tx1 works, but rx1 doesn't work on 14K50. The RB5/AN11/RX/DT pin is an analog input after reset. The ANS11 of ANSELH (bit3 of ff7f) must be cleared at initiation.
Attila
Ok.
My 14K50 board does not have the UART connected so I never tried it.
I'll fix that in the near future.
Mike
It is not important to connect the UART to PC for test. Connect the TX pin to RX for loopback, and try tx1 rx1 sequence. (Using USB as terminal port.) Now it works only if you say before try: 8 anselh mclr
Attila
Hi Mikael,
FF 3.8 is up and running pretty well here…Minor edits to cfg files.etc.
USB - PICDEM FSUSB Demo Board PIC18F4550, 20MHz xtal.
UART - In-house prototyping board PIC18F6527, 32MHz internal oscillator.
Testing and porting of code from past projects continues…
Thanks for FalshForth.
Pete
Hi Mikael,
I'm having trouble with the PAD location start and ram Variable definitions colliding.
When I start FF3.8 'pad' and 'ram here' report the same address.
Any thoughts on this?
Pete
Never mind…..Looks like I have to 'allot' pad space even in a single task application.
Pete
There is no space alloted for PAD by FlashForth. You have to do it yourself.
FF core does not use PAD
Instead WORD writes the length byte straight into the TIB.
This is OK as long as there are no files or blocks used as input streams.
I made it like this to save ram.
I'll have to clarify the wordlist and user guide.
Mike