Using this sketch to test my Bobuino analogpins:
void setup() {
// declare the ledPin as an OUTPUT:
Serial.begin(9600);
}
void loop() {
// read the value from the sensor:
for (int i=0; i < 8; i++){
int sensorValue = analogRead(i);
Serial.print("A");
Serial.print(i);
Serial.print( " = ");
Serial.println(sensorValue);
delay(500);
}
}
My results:
printed name Actual pin
A0 A0
A1 A7
A2 A6
A3 A5
A4 A4
A5 A3
A6 A2
A7 A1
That appears to work for you. Doesn't for me, Could you post the contents of your Bobuino variant pins_arduino.h file?
That is one way of testing I didn't try, using numbers 0 to 7 to refeer to the analog pin names A0 to A7 or by using their digital pin numbers 14 to 21. All forms should work the same. However when I tried your sketch I see 0 reading A7, 1 reading A6, etc, so a symmetrical flip of 0-7 to 7-0. Not the same results I see when I'm using A0 or 14.
I'm sure it's Bob's fault for not testing his analog input pins before sending his PCBs out for production. 
Lefty
Indeed. I only tested for digital functionality, never tried a pot on each analog pin.
Maniacbug flipped the analog pin mappings end for end for me, so that ADC7 (near the middle of the chip) went direct to the A0 header near the middle of the board, the way a Duemilanove/Uno has them. (whereas ADC0 is near the middle on a '328).
The line identified in pins_arduino.h
#define analogPinToChannel(p) ( (p) < NUM_ANALOG_INPUTS ? (NUM_ANALOG_INPUTS-1) - (p) : -1 )
might be the key.
#ifndef Pins_Arduino_h
#define Pins_Arduino_h
#include <avr/pgmspace.h>
// ATMEL ATMEGA1284P on Bobuino
//
// +---\/---+
// (D 4) PB0 1 | | 40 PA0 (D 21) AI 7
// (D 5) PB1 2 | | 39 PA1 (D 20) AI 6
// INT2 (D 6) PB2 3 | | 38 PA2 (D 19) AI 5
// PWM (D 7) PB3 4 | | 37 PA3 (D 18) AI 4
// PWM/SS (D 10) PB4 5 | | 36 PA4 (D 17) AI 3
// MOSI (D 11) PB5 6 | | 35 PA5 (D 16) AI 2
// PWM/MISO (D 12) PB6 7 | | 34 PA6 (D 15) AI 1
// PWM/SCK (D 13) PB7 8 | | 33 PA7 (D 14) AI 0
// RST 9 | | 32 AREF
// VCC 10 | | 31 GND
// GND 11 | | 30 AVCC
// XTAL2 12 | | 29 PC7 (D 29)
// XTAL1 13 | | 28 PC6 (D 28)
// RX0 (D 0) PD0 14 | | 27 PC5 (D 27) TDI
// TX0 (D 1) PD1 15 | | 26 PC4 (D 26) TDO
// INT0 RX1 (D 2) PD2 16 | | 25 PC3 (D 25) TMS
// INT1 TX1 (D 3) PD3 17 | | 24 PC2 (D 24) TCK
// PWM (D 30) PD4 18 | | 23 PC1 (D 23) SDA
// PWM (D 8) PD5 19 | | 22 PC0 (D 22) SCL
// PWM (D 9) PD6 20 | | 21 PD7 (D 31) PWM
// +--------+
//
#define NUM_DIGITAL_PINS 32
#define NUM_ANALOG_INPUTS 8
#define analogInputToDigitalPin(p) ((p < NUM_ANALOG_INPUTS) ? 21 - (p) : -1)
extern const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS];
extern const uint16_t __pcmsk[];
extern const uint8_t digital_pin_to_timer_PGM[NUM_DIGITAL_PINS];
#define ifpin(p,what,ifnot) (((p) >= 0 && (p) < NUM_DIGITAL_PINS) ? (what) : (ifnot))
#define digitalPinHasPWM(p) ifpin(p,pgm_read_byte(digital_pin_to_timer_PGM + (p)) != NOT_ON_TIMER,1==0)
#define digitalPinToAnalogPin(p) ( (p) >= 14 && (p) <= 21 ? (p) - 14 : -1 )
#define analogPinToChannel(p) ( (p) < NUM_ANALOG_INPUTS ? NUM_ANALOG_INPUTS - (p) : -1 )
static const uint8_t SS = 10;
static const uint8_t MOSI = 11;
static const uint8_t MISO = 12;
static const uint8_t SCK = 13;
static const uint8_t SDA = 23;
static const uint8_t SCL = 22;
static const uint8_t LED = 13;
static const uint8_t A0 = 14;
static const uint8_t A1 = 15;
static const uint8_t A2 = 16;
static const uint8_t A3 = 17;
static const uint8_t A4 = 18;
static const uint8_t A5 = 19;
static const uint8_t A6 = 20;
static const uint8_t A7 = 21;
#define digitalPinToPCICR(p) ifpin(p,&PCICR,(uint8_t *)0)
#define digitalPinToPCICRbit(p) ifpin(p,digital_pin_to_pcint[p] >> 3,(uint8_t *)0)
#define digitalPinToPCMSK(p) ifpin(p,__pcmsk[digital_pin_to_pcint[]],(uint8_t *)0)
#define digitalPinToPCMSKbit(p) ifpin(p,digital_pin_to_pcint[p] & 0x7,(uint8_t *)0)
#ifdef ARDUINO_MAIN
#define PA 1
#define PB 2
#define PC 3
#define PD 4
const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =
{
24, // D0 PD0
25, // D1 PD1
26, // D2 PD2
27, // D3 PD3
8, // D4 PB0
9, // D5 PB1
10, // D6 PB2
11, // D7 PB3
29, // D8 PD5
30, // D9 PD6
12, // D10 PB4
13, // D11 PB5
14, // D12 PB6
15, // D13 PB7
7, // D14 PA7
6, // D15 PA6
5, // D16 PA5
4, // D17 PA4
3, // D18 PA3
2, // D19 PA2
1, // D20 PA1
0, // D21 PA0
16, // D22 PC0
17, // D23 PC1
18, // D24 PC2
19, // D25 PC3
20, // D26 PC4
21, // D27 PC5
22, // D28 PC6
23, // D29 PC7
28, // D30 PD4
31, // D31 PD7
};
const uint16_t __pcmsk[] =
{
(uint16_t)&PCMSK0,
(uint16_t)&PCMSK1,
(uint16_t)&PCMSK2,
(uint16_t)&PCMSK3
};
// these arrays map port names (e.g. port B) to the
// appropriate addresses for various functions (e.g. reading
// and writing)
const uint16_t PROGMEM port_to_mode_PGM[] =
{
NOT_A_PORT,
(uint16_t) &DDRA,
(uint16_t) &DDRB,
(uint16_t) &DDRC,
(uint16_t) &DDRD,
};
const uint16_t PROGMEM port_to_output_PGM[] =
{
NOT_A_PORT,
(uint16_t) &PORTA,
(uint16_t) &PORTB,
(uint16_t) &PORTC,
(uint16_t) &PORTD,
};
const uint16_t PROGMEM port_to_input_PGM[] =
{
NOT_A_PORT,
(uint16_t) &PINA,
(uint16_t) &PINB,
(uint16_t) &PINC,
(uint16_t) &PIND,
};
const uint8_t PROGMEM digital_pin_to_port_PGM[NUM_DIGITAL_PINS] =
{
PD, // D0
PD, // D1
PD, // D2
PD, // D3
PB, // D4
PB, // D5
PB, // D6
PB, // D7
PD, // D8
PD, // D9
PB, // D10
PB, // D11
PB, // D12
PB, // D13
PA, // D14
PA, // D15
PA, // D16
PA, // D17
PA, // D18
PA, // D19
PA, // D20
PA, // D21
PC, // D22
PC, // D23
PC, // D24
PC, // D25
PC, // D26
PC, // D27
PC, // D28
PC, // D29
PD, // D30
PD, // D31
};
const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[NUM_DIGITAL_PINS] =
{
_BV(0), // D0 PD0
_BV(1), // D1 PD1
_BV(2), // D2 PD2
_BV(3), // D3 PD3
_BV(0), // D4 PB0
_BV(1), // D5 PB1
_BV(2), // D6 PB2
_BV(3), // D7 PB3
_BV(5), // D8 PD5
_BV(6), // D9 PD6
_BV(4), // D10 PB4
_BV(5), // D11 PB5
_BV(6), // D12 PB6
_BV(7), // D13 PB7
_BV(7), // D14 PA7
_BV(6), // D15 PA6
_BV(5), // D16 PA5
_BV(4), // D17 PA4
_BV(3), // D18 PA3
_BV(2), // D19 PA2
_BV(1), // D20 PA1
_BV(0), // D21 PA0
_BV(0), // D22 PC0
_BV(1), // D23 PC1
_BV(2), // D24 PC2
_BV(3), // D25 PC3
_BV(4), // D26 PC4
_BV(5), // D27 PC5
_BV(6), // D28 PC6
_BV(7), // D29 PC7
_BV(4), // D30 PD4
_BV(7), // D31 PD7
};
const uint8_t PROGMEM digital_pin_to_timer_PGM[NUM_DIGITAL_PINS] =
{
NOT_ON_TIMER, // D0 PD0
NOT_ON_TIMER, // D1 PD1
NOT_ON_TIMER, // D2 PD2
NOT_ON_TIMER, // D3 PD3
NOT_ON_TIMER, // D4 PB0
NOT_ON_TIMER, // D5 PB1
NOT_ON_TIMER, // D6 PB2
TIMER0A, // D7 PB3
TIMER1A, // D8 PD5
TIMER2B, // D9 PD6
TIMER0B, // D10 PB4
NOT_ON_TIMER, // D11 PB5
TIMER3A, // D12 PB6
TIMER3B, // D13 PB7
NOT_ON_TIMER, // D14 PA0
NOT_ON_TIMER, // D15 PA1
NOT_ON_TIMER, // D16 PA2
NOT_ON_TIMER, // D17 PA3
NOT_ON_TIMER, // D18 PA4
NOT_ON_TIMER, // D19 PA5
NOT_ON_TIMER, // D20 PA6
NOT_ON_TIMER, // D21 PA7
NOT_ON_TIMER, // D22 PC0
NOT_ON_TIMER, // D23 PC1
NOT_ON_TIMER, // D24 PC2
NOT_ON_TIMER, // D25 PC3
NOT_ON_TIMER, // D26 PC4
NOT_ON_TIMER, // D27 PC5
NOT_ON_TIMER, // D28 PC6
NOT_ON_TIMER, // D29 PC7
TIMER1B, // D30 PD4
TIMER2A, // D31 PD7
};
#endif // ARDUINO_MAIN
#endif // Pins_Arduino_h
// vim:ai:cin:sts=2 sw=2 ft=cpp
Thanks I see no difference in the contents, must be something else going on.
Lefty
So in summation of problems addressing analog input pins of bobuino varieant board, there seems to be two
different symptoms:
If using analogRead() addressing names of 0 to 7 see a symmetrical reversal to 7 to 0.
If using analogRead() addressing names of A0 to A7 or 14 to 21 get:
sketch software pin name used valid voltage reading shows up on shield pin
A0 (or14) A1 (15)
A1 (or15) A0 (14)
A2 (or16) A7 (21)
A3 (or17) A6 (20)
A4 (or18) A5 (19)
A5 (or19) A4 (18)
A6 (or20) A3 (17)
A7 (or21) A2 (16)
Strange stuff, no?
Lefty
At least we're making some progress, as it's not just a dream I had.
Mine work in perfect order for "both" 0..7 and A0.., although I'm using a loop on A0...,
so I don't know what the problem is over there. ??? I'm not using Bob's board, just connecting
directly to the pins.
Here is my current test. I compiled the code with the Bobuino arduino_pins.h file
patched as I indicated above. All ADC Channels are floating here, and I am moving a
gnd wire from pin to pin after each set of readings, starting at 33 [AD0]. You
see the zero reading follows along exactly correctly.
My entire sketch is included below.
A0..A7: 0 301 275 290 320 352 360 602
0...7: 0 152 226 272 313 362 365 479
A0..A7: 419 0 138 232 308 384 400 425
0...7: 403 0 103 181 229 261 272 275
A0..A7: 420 428 0 123 243 309 323 304
0...7: 305 319 0 97 166 191 210 254
A0..A7: 306 319 295 0 111 211 266 308
0...7: 339 351 338 0 136 243 307 385
A0..A7: 398 392 360 345 0 166 262 379
0...7: 396 398 382 375 0 149 240 338
A0..A7: 360 370 351 343 346 0 169 271
0...7: 317 338 336 332 335 0 121 204
A0..A7: 370 381 361 348 357 356 0 154
0...7: 235 282 292 294 305 312 0 111
A0..A7: 146 257 306 351 393 476 443 0
0...7: 95 183 227 255 279 295 296 0
A0..A7: 125 223 252 269 293 311 312 0
0...7: 104 196 235 260 286 313 321 0
/**********************************************************
file: analog_test1284
revised: 01/22/13, orig 01/21/13.
Tests Bobuino-1284 ADC channels.
***********************************************************/
/*****************************************/
void setup()
{
Serial.begin(57600);
Serial.println("\n1284 Analog Test ...");
a_print("defines: A0=",A0);
a_print(", A7=",A7);
}
/******************************************/
void a_print( char *s, int num )
{
Serial.print(s); Serial.print(num);
}
/*****************************************************/
void loop()
{
test_adc();
}
#define INTV 5000 // ADC repeat interval.
/**************************************************/
void test_adc()
{
static unsigned long prev=0; // last time LED was updated
unsigned long current=millis();
static int cnt=0;
int i, val=0;
if( (current - prev) > INTV) {
prev = current; // schedule next tick.
nl();
Serial.print("A0..A7: ");
for( i=0; i<8; i++) {
val = analogRead(A0+i);
// val = analogRead(A0+i);
a_print(" ",val);
delay(100);
}
nl();
Serial.print(" 0...7: ");
for( i=0; i<8; i++) {
val = analogRead(i);
// val = analogRead(i);
a_print(" ",val);
delay(100);
}
}
}
void nl() { Serial.println(""); }
Was wiring_analog.c updated from 1.0 to 1.01, .02, .03?
Wondering when the 1284 support came in.
AAMOF, I had already looked at that, but must have been in 1.0 only. However, my sketch
from last time gives me exactly the same results with both IDE 1.0 and 1.03. Likewise
for ERW 1.03. Go figure.
Have you tried running my sketch from last time? Maybe something is weird there.
IDE 1.0
int analogRead(uint8_t pin)
{
uint8_t low, high;#if defined(AVR_ATmega1280) || defined(AVR_ATmega2560)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(AVR_ATmega32U4)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
IDE 1.02
int analogRead(uint8_t pin)
{
uint8_t low, high;#if defined(AVR_ATmega1280) || defined(AVR_ATmega2560)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(AVR_ATmega32U4)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(AVR_ATmega1284P) || defined(AVR_ATmega644P)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
IDE 1.03
int analogRead(uint8_t pin)
{
uint8_t low, high;#if defined(AVR_ATmega1280) || defined(AVR_ATmega2560)
if (pin >= 54) pin -= 54; // allow for channel or pin numbers
#elif defined(AVR_ATmega32U4)
if (pin >= 18) pin -= 18; // allow for channel or pin numbers
#elif defined(AVR_ATmega1284P) || defined(AVR_ATmega644P)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
#else
if (pin >= 14) pin -= 14; // allow for channel or pin numbers
#endif
Have you tried running my sketch from last time? Maybe something is weird there.
Well I seem to be straighten out finally. What I was fighting I guess is a older or different version of maniacbug's hardware files setup for the sanguino/644P chip which I had downloaded and modified to use the bobuino pins_arduino.h, added a optiboot bootloader file for the 644P, etc.
However there seems to be too many differences between some of the hardware core files between the two different maniacbug's hardware folder I had downloaded and installed. So I dumped all the sanguino hardware folders and just added a new bobuino 644P/optiboot board to the maniacbug-mighty-1284p hardware folders. Then I added your suggested fix to the pins_arduino.h and then recompiled/uploaded the various analog test sketches and all is well in bobuino 644P land for me now, yea.
Thanks for your help, I had never actually tested out my analog pins for this bubuino/644P setup (just like Bob I guess 
) so it's good to have that checked off. Still waiting for my 1284P chip to show up, I hope it has at least crossed the international date line by now.
Lefty
Yeah, still doesn't explain, that I can see, the funny business about
#elif defined(AVR_ATmega1284P) || defined(AVR_ATmega644P)
if (pin >= 24) pin -= 24; // allow for channel or pin numbers
I don't know about Sanguino or 644, as they're not included with the maniacbug mighty-1284P-master
files. The files and bootloaders I have are all dated 23 June 2012.
Besides the digital and analog pins, I also checked the PWM pins today with analogWrite(), and
they all look ok, so I think only the analogPinToChannel(p) declaration was wrong.
I just bought some 1284P chips from digikey today, and should arrive on thursday. Yours
are no doubt cheaper, but I want to get this darn thing wrapped up already. Sheesh. Thursday,
I can check the RX0 sensitivity/download problem using the 1284P chips.
On a brighter note, today, my local Coopers hawks returned to their nest in the nearby tree
from their winter sojourn. One can only imagine where they've been all winter since they
left in the fall after their kids had grown. Probably in San Diego, sitting on the beach.
On a brighter note, today, my local Coopers hawks returned to their nest in the nearby tree
from their winter sojourn. One can only imagine where they've been all winter since they
left in the fall after their kids had grown. Probably in San Diego, sitting on the beach.
Well for us that means the hawk population will probably start to dwindle to 1/4 of what we see in the winter as they leave for the north. We have local hawks (mostly red-tails) that are year around.
If your ever interested in populating any of your boards with a 644P chip, here is the boards.txt entry I setup.
##############################################################
bobuino644.name=Bobuino 644P optiboot
bobuino644.upload.protocol=arduino
bobuino644.upload.maximum_size=63488
bobuino644.upload.speed=115200
bobuino644.bootloader.low_fuses=0xff
bobuino644.bootloader.high_fuses=0xdc
bobuino644.bootloader.extended_fuses=0xfd
bobuino644.bootloader.path=optiboot
bobuino644.bootloader.file=optiboot_atmega644p-4-5.hex
bobuino644.bootloader.unlock_bits=0x3F
bobuino644.bootloader.lock_bits=0x0F
bobuino644.build.mcu=atmega644p
bobuino644.build.f_cpu=16000000L
#bobuino644.build.core=arduino:arduino
bobuino644.build.core=standard
bobuino644.build.variant=bobuino
##############################################################
Still waiting for my 1284P chip to show up, I hope it has at least crossed the international date line by now.
Is Mouser shipping these from overseas now?
With >1700 in stock you'd think they'd arrive pretty quick.
http://www.mouser.com/ProductDetail/Atmel/ATMEGA1284P-PU/?qs=sGAEpiMZZMtVoztFdqDXO3QpeG9FlGm9
CrossRoads:
Still waiting for my 1284P chip to show up, I hope it has at least crossed the international date line by now.
Is Mouser shipping these from overseas now?
With >1700 in stock you'd think they'd arrive pretty quick.
http://www.mouser.com/ProductDetail/Atmel/ATMEGA1284P-PU/?qs=sGAEpiMZZMtVoztFdqDXO3QpeG9FlGm9
Call me a cheapskate but when I click on buy I get this total:
MERCHANDISE TOTAL:
$8.71
SHIPPING CHARGE:
$20.00
ORDER TOTAL:
$28.71
That sounds nuts to me?
So I ordered from Futurlec for like $10 including shipping. I was aware that they take a long time shipping as I've ordered a couple of things from them before in the past, and being retired I'm almost never in a hurry. And because of being able to use a DIP 644P in your same Demu through hole 1284P board you sold me, it's not been non-constructive time spent waiting.
Besides you now have the option of calling your board a 644P/1284P board.
Lefty
I always use USPS Priority Mail shipping from digikey and mouser and jameco, and with the order
I placed yesterday with digikey, the shipping is $4.91. Priority usually takes 2 days to the west
coast. Mouser is a little cheaper than digikey for small quantities, but only digikey had some other
parts I needed for this order.
I also ordered a few atmega32A chips to play with. From what I can tell, these have the same
pinout as 644/1284, but are essentially a 328 in DIP40, so you get a -UNO with 40-pins. Also
2/3 cheaper than the 644/1284. I don't know if there is a bootloader for the 32A, however.
I should have ordered some 644s too, just to play, but forgot.
oric_dan:
I always use USPS Priority Mail shipping from digikey and mouser and jameco, and with the order
I placed yesterday with digikey, the shipping is $4.91. Priority usually takes 2 days to the west
coast. Mouser is a little cheaper than digikey for small quantities, but only digikey had some other
parts I needed for this order.I also ordered a few atmega32A chips to play with. From what I can tell, these have the same
pinout as 644/1284, but are essentially a 328 in DIP40, so you get a -UNO with 40-pins. Also
2/3 cheaper than the 644/1284. I don't know if there is a bootloader for the 32A, however.
So what was the
SHIPPING CHARGE:
$20.00
That Mouser showed me when I clicked on buy it? Is the default hand delivery by limousine? Or some kind of minimum order size hidden as a shipping charge?
Lefty
Those guys have a dozen or more shipping options, with Fedex overnight at the top of the
cost structure, and Fedex or UPS ground near the bottom [and which may take a week].
A guy like you [!!!] should avoid clicking on the upper lines.
$4.99 residential shipping is what I normally see with Mouser. $6.99 for bulkier stuff.
oric_dan:
Those guys have a dozen or more shipping options, with Fedex overnight at the top of the
cost structure, and Fedex or UPS ground near the bottom [and which may take a week].
A guy like you [!!!] should avoid clicking on the upper lines.
But I didn't, I just clicked buy it and that is what popped up. I didn't even go to further screens to see if I had a choice of shipping options. So they in effect 'scared me away' by their choice to default to a or the most costly shipping method. If that had not stated any shipping cost then I might have adventured further into the buying process/screens, to see that options they made available. Just poor web design in my opinion.
Lefty
Looks pretty darn easy to me. I looked at my Mouser cart from yesterday [order not
completed], but once I click on "Checkout" from the cart, it takes me to a succession
of screens [notice the top line], then 3rd screen is here,
CHECKOUT» Addresses» Shipping Method» Payment» Review
Shipping Method
Please select one of the following:Shipping cost determined at the time of shipment.
UPS Ground
UPS 3rd Day
UPS 2nd Day
UPS Next Day Saver
UPS Next Day
UPS Next Day Early AM
FedEx Ground
FedEx 3rd Day
FedEx 2nd Day
FedEx Standard Overnight
FedEx Priority Overnight
FedEx Priority Overnight Early AM
US Postal Service Priority Mail w/Delivery Confirmation
Live wild.