ATMEGA328P on V-USB

[ulao]

anyone try this on usb-V-USB?

[RazorConcepts]

I am also unable to use the mega328p.

I have a fully working version of the mega168 on v-usb, however changing the settings to 328p (and not changing anything else) does not work.

[ulao]

I heard the (p) chips dont work with v-usb. My guess is that atmega168p also does not work. Can we get some confirmation on this?

Ok, here is where I heard that from

viewtopic.php?f=8&t=2663&p=11457&hilit=168p#p11457

rodmolina, never posted the fuses.

objective, says to compile as a 168 but what if its over the size limit?

julian.dasilva, gave a suggestion but I dont understand it

DetlevT, gave some good insight and christian said he woudl include it on the next release. I dont have a free 328p to test on right now, cant find them anywhere.. So, maybe try the latest release?

[spudw2k]

I have used both a 168 and 328 chip with no problems (beyond learning all this AVR stuff, I'm very in-experienced). So far I have successfully compiled and uploaded code from the wii-ext-to-usb. Might be a good starting point to get something running on a 168 or 328.

[ulao]

Thank you for this info. So you made no changes from the 168 code to work with 328 chips?

[spudw2k]

Yes, no changes to the code. I just had to specify the chip at compile time.

[Dy]

Hi,

if you are still having troubles running your mega*p devices I recommend reading following paragraph from the V-USB wiki [1]:

8.- Don't compile for 'P' series chips - There is an issue in the driver where some interrupt tables are named in a way that isn't compatible with chips that have a 'p' after their name - i.e. ATmega168p, ATmega3280. This is tricky, since the code will compile, but just won't work. However, the 'p' series chips are binary compatible with their non-'p' cousins, so if you're working with an ATmega168p, compile for a regular ATmega168. The ATmega328p has no non-p variant, but it's binary-compatible with the ATmega168, so compile for the ATmega168. You may also try defining "USB_INTR_VECTOR" as "INT0_vect" in "usbconfig.h", or replacing "SIG_INTERRUPT0" with "INT0_vect" in "usbdrvasm.S" (around line 60 in version 20090822).

(Remark: I havn't check that for myself yet, I just read it...)

hth
Dy

[1] http://vusb.wikidot.com/troubleshooting

[ulao]

Right but whats the equivalent to a 328? If you compile for the 168 wont you be out the extra space? AFAIK there is no non p for 328.

[frank26080115]

There is no equivalent for the ATmega328P

You may also try defining "USB_INTR_VECTOR" as "INT0_vect" in "usbconfig.h", or replacing "SIG_INTERRUPT0" with "INT0_vect" in "usbdrvasm.S" (around line 60 in version 20090822).

That last sentence in the wiki was added by me, it works for ATmega328P.

[ulao]

Well I got my chips today and set my burn settings for 328p, set my make to 328p and all worked just fine? No need for anything special.

[DetlevT]

From the wiki:

The ATmega328p has no non-p variant, but it's binary-compatible with the ATmega168, so compile for the ATmega168.

This is a bad idea. The 328p has twice as much RAM as the 168, so the stackpointer will point to the wrong position (RAMEND of the 168) and the usable RAM is reduced by half.

Adding

Code: Select all

#define USB_INTR_VECTOR INT0_vect

to usbconfig.h works fine and should be the way of your choice.

[beardy]

Hi chaps. My chum and I are looking to get this working - and very excited about too.

We're not having any joy yet - though I think we've tried all of the above suggestions so far.

He's on a 328 Duemilanova and I'm on a Seeduino 1.1 (SMD 168). We're using IDE 0019 and 0020.

I guess the biggest question would be... are we barking!? Can this work? I'm out of my depth now so I don't know if more hours of fiddling will ever produce a result.

A quick yes/no would be very much appreciated - and maybe a key pointer if you feel there is one.

Many thanks to all for the discussion posted here so far it's been most helpful.

[m]

[ulao]

I guess the biggest question would be... are we barking!? Can this work?

If you are referring to the original post, yes. atmega328p's work just fine.

[beardy]

Thanks Ulao, we're making progress.
[m]

[I get a problem compiling]

VUSBExample1.cpp.o: In function `main':
VUSBExample1.cpp:22: undefined reference to `usbInit()'
VUSBExample1.cpp:35: undefined reference to `usbPoll()'

Is this forum still being used?
Has this problem been solved?
Anyone know whats going on?
These Confirmation codes will drive everybody away they are a pain in the arse . I can't read the rotten things!!!!
Taken me 5 minutes to try and read this rubbish