Show Posts
Pages: 1 ... 4 5 [6]
76  Using Arduino / Installation & Troubleshooting / Upload Using Programmer - Terribly Slow and erases EEPROM on: May 25, 2012, 05:29:36 pm
I'm working on a sketch that is uploading to a sparkfun pro micro (Leonardo clone / 32u4) and to fit all the features I want I've removed the bootloader from the 32u4. I am using a USBTinyISP programmer board.

I've got a few issues / questions though.

First, using the File menu...Upload Using Programmer option does work, but it is excruciatingly slow. Much slower than using the USB bootloader. When I've used avrdude directly on non-arduino projects, it has always run quite fast. Are the avrdude parameters saved somewhere that I can edit them directly to speed up the burn process?

Second, same scenario, using File -> Upload Using Programmer, the upload erases my EEPROM every time. I have settings saved to EEPROM so they will survive reboots / power cycles / testing but it defeats the purpose if the EEPROM is going to get erased every time I re-upload the sketch. I know this is an option in avrdude, so, same question as above - where can I find the avrdude settings, so I can edit them to preserve EEPROM during uploads?

And finally, on this page: http://arduino.cc/en/Hacking/Programmer it mentions that  you can add an upload.using= parameter to your boards.txt file, to set the default for that board to use the programmer. I have set this up in my boards.txt file for this board (created a new entry for it) and set the parameter to usbtiny but the IDE seems to ignore this setting. Is this a case of the documentation not keeping up with the code? Is the syntax different nowadays? Here's the entry from my boards.txt file:
Code:
proMicroICSP.name=ICSP ProMicro 3.3
proMicroICSP.upload.protocol=arduino
proMicroICSP.upload.maximum_size=32768
proMicroICSP.upload.using=usbtiny
proMicroICSP.bootloader.low_fuses=0xde
proMicroICSP.bootloader.high_fuses=0xd8
proMicroICSP.bootloader.extended_fuses=0xcb
proMicroICSP.bootloader.path=diskloader
proMicroICSP.bootloader.file=DiskLoader-ProMicro8.hex
proMicroICSP.bootloader.unlock_bits=0x3F
proMicroICSP.bootloader.lock_bits=0x2F
proMicroICSP.build.mcu=atmega32u4
proMicroICSP.build.f_cpu=8000000L
proMicroICSP.build.core=arduino
proMicroICSP.build.variant=proMicro8

Thank you!
77  Using Arduino / Displays / Re: LCD - can you program characters? (Or looking for a certain character) on: May 25, 2012, 07:15:35 am
The standard LCD character display screens with the HD44780 or compatible drivers have room for up to eight custom characters. I've used these to create degrees-symbols and that sort of thing. There's a web-page that gives some good information about these displays and how to create characters for them:
http://www.quinapalus.com/hd44780udg.html

In the LiquidCrystal library, the command to create the character is lcd.createChar() - there is an example here:
http://arduino.cc/en/Reference/LiquidCrystalCreateChar

Cheers!
78  Using Arduino / Networking, Protocols, and Devices / Re: Ethernet shield and differentiating between clients on: May 23, 2012, 12:57:14 pm
I'm not sure about differentiating between client1 and client2 within the Arduino code, but the W5100 somehow does it internally. I know this because I have had two persistent telnet connections onto my Arduino's ethernet port at the same time, and there is no 'crosstalk' or confusion between them. When client1 sends some data over and the arduino responds, the arduino's response goes to client1 and client2 is never involved at all. And the same if client2 is active and client1 is idle. (You couldn't get concurrent activity as the Arduino can't multithread, so if they both tried to be active at once one of them would get served first and the other would be buffered then served second.)

I've dug into this while tracking down another bug and what I find is that when server.available() returns a client, the information returned is the connection number. You could probably track that information, eg. if client1 is on port 0 then you could keep track of whether or not port0 has passed some sort of authorization before accepting commands. You just have to ensure you clear the authorization flag when the client on port0 has logged off. And since the W5100 is limited to 4 connections, you really only have to worry about a maximum of 4 authorization flags, so it shouldn't take a lot of memory to monitor that.

You can read through the various files in the Ethernet library to see how it all comes together.
79  Development / Suggestions for the Arduino Project / Re: Option to Not include all the USB libraries (Leonardo & compatibles) on: May 23, 2012, 12:36:18 pm
That would be much more elegant and friendly if it could omit the HID stuff until added by a .begin() statement. My mindset was more in coming at it from a 'hacking' perspective and what would be easiest for an 'advanced' user to modify, while leaving it all simple and unchanged by default.

