Show Posts
Pages: [1] 2 3 ... 60
1  Using Arduino / Storage / Re: Do you want Long File Names in SdFat? on: October 04, 2014, 10:37:35 am
I plan to add Long File Names in the same way it is implemented in other popular FAT libraries for embedded systems.  No extra flash will be used unless Long File Names are enabled and extra RAM will be allocated as temp storage on the stack so no extra RAM will be required unless you call Long File Name member functions.

This sounds like the right way to go.

SdFat is used in very sophisticated apps on Teensy 3.1 and Due.  These boards have lots of memory and developers want more features.

I've actually got a Teensy 3 project that would benefit from lfn support, to be able tp read .mp3 files from a sd card and display the long name on a tft display along with other info.

So l for one would appreciate lfn support in SdFat. :-)
2  Development / Other Hardware Development / Re: 1284p/nRF24L01+/proto dev board - Skinny Bob! :-) on: August 05, 2014, 11:39:23 am
Only suggestion I might make is to power the 3.3 vdc regulator from the output of the 5 vdc regulator rather then feeding the 3.3vdc regulator from the Vin source voltage. That way if one was to power the board via an external regulated 5 vdc the 3.3vdc would be available?

It's actually got an auto-power switching circuit using a Schottky that will power the 3v3 VR from the 5V rail, unless there is a higher voltage on the Vin input, in which case it will draw power from that.

So, just like a standard Arduino board you can power it from the USB 5V (which is tied to the 5V rail), or the Vin, without having to set a connector to select the power source. The switching is just done all a bit more straightforwardly than the fairly Byzantine op-amp/FET set-up on an Arduino Uno, for example.  smiley-mr-green

And this way, with an adequate supply on Vin, you get two full 800mA rails, at 5V and 3v3, (as opposed to 800mA combined total for both rails.)

Also, if you chose to supply a regulated 5V on Vin, the Vin and 5V rail can be directly tied together by a jumper on the power jumper block. In that case you could actually dispense with the 5V regulator entirely if you wished. And the capacity of the 5V rail would then only be limited to whatever your external supply can provide. Quite a neat solution for higher power applications, as long as you have a reasonable quality regulated external 5V power supply.

So short answer is yes, applying 5 vdc to the 5V rail directly will also result in power to the 3v3 rail with the current design.
3  Development / Other Hardware Development / Re: 1284p/nRF24L01+/proto dev board - Skinny Bob! :-) on: August 05, 2014, 10:17:01 am
Hi pico,

That .jpg of the schematic is a bit hard to read.  Any chance of posting a hi-res .pdf?

4  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: July 07, 2014, 08:41:04 pm
1.5x IDE also has some nice features that are not in 1.x
The biggest being that dropdown are now scrollable.
This is critical if you have lots of boards or libraries installed.
Without this capability you may not be able to select the desired board or be able
to pick an example sketch because the entry is below what is on the screen and there
is no way to scroll down to it.
Having this scrolling capability is a MUST HAVE for me as I have close to 100 libraries
and nearly the same number of board selections.
There is a work around in 1.x that I'm using for that, and that is if you install Pauls
teensyduino he modifies the IDE to add in the scrolling menus.
So you can get the scrolling menus on 1.x by simply installing Pauls Teensyduino add on.

There's also the eried enhanced 1.0.5 IDE that supports scrolling menus (I believe this is the code that Paul based some of his Teensyduino enhancements upon.)

Personally, I'd never recommend someone use 1.5.x just for something like scrolling menus. 1.5.x is, after all, still a beta platform, with an unstable code base and feature set. If you want to program a Due, then I guess you don't have much choice. But for anything else, unless you are particularly yearning for adventure, well -- fuggetaboutit!

If someone asks "how do you program a 1284p using Arduino?", the current correct answer is "we have a 1.0.5 compatible core and set of libs".

Well, at least that's the answer *I* give!

But for the adventurous, I'd suggest a new thread would be appropriate for discussion of any 1.5.x related work on the 1284p core.

