Show Posts
Pages: [1] 2
1  Using Arduino / Installation & Troubleshooting / Re: [SOLVED] Leonardo-based board - BAD_POOL_CALLER 0x000000C2 upon driver load on: November 20, 2013, 02:08:11 am
I tried, but it doesn't let me, BlindWolf8.  Or, to be more precise, it tells me it's not going to work, but asks if I'd like to change it anyway (see attached).

I've attached a photo of the tasteful, white on blue, on screen crash report, instead.

I assume KMODE_EXCEPTION_NOT_HANDLED 0x0000001E in USBD.SYS is a symptom of a driver trying to use a feature that the Windows 2000 USB stack doesn't actually have.
2  Using Arduino / Installation & Troubleshooting / Re: [SOLVED] Leonardo-based board - BAD_POOL_CALLER 0x000000C2 upon driver load on: November 19, 2013, 04:13:36 am
I agree that's where it should be, BlindWolf8, but it isn't.  It seems to be an informally documented "feature" of Windows 2000 - if your swap file isn't on the system partition, or possibly just isn't on C, you don't get a minidump.  I could change things so it is, if it's important, but I'd have to move some stuff to make room first.
3  Using Arduino / Installation & Troubleshooting / Re: [SOLVED] Leonardo-based board - BAD_POOL_CALLER 0x000000C2 upon driver load on: November 18, 2013, 11:01:06 pm
Is there a similar fix for the BSOD problem when installing Leonardo drivers for Windows 2000?

Having tried to install them once, even pressing Cancel when Windows asks to install drivers (when connecting a Leonardo) causes a BSOD.  In the case of Windows 2000, it's to do with USBD.SYS.

I tried following the instructions here, but they don't quite fit into the way things work in Win2k and I couldn't get them to work.  Having the machine blue screen every time I try doesn't help.

Is there a set of drivers for the Leonardo that just plain work in Windows 2000?  The documentation implies that they do, but my guess is that no one on the development team has actually tried it.


I haven't been able to get a MiniDump file of the BSOD, because my swap file is kept on a dedicated partition, which stops Windows creating one, for some bizarre reason.  I guess I could change that temporarily, if needed.  Alternatively, I could attach a photo of the screen, but I don't know how much there is to learn from the error message, other than the module it happens in.


Maybe I should start a new thread, as this one has SOLVED in the title, and was for Win7.  The general topic is the same though - Leonardo drivers are unstable, in some versions of Windows.  Or to be more accurate, they very reliably don't work at all, causing an instant BSOD when you try to install them.
4  Using Arduino / Microcontrollers / Re: Help in programming the Atmega1284 with maniacbug-mighty-1284p. on: May 15, 2013, 02:57:00 am
It's not totally trivial to locate where the following page is found, but it indicates where
you are supposed to have the libraries located, namely in your sketch directory, and not
in your IDE directory.
http://arduino.cc/en/Guide/Libraries

Thanks, oric_dan.  I'd been putting them in the program files folder, which works, and means I have a separate copy for each installation of the Arduino environment (I currently have 1.01, 1.04 and 1.52 installed, separately, just to make sure smiley). 

I suppose I ought to do it the official way though, and I didn't realise that's how it was supposed to be done.  It would make the next upgrade just a touch easier, but then I might break something that worked in an older version of Arduino, and not be able to fall back to using that.
5  Using Arduino / Microcontrollers / Re: Help in programming the Atmega1284 with maniacbug-mighty-1284p. on: May 15, 2013, 02:53:40 am
Thanks, pito

# Manually added the boards.txt content for Maniacbug Mighty 1284P to the main boards.txt
#
# Also moved the cores from it into
# C:\Program Files\arduino-1.5.2\hardware\arduino\avr\cores\mighty1284P_standard
# and the variants form it into
# C:\Program Files\arduino-1.5.2\hardware\arduino\avr\variants\mighty1284P_avr_developers
# C:\Program Files\arduino-1.5.2\hardware\arduino\avr\variants\mighty1284P_bobuino
# C:\Program Files\arduino-1.5.2\hardware\arduino\avr\variants\mighty1284P_standard

I can't help wondering if there's a cleaner way of doing it, so it's easier to keep upgrading the Arduino environment, but that seems fine for now - the different types of 1284P board are now on my Board menu.
6  Using Arduino / Microcontrollers / Re: Help in programming the Atmega1284 with maniacbug-mighty-1284p. on: May 14, 2013, 07:09:38 pm
Mighty 1284p works fine with 1.5.2.

Not for me, it doesn't.  The boards don't appear in the Board menu.  I don't know where to go from there.

What is your picture supposed to illustrate?

EDIT:  I see now - in the bottom right hand corner.  But how did you select the board?  Are you using the Windows distribution or a Linux one?
7  Using Arduino / Microcontrollers / Re: Help in programming the Atmega1284 with maniacbug-mighty-1284p. on: May 14, 2013, 05:57:15 am
I'm trying Arduino 1.5.2 and the maniacbug 1284P boards don't appear in the Board menu any more.  The ATtiny AVR ones didn't either, but there was a new release that fixed that - and uses the new options for selecting the CPU and speed variants separately, making the Board menu shorter.

