USB in forth on the SAM7I've looked at the USB peripheral on the SAM7 a few times but never got very far with it - it just looked too hard. There are several examples out there written in C and they looked difficult to convert to forth. They use some predefined and newly defined structures which I had to untangle.
I was not sure how fussy the timing was or how much of the code I needed.
It turns out the timing is extremely forgiving and you can have quite long pauses with out problems. Printing debugging information on the serial lines does not cause a problem.
It also turns out only a half a dozen enumeration methods of the twenty or so in the demo code are needed for a CDC (Communications device class).
I think the code could be further simplified for cases like mine where the USB payload is less than 64 bytes.
My aim is to make a USB to TWI/I2C converter.
These things already exist but I want non-standard clock rates. By slowing the clock I can extend the range without using any boosters.
There are also open-sourced converters including one using a tiny AVR with no USB or TWI support and everything bit banged (it makes my project look positively wimpy).
I choose to use SAM7 because I wanted to get my head around USB so I can (in future) use it as an option to communicate with my EMForth system. This is a low priority though because I also have to find time to write a new server which supports virtual comms ports.
As a fall back I have a arduino to use, this uses an FTDI chip the convert USB to serial but this is a step I'd like to eliminate.
10'th May 2009,The are two parts to the problem.
The first is the enumeration where the hosts works out what has been poked into its hole. Quite few messages get passed back on forth before the PC knows what drivers to load and so forth.
When you get that right you are rewarded with a line in the device manager showing you device listed.
11'th May 2009,I've managed to port the basic USB loop back program to Forth and can connect to it via hyperterminal or my c# based emserver (which is not compete but can do simple dumb terminal comms).
21'st May 2009,It has been a long time in the making but I can now access SAM7 emforth without a real com port.
It only supports dumb terminal mode for now but this can still be pretty useful to me.
Server client mode will not happen for some time.
This project is a USB to TWI/I2C converter and the USB part of that now works.
The simplest way to access TWI via the SAM7/USB is to use the existing Forth interpreter but writing a separate command processor is less likely to be crashed. If you allow access to the full power of Forth you also allow commands which will crash the system.
23 May 2009, TWI project on hold.I've just looked the SAM7 data sheet and it appear the SAM7 TWI can only be a master and not a slave. This makes it impractical to set up the TWI network I had in mind. I could do a slave mode by turning off the TWI peripheral and bit banging the lines but it makes the idea less attractive.
The lack of slave mode causes two problems. One is I can't have the TWI/USB sniffing for broadcasts from the network. The other is I planned to use a another SAM7 as one of other devices in the network and one of the SAM7s needs to be a slave.
I didn't expect the SAM7 TWI to be inferior to the AVR TWI. The AVR (as used in arduino) can do both master and slave modes. I'm likely to have several AVRs in the network but I wanted at least one SAM7 controlling a nokia LCD.
17-July-2009 My TWI-Gateway is working.I made a TWIG using an aurdino. It is written in assembler for the mega328.
Unfortunately it is based on proprietary code and protocols I can't publish.
The protocol is overkill but there are advantages in remaining compatible with my ongoing paid work.
The main TWI code is based on that found in the AVR datasheet.
The arduino IDE also supports TWI but I'm not using any of that code.
I'm putting a few up a few TWI notes.