5  Community / Bar Sport / Re: Students caught out.... on: July 03, 2014, 06:51:51 am
Interesting article I saw recently in the NY Times:

6  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 25, 2014, 09:54:41 pm
I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.

What I saw wasn't any sort of recasting but rather some use of macros that use concatenation
to derive other macro names similar to what is done in the Teensy core.
Changing the pin & bit macros and naming, obviously breaks any code that uses them since I'm proposing eliminating
the old/existing 1284 variant BIT* and PIN* macros for Teensy style "CORE" macros.
The DPM() macro used in those libraries when using the mighty 1284 would break.
However, the DPM macro could easily be changed to use the CORE macros instead since the
functionality is the same.

As long as the DPM macro can be rewritten to use the CORE macros, there no issue then.

By changing the macro the actual tables in utility/Sd2PinMap.h and utility/DigitalPin.h wouldn't change,
but the DPM() macro is inside the header too, so the headers would have to be modified.
The macro would change from this:
to this:

Try it out and see if it works as expected. Post what you propose the CORE macros will be that will be included in the pins_aruduino.h files, and I'll test as well.

I'm not sure what other code out there is already using these BIT* and PORT* macros,
but I think Paul's way is a bit more useful with additional capabilities.

Nothing else I can think of off-hand, although I'm sure the compiler will quickly remind me if a macro it was expecting somewhere goes missing.

All this said it is a pretty large change and a good bit of work.
I'm not sure if folks are on board with the changes.
However, if this change is to be made, it is better to make it sooner rather than later.

I have to disagree. This looks a very minor change, and not much work at all.  smiley-mr-green

But I will agree that if we are going to do it, let's do it now. Just so we agree on something.

In looking at the low level code, it looks like there might be a small performance bump and
code size reduction if the tables stored the bitmask rather than the bit number.
i.e. let the compiler do the bit shift vs doing it at runtime in the data path.

--- bill

As long as the macros give you the access to the bit shift values as integers as well as masks, I'm happy. Writing a macro or function to convert a pin no. to a mask is trivial, but going the other way is annoyingly messy. One thing I didn't like about the original casting of the pin/port info is that it didn't have the pin no. info explicitly accessible, only indirectly in mask format, and that made things relatively awkward and inflexible.