Is there a fix for maniacbug Mighty 1284P to work with Arduino 1.5.2, or would I just have to stick with 1.0.4?  That still shows them, but suffers from the very long Board menu, that doesn't fit on my screen unless I comment out some of them.
8  Using Arduino / Displays / Re: problem with serial lcd from YwRobot, LCM1602 IIC on: June 30, 2012, 07:45:52 am
Couldn't you just rename the new library so the two can coexist?

I haven't looked into how libraries are organised yet, but I assume it's just a set of C++ classes.  If you rename any classes that are the same in the standard library, change all the references to them to match, and rename the new library, I would have thought that would do it.
9  Using Arduino / Programming Questions / Re: Parallel I/O - e.g reading or writing a whole byte, not one pin at a time on: June 21, 2012, 01:34:30 pm
Thanks, Nick and wanderson.

I wasn't familiar with that type of chip package, and I didn't realise there were extra pins on those versions.  I'd wondered why the pin numbering on the Nano and Mini schematics didn't match the Atmega168 Pin Mapping page, that the Uno page links to.  Datasheet reading is on my list of things to do, and has been for a few days now.
10  Using Arduino / Programming Questions / Re: Parallel I/O - e.g reading or writing a whole byte, not one pin at a time on: June 21, 2012, 01:55:56 am
ATmega168, yes, but I didn't know the Mutant Liberation Front made microcontrollers...
11  Using Arduino / Programming Questions / Re: Parallel I/O - e.g reading or writing a whole byte, not one pin at a time on: June 20, 2012, 09:59:35 pm
My mistake.  BitWrite() is mentioned on the main Reference page:

http://arduino.cc/en/Reference/BitWrite

There doesn't seem to be any way to search the Reference section though, and I'm sure there's more stuff in there, having found the Port Manipulation page.
12  Using Arduino / Programming Questions / Re: Parallel I/O - e.g reading or writing a whole byte, not one pin at a time on: June 20, 2012, 09:43:23 pm
Is this the datasheet you're referring to, Nick, or is there a more detailed one somewhere?

http://arduino.cc/en/Main/ArduinoBoardMini

The ReadMe PDF for the DigitalWriteFast library impliies that it uses sbi and cbi to set or clear individual bits on ports below F.  Looking at the .h file, it uses bitWrite().  I can see lots of references to that in the forum, but I can't find any official documentation for it.

The Reference section seems to contain more than it admits to though.  The index page appears to be incomplete, and I don't see a way to search it - all searches just seem to go to the forum.
13  Using Arduino / Programming Questions / Re: Parallel I/O - e.g reading or writing a whole byte, not one pin at a time on: June 20, 2012, 09:24:31 pm
Thanks, Nick.  I've ordered a couple of cheap ATmega168 boards based on the Arduino Mini, which also have A6 and A7.  Would those be addressed as 20 and 21, following on from A5=19?  I guess I'll find that out anyway.

The DigitalWriteFast library looks useful, but it still only manipulates one bit at a time, unless I'm missing something.  Also, in the PDF that comes with it it says "For Ports above F, the microprocessor must read in all the 8 pins in a Port, modify and rewrite all 8 pins." (to change a single bit) - I guess that applies to the ATmega1280 and 2560.  That would appear to involve a huge performance loss if what you wanted to do was change most or all of those bits together.  By looping for each bit in a byte, you'd be doing more than eight times the work - reading the whole port eight times over, and ignoring all but one bit each time.
14  Using Arduino / Programming Questions / Re: Continuity test on: June 20, 2012, 08:52:19 pm
Yes, that makes sense.

I'd be wary of arranging hardware so that a bug in the software could kill it though smiley
15  Using Arduino / Programming Questions / Re: Parallel I/O - e.g reading or writing a whole byte, not one pin at a time on: June 20, 2012, 08:45:16 pm
Yes, I realise there are restrictions on using certain pins, and actually an 8 bit output will more than likely be spread over two ports.  However, that output will be done over and over again, so saving a few microseconds at that stage will make a huge difference in speed, and leave the CPU more time to do other things - I intend it to be interrupt driven, eventually.

Having set which bits I want as outputs, I could just do this, for example:

Code:
// Using bits 0..5 of PORTC for the low 6 bits, and bits 6..7 of PORTB for the high two bits.  All other bits are inputs, or not used.
PORTC= data;
PORTB= data >> 6;

That has to be a lot faster than using a loop with digitalWrite() for each pin... I'm not even sure how to loop through the analog pins as outputs, though it's allowable to use them for that.  They seem to have to be referred to by name.

I'm not really concerned about portability, though using a library that does it better than using digitalWrite() for each pin separately, would be acceptable too.
Pages: [1] 2