Objective Development Forums

This is an extension of the poorly titled thread
viewtopic.php?f=8&t=5724#p19549

Volker writes:

Pls. note that Pin B2 is also the Int0 input pin. V-USB seems to use this interrupt. So if you connect the USB D+ data line to another pin, you have to figure out which interrupt can be used by v-usb. In your case you connect D+ to B3 and therefore you must enable PCINT3 and provide v-usb with the corresponding irpt vector number. But this is clearly described in usbconfig.h -- pls. read the comments!

Here are the relevant entries for usbconfig.h:

Code: Select all
#define USB_CFG_IOPORTNAME B
#define USB_CFG_DMINUS_BIT 4
#define USB_CFG_DPLUS_BIT 3

#define USB_INTR_CFG PCMSK
#define USB_INTR_CFG_SET (1 << PCINT3)
#define USB_INTR_CFG_CLR 0
#define USB_INTR_ENABLE GIMSK
#define USB_INTR_ENABLE_BIT PCIE
#define USB_INTR_PENDING GIFR
#define USB_INTR_PENDING_BIT PCIF
#define USB_INTR_VECTOR PCINT0_vect



Note that you should avoid using interrupts of a higher priority than PCINT0.


Cheerieo,
Volker.

Thanks Volker for your response. I am in the midst of changing the pin mapping and see that the existing code uses firmware INT0, which is dedicated to pin7 (PB2) on the tinyx5, which we will need for the SPI clock signal.

I see that we have pin change interrupt 0 (firmware PCINT0; another interrupt unique from INT0), and that there are four clock cycles latency on the pin change interrupt.
The timing is already tight within the usb implementation and I do not understand whether this is pushing it too far. Any advice on this is welcome, preferably with analysis. I've looked at the 16.5MHz assembly code, but still don't understand it. We are going against the comments in usbconfig.h here which states:
"Please note that D+ must also be connected to interrupt pin INT0!"
which means the hardware interrupt0 rather than the PCINT0 I guess, so we are beyond proper behavior here, but this is an opportunity to learn. Volker's comments and example code suggest that we can get this working!

To me the proper method of porting over the EasyLogger code to the SPI implementation should be done carefully. There are several intermediate steps to a methodical implementation. First we've got to disable the ADC and KeyPress code to free up PB5 and PB3. This means generating some fake keypress report, at which point my own code is spitting out quite a bit of junk, so I've got some more work to do just to get through this stage.

I do see that eventually we would have the nicety of a host hooked up to both the parallel port(SPI) and the USB port(v-usb firmware), and this could be an invaluable debugging implementation even for the code we are possibly going to implement here. The next step will be to get away from the keyboard HID, which I only barely appreciate just yet.

Again, if this can work then this is a minimalist implementation that could become a programmer or a stdio channel. Minimal parts/pin count...
So I hope to draw somebody else into this. This is potentially a good project.

- Tim

Hi Tim,

Tim_BandTech.Com wrote:I see that we have pin change interrupt 0 (firmware PCINT0; another interrupt unique from INT0), and that there are four clock cycles latency on the pin change interrupt.

I had a short look into the 85's datasheet. Only Int0 has a higher priority than PCINT0. So if you don't use INT0 in your application, v-usb should work with PCINT0 w/o any problems.

Just try it out -- I'm quite confident it will work I've done something similar. My application uses the USI-Overflow Irpt. and v-usb runs on PCINT0 -- it works like a charm!

Cheerio,
Volker.

Thanks very much Volker.

I did use your usbconfig.h lines verbatim and it worked on my first try.
The trick was getting some sense out of the HID keyboard code.
Now that I understand it I see it is fairly simple.
I'm printing one character per second now, which in itself has debug possibilities.
I still have not attempted any SPI. Here is my SpiLogger output direct to this web app:
234567890
1234567890
1234567890
123

Not sure why the first report(the first '1') doesn't work. Saw that in the original Logger code too.
Thanks Christian Starkjohann and whoever else I should thank... There is rather a long stack of shoulders that we are upon. The accumulation is daunting, but the slenderness of the AVR chips helps to ease that.

- Tim

As I go along researching and learning about usb, I see that the logger with its HID keyboard interface is pretty limited.
Still, the behavior could be very practical in terms of debugging an end-user product, whereby system tracing via debug statements could remain in code for some pilot projects, left off-site with a client. The beauty of this method is that they simply connect their computer up to the device while they are in a web page such as this one.
They then disconnect, send the page, and the developer has a trace of the product's behavior, with nearly no client-end effort.

I see that
http://www.recursion.jp/avrcdc/cdc-spi.html#sample
is a more practical instance of what I am trying to do, which relies upon the usb CDC device implementation.

Still, the EasyLogger is a great way into these things since it requires zero host setup. So unique also to find input into any application from such little hardware. This is the beauty of the keyboard HID interface that usb provides. I recommend taking these same steps for newbies as incremental learning, but the keyboard HID is still mostly a mystery to me. The next step of this project to me is to discover how to get ASCII to translate to the keyboard HID codes. Any advice is welcome.

- Tim