(BTW, by "casting" I don't mean "cast" as in type casting, rather "cast" as in "represent in a particular way",  the more general/non-technical sense. Just to avoid any misunderstanding or confusion.)

7  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 24, 2014, 11:30:59 pm
I'm seeing this:
extern const uint8_t digital_pin_to_pcint[]; // this extern needed for mighty-1284p core support
show up in code. Like SoftwareSerial and the GSM libraries.
To me this is wrong. This is an extern to support some macros like

The code that uses those macros should have no knowledge about their internal implementation
and shouldn't have to do special things to make them work.
So in my view the extern declaration should be in  pins_arduino.h where the macro definition is.
i.e. the pins_arduino.h should do whatever it takes to make the macros/functions it uses & defines
work and that should also include declaring extern references when needed.
Was it just an "oops" or is there some reason why this wasn't done in pins_arduino.h?

The digital_pin_to_pcint[] array is defined in pins_arduino.h, but for only the "bobuino" variant. Because it's an array, and pins_arduino.h is potentitally pulled into multiple libs, the declaration is guarded by a #ifdef ARDUINO_MAIN, so the linker doesn't complain about multiple declarations..

Changing this so that

extern const uint8_t digital_pin_to_pcint[];
const uint8_t digital_pin_to_pcint[NUM_DIGITAL_PINS] =

will work just as well, and has the advantage of not needing a patched version of  SoftwareSerial, so I will make that change, and then we can remove the patched SoftwareSerial lib from the repo.

Given that this extern declaration is the only change to SoftwareSerial, if the extern is moved to pins_arduino.h
then a patched version of SoftwareSerial wouldn't be needed.

Another issue I'm seeing is that these patched libraries are interfering with other patched libraries.
For example, the Teensy install modifies some libraries. SoftwareSerial is one of the libraries that Teensy modifies.
So if you have Teensy installed and then try to copy/install the patched 1284 patched SoftwareSerial,
you overwrite/replaced the SoftSerial with Teensy support.
I think at least for SoftSerial, that if pins_arduino.h could be updated to include the extern for digital_pin_to_pcint[]
that this specific issue will go away.
But this is hinting at the issue I was concerned about: supporting patched libraries.
It is a very large task with almost no boundaries.

--- bill

The boundaries are just where you set them. In this case, I was seeking to make a set of libs that patch support for the mighty-1284p core with the official Arduino 1.0.5 IDE. If anyone wants to mix and match patched libs from other non-official distros of the IDE, fine, but that's beyond the well-defined scope of the undertaking here.
Having said that, if we can easily make things compatible with what Paul has done, why not?

But sorry, Bill, your hand-wringing and finger-wagging here leaves me as unmoved now as it ever has.  smiley-mr-green

8  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 24, 2014, 11:07:11 pm
In looking back at the commits, I see a pretty big change to the pins_arduino.h header file that
was put in as part of a commit related to adding patched versions of Ethernet, Servo, & SD.
It added defines for the bit and port for each pin.
I'm assuming that these changes weren't needed for those libraries, but were tossed in for clarity?

Actually, no, the port/pin info needed to be recast so as to be able to support Bill G.'s fast pin mapping code in Sd2PinMap.h SD lib (also used in his SdFat lib, in DigitalPin.h).

If adding all these new port and bit defines for each pin is desired,
I'd suggest moving down a path of what what Paul did in the Teensy core in his core_pins.h header file.
(It was rejected by the Arduino team but I believe it is quite useful and makes a lot of sense)
In his implementation, there are defines per pin for port, bit,  and bitmask but I think it is better than
what is currently in the 1284 variant pins_arduino.h header files.
You never use the port, bit, and bitmask defines directly but rather through macros and as and added bonus
you have the added ability to specify AVR port/bit pins directly. i.e.
digitalWrite(PIN_B0, HIGH);
to set PB0 high.

To make this happen, you create a define for each pin, whose name is PIN_Pb where P is the port and b is the bit
and the value is the Arduino pin number.
Then you have the port bit, and bitmask defines that are never used directly but
rather through some concatenation macros.

This allows you to access things like bit, bitmask or port: (examples for B7)

It is very clear and easy to visualize for things like the progmem tables.
If there is interest in moving twards Paul's "core" defines (which goes a bit further than just these bits/masks/port defines),
I'll be happy to do the mods, but I before doing it,
I want to make sure people are ok with this.

To see the defines and macros, look down in the teensy core at the file core_pins.h

--- bill

One other note:
Making these changes and adding these defines, should have no impact on existing code.
It merely adds defines that new code could take advantage of.

I'm completely OK with this, particularly if it ties into a scheme like Paul is already using -- why have fragmented approaches if they can be avoided? Before you do too much work, please double check that the recasting is still going to work for the SD and SdFat libs.

9  Using Arduino / Networking, Protocols, and Devices / Re: newbie quiestion: nRF24L01+PA+LNA talking to nRF24L01+ on: June 22, 2014, 09:36:50 am
I use the PA-variant as receiver from UNOs 3V3.   No problems detected...

The Uno 3v3 rail can't supply the peak current requirement for the PA+LNA variants, which is over 100mA. Running off the Uno 3v3 rail (or similar) "kinda/sorta" works, but you will actually be having compromised performance, with degraded performance in range in particular.

For the low-power "PCB trace antenna" style units, the Uno 3v3 rail is fine, as they have much lower peak current demands.
10  Development / Other Hardware Development / Re: Let's learn Arduino Micro's design :) on: June 22, 2014, 09:07:32 am
There is a diode pointing from RESET to 5V. See the far left side of the diagram. What does it do?

I believe this is something that came from the late revision UNO's.  See

The diode prevents the reset pin voltage from rising (much) over 5V. Anything higher, and the diode shunts it back to the 5V rail voltage.

This is to designed to prevent the AVR accidently going into HVP (high-voltage programming) mode by a transient high voltage on the reset pin. So you can consider it a form of over-voltage protection.

11  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 22, 2014, 08:35:23 am
Just wanted to also say thanks to @Pico for his work on the libraries. Awesome!

Great timimg, as I've just put one of his (Pico's) "Skinny Bob" kits together today. It all went together very fast (less 1 hour, and I don't think I'm a fast solderer). Loaded some example sketches after installing and -- success!

Very satifying to start with a bag of parts in the afternoon and end up with a fully functioning board running programs just a few hours later!  smiley smiley smiley Thanks again to everyone who made this possible.

Excellent to hear. :-)

(One thing I would suggest is updating the Installation instructions on the GitHub page to include installing the libraries.)

Oops, good point, forgot about this... I'm not sure I can edit that page though. Perhaps you could update when you have time, Jack?
12  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 22, 2014, 08:31:13 am
Pico - I am interested to see the changes required for the SDfat library as that is what I use. I don't recall any issues with the previous Mighty-1284 version.

You wouldn't have seen issues unless you were enabling USE_SOFTWARE_SPI in SdFatConfig.h, as all the required changes were in DigitalPin.h.

At any rate, do you have a link where I could download the fixed version of SDfat for 1284?

For want of a better idea of where to park it, I've uploaded it to patched-libs/unofficial so as to make accessible until such time Bill G. incorporates the changes into his next release.

13  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 20, 2014, 09:10:44 am
In any case, that completes the first cut at porting all the 1.0.5 official libs to mighty-1284p core support. Nothing too difficult, as it turned out. But significantly, this gets us to an important "Everything you need to run Arduino on an ATmega1284P microcontroller" milestone.

So what's next?

I should note that (not by accident) the changes for the SD lib also straightforwardly adapt to Bill Greiman's SdFat lib.

Because of its many improvements over the official SD lib, I suspect SdFat is probably more widely used than the official SD lib.

I've been in contact with Bill G., and he is receptive to SdFat support for the new mighty-1284p core, although he is not sure when the next version of the SdFat lib will be released.

In any case, the patches for SdFat lib are ready to go -- it's just a question of where they get hosted, if at all, until the next release of SdFat. One possibility we could host them here under "patched-libs/unofficial", with the understanding that when the support becomes available in the mainstream release, then the interim patched version could be removed from the repo.

Thoughts? Are there any other third-party libs important enough that we should be thinking about pro-actively approaching the maintainers for mighty-1284p core support?

14  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 20, 2014, 03:40:18 am
And to complete the port of the 1.0.5 official libs, I just pushed partial support for the RobotControl lib (changes to SdCard.h).

From the README.txt:
Note: This is not a complete port of the RobotControl lib, only a single file (SdCard.h) with changes that would be required for SPI pin assignment if ever a full port to using the mighty-1284p core was undertaken. It is unclear, however, whether the RobotControl lib could be or should be applied to anything except the Arduino RobotControl hardware. The library seems to be a melange of many other libs, and has the potential to interfere with files with the same name in other standard libs (e.g., SPI.h, SPI.cpp). Given these considerations, it is not intended at this stage to support the lib for the mighty-1284p core project beyond providing this single patched file for reference.

How and when it should be deployed it left to the user, but because of the potential problems indicated above, the recommendation is to not install the RobotControl lib unless there is a definite requirement, and you fully understand how the Arduino IDE build process works (and when it doesn't) so you can debug any snarls resulting from the wrong files picked up from the libs containing files of the same name.

I don't know much about the Arduino RobotControl hardware, but the way they've provided support in this lib really looks like a mess. Anyone know the back story on this one?
15  Using Arduino / Microcontrollers / Re: Updating the mighty-1284p core on: June 20, 2014, 01:52:55 am
I just pushed an updated version of the GSM lib to patched-libs/official, two-step process.
Pages: [1] 2 3 ... 60