millis, micros ... will not work correctly at 11.0592 MHz ... What happens if the F_CPU is set to that frequency?
The rule for the clock frequency because of the way the code is written... http://arduino.cc/forum/index.php/topic,59263.msg427808.html#msg427808
An example of what happens when the rule is not followed... http://arduino.cc/forum/index.php/topic,59263.msg426611.html#msg426611
Okay so you're saying the crystal freq has to be a power of 2? But there are other boards that do not follow this rule. These boards claim Arduino compatibility and work with Arduino cores from avr-developers.com. Here is a list:
arduino_amber128.name=Arduino-Amber 128 14.7456 Mhz arduino_amber128.build.f_cpu=14745600L
arduino_OrangutanSVP1284.name=Arduino-Orangutan SVP-1284 arduino_OrangutanSVP1284.build.f_cpu=20000000L
arduino_gator.name=Arduino-Rugged Circuits Gator Board arduino_gator.build.f_cpu=20000000L
arduino_bahbots1284p.name=Arduino-BahBots 1284p arduino_bahbots1284p.build.f_cpu=18432000L
These boards claim Arduino compatibility and work with Arduino cores from avr-developers.com
How do you know that millis (et al) works correctly on those boards with that core?
I certainly could have made a mistake analyzing the code but by my calculations the 20 MHz boards are off by 0.39%; the 14745600 Hz board is off by 6.84% 0.64%; and the 18432000 Hz board is off by 0.10%.
Edit: Corrected the percent error for one of the boards.
Can I get an eyeball on Reply #25 and confirm I have the socket installed the right way? Not sure what the lines at the left side do, they interfere with routing tho.
[quote author=Coding Badly link=topic=61126.msg442725#msg442725 date=1305502879]
These boards claim Arduino compatibility and work with Arduino cores from avr-developers.com
How do you know that millis (et al) works correctly on those boards with that core?
I certainly could have made a mistake analyzing the code but by my calculations the 20 MHz boards are off by 0.39%; the 14745600 Hz board is off by 6.84%; and the 18432000 Hz board is off by 0.10%.
[/quote]
I don't know that millis works right for sure, that's true although I think a fair claim of "Arduino compatibility" would require them to be pretty close. However, I would be amazed if the baud rates were substantuially off, and that would also be impacted by changing rhe crystal frequency.
I have a 1284P prototype board here with a socketed crystal. I think I'll get a few different crystals and see what happens.
RE the SD sockets.
The schematic looks good according to my limited SD knowledge. However the pins on the two sockets are reasonably aligned, yet the rats nest on the PCB shows them all crossed over.
Not sure what the lines at the left side do,
What lines?
RSV => reserved I think.
PS I responded to your PM with a couple of other comments.
Rob
I’m thinking this is the correct orientation for the microSD - the vertical lines to the right are part of the microsd symbol. No idea what they do besides get in the way.
Rob,
I had an e-mail typed up & it got dumped while I was looking up a 4 pin header to stick on the 4-pin RS232 header. I think I will recommend folks use 4-pin crimp connector housing that pololu.com carries, 3 wires plug in, the other ends connect to uses RS232 connector of choice. Just occurred to me - what if I made that 3 pins with ground in the middle? Then the housing could be plugged on either way, worst case Tx goes against TX and nothing gets received on either end.
I’ve had no luck finding a 2x2 crimp on type for a ribbon cable.
Reset_enable - 3 pin header was used as I couldn’t find a 2 pin header that was just pins.
Values - I left off the R & C values, are just 1K/10K resistors, 100nf/0.1uF for the small caps, 100uF for the 3 big one, nothing unusual.
COMM1 jumper - my intent there was to have jumpers across 1-2 and 3-4 to have RS232 going off board, and to have No jumpers installed if one needed D2/D3 not interfered with on the shield header.
I’m up for changing it to something that will provide more functionality, I don’t understand what you are referring to by Serial Polarity tho.
what you are referring to by Serial Polarity tho.
If you want to connect two devices (especially two that are the same such as two of these boards) you have to swap Rx and Tx. In the past I've found the easiest way to do this is with a 2x2 header and two jumpers. The jumper are say horizontal for one polarity and vertical for the other, so there's no wiring of special plugs/cables. The alternative is to have crossover cables. With Pololu-style discrete connectors that's easy enough, but with ribbon cable you can't (easily) make a crossover cable.
However if you're not using ribbon cable this is all pretty moot. It's easy enough to wire up a crimp connector in any format.
It's largely an aesthetic thing for me, if you use separate wires they look ugly and you have to have a huge DB9 shell with just 3 small wires poking out the back. Ribbon cable looks neat.
I've had no luck finding a 2x2 crimp on type for a ribbon cable.
You won't AFIAK 2x3 is the smallest.
I couldn't find a 2 pin header that was just pins.
Do you mean in the Eagle library?
COMM1 jumper
OK, I get it.
The SD sockets now line up as I would have expected. How far out does the card sit physically. I'm guessing that's what those lines are but there's 3 of them.
What I'm getting at is accessibility when the board is in an enclosure, any memory card has to poke off board enough to be usable from outside the box. The right most line looks good, the other two would not work. Are there 3 sizes in micro SD, I didn't think so. Not that there's much you can do about it, the socket is already right on the edge.
Rob
Hi Rob,
Reset_Enable: yes in the eagle library. I’m sure there is one, I just gave up on looking. I’m up for changing it if you know where to find one. The ones I found had big outlines around them for plastic shrouds or something.
RS232 - I have it set up now as 3 pins, middle is ground. If one wants to go board to board, make a flat 3-pin cable and it will go one way or the other.
I'm actually thinking about keeping the same Arduino footprint and changing the processor to the ATmega1284. I seems like it would jsut fit in there (DIP version). The extra pins would be added to the end of the board. A bit like the Seeeduino Mega. Haven't routed it yet, though.
@bubulindo, I did just that, adding SD card driver and RS232 driver as most folks seem to need a 2nd serial for their GPS, etc. Standard shield header with all the regular signals, and a couple of jumper fields for flexibility. Waffling on the autopower vs power selection headers still, debating whether to make space for a reset switch.
Quit making me drool all over my d*mn keyboard :-/
You guys make it sound like I need to get the prototypes ordered yesterday!
CrossRoads: You guys make it sound like I need to get the prototypes ordered yesterday!
No, but you have seemed to have created an itch in a lot of us. I'm still not convinced that all the software hurdles have been leaped over yet, clock @ standard 16Mhz, bootloader compiled to run at 16Mhz, etc. Pin mapping should be the same as 644p however.
I'm glad you are still considering the manual Vs auto-voltage switching function. Can live with either but still think the board space could be used for more useful purposes.
Lefty
I would suggest to get rid of rs232 chip and put there an rtc chip with a backup battery instead. The usage of a Sdcard (for e.g. logging purposes) require a valid timestamp mostly. This is my experience as I run 1284puino for a year now (rtc pcf8563 and cr1220 hardwired on the board). Rs232 - most gps modules are 5v or 3v3 ttl, so no need for a rs232 hw driver, just bare 3 pins, I think. I would put 10k pullup on each Rx pin as well. Reset button - I would rather go with it.. Also - I would go with 3V3 Vcc, no need for SDcard buffer and 3v3 reg then. I would go with microsd socket only.. Add maybe a header for an external accu (with a charging circutry or a trickle charge..). Also mind the situation you have a SDcard plugged in and you do ICSP programming.. The crystal value - you may use any provided you will not use micros and do recompile the bootloader. The delay() used in 0022 is based on micros(??) so I am using my own based on millis (as it was in past). P. PS: :P two new gadgets in the town: http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,895&Prod=CHIPKIT-MAX32 http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,719,896&Prod=CHIPKIT-UNO32
No!! Leave my RS-232 alone! :-)
OTOH, if you find room to add an RTC, that'd be fine & dandy :-)
retrolefty: I'm glad you are still considering the manual Vs auto-voltage switching function. Can live with either but still think the board space could be used for more useful purposes.
Would moving the auto-voltage switch to a daughter / companion board be a good idea? That would free some space and reduce the component count for people who intend to run the board from a 5 volt source.
Would moving the auto-voltage switch to a daughter / companion board be a good idea? That would free some space and reduce the component count for people who intend to run the board from a 5 volt source.
Not as useful as just s@#t canning the whole concept of auto-voltage selection. It’s such a lame function that uses way too many components and space for what it brings to the table. Real people should use real switches or jumper clips for things like voltage source or voltage level selection, auto-reset enable/disable, and any other useful user hardware selection feature required or desired. Auto-voltage selection was an idea that might have had the best of intentions for beginners, but if just limits flexibility and has some questionable design points.
OK, I’m done with my arduino rant for the time being. 
Lefty
The automatic selection of powering from USB or another source is very useful for many applications. If the device is going to live somewhere away from a PC ou need to power it, but for the occasional trip to the PC to be updated or whatever it comes in very handy not to have to go searching for the wall art.
retrolefty:
No, but you have seemed to have created an itch in a lot of us. I’m still not convinced that all the software hurdles have been leaped over yet, clock @ standard 16Mhz, bootloader compiled to run at 16Mhz, etc. Pin mapping should be the same as 644p however.
I have a bootloader running at 16 MHz and the cores available at avr-developer.com work nicely.