What I have found as a relatively straightforward hack is in the core files, in main.cpp if I comment out the USB.attach() line, the USB is never initialized and the compiler optimizes away all the USB code even though it was included in the sources. So there's no HID but also no CDC either, and the compiled sketch is about 3kB smaller. There's also about 50bytes of RAM freed up.

Anyhow, thanks for the replies! If I can help somehow I will, but my C / C++ are not great.
80  Development / Suggestions for the Arduino Project / Option to Not include all the USB libraries (Leonardo & compatibles) on: May 23, 2012, 07:20:59 am
I've been working with a Leonardo compatible (Sparkfun Pro Micro, using the 32u4) and with the 1.0.1 version of the IDE I had the opportunity to compare the ProMicro and Leonardo build processes. What I was a bit dismayed to find was that all the USB libraries are loaded regardless of whether they are needed or used.

In other words, even if your sketch does not use keyboard, mouse, or Serial classes, when the sketch is compiled all the libraries for keyboard, mouse, and CDC serial are included. It seems that this is controled in a bunch of core files which are testing " if defined(USBCON) ...."  This is defined in Avrdude's conf file, and I believe it would apply for any Avr chip that has on-board USB.

It also concerns me for the future, if more native USB functions are added (eg. joystick, midi, are two I've seen requested) then it seems likely these might be added the same way as the existing functions, and would end up being part of every sketch whether used / needed or not.

The reason I find this excessive is that the USB libraries seem to add about 3kB to the size of the sketch. So if your project does not use any of the USB routines, you're wasting about 10% of the available flash space for un-needed code.

When the USB libraries are not included, the only drawback I have encountered is that the board does not auto-reset when you try and load a new sketch. This is a minor inconvenience though as you have already got the 1.0.1 IDE set to let the Leonardo board fall-back on a manual reset incase the auto-reset does not work. (This seems to be hardcoded to the Leonardo board however, rather than being common to any board using the 32u4. It would be nice to expand that fall-back upload method to be based on the chip type rather than the bootloader name.)

I understand that for friendliness and compatibility it would be preferable to keep the USB libraries being always-loaded as a default behavior, but it would be great to have the option to override that behavior and have the libraries omitted. Perhaps change the core files from testing USBCON to testing some other build-time define, which would be included in the boards.txt file by default? Then overriding it would mean only editing boards.txt rather than having to go through a half-dozen or so core files?

Thanks & cheers!
81  Using Arduino / Networking, Protocols, and Devices / Ethernet Shield as Server, Multiple Connections? on: December 08, 2011, 02:17:35 pm
According to the info on the Arduino Ethernet shield, it can handle up to 4 connections.

I'm using the shield on a Mega, running the ethernet in server mode. The client connects and sends text to the arduino and receives text back, and remains connected until the client disconnects.

This all works fine, as long as only one client is connected. If a second client connects, the Arduino becomes nonresponsive to the other client. It seems to cache a bit of activity from the 'frozen' client, which is then acted on when the other client disconnects.

Looking through the documentation and the library sources, I think the problem lies in the fact that there doesn't seem to be a way to get a client object for more than one connection. You use server.available() which
Quote
Gets a client that is connected to the server and has data available for reading. The connection persists when the returned client object goes out of scope
However, in getting 'a' client, it doesn't seem to have provision to get more than one client, or rather, to get additional clients should they exist.

The source for server.available() looks like it just counts up through the four available sockets and returns the first one that has a connection:
Code:
EthernetClient EthernetServer::available() {
  accept();
  for (int sock = 0; sock < MAX_SOCK_NUM; sock++) {
    EthernetClient client(sock);
    if (EthernetClass::_server_port[sock] == _port &&
        (client.status() == SnSR::ESTABLISHED ||
         client.status() == SnSR::CLOSE_WAIT)) {
      if (client.available()) {
        // XXX: don't always pick the lowest numbered socket.
        return client;
      }
    }
  }
  return EthernetClient(MAX_SOCK_NUM);
}
Despite the comment to the contrary, I don't see anything in there that indicates that it would not always pick the lowest numbered socket.

So it doesn't look like it would help if I tried calling server.available four times over, assigning each call to a different client.. so this would probably just return four instances of the very same connection:
Code:
EthernetClient client1 = server.available();
EthernetClient client2 = server.available();
EthernetClient client3 = server.available();
EthernetClient client4 = server.available();
Does anyone know how to go about handling multiple concurrent connections? Or do I need to do some rewriting of the ethernet library?

Thanks!
Pages: 1 ... 4 5 [6]