Show Posts
Pages: [1] 2 3 ... 185
1  Development / Suggestions for the Arduino Project / Re: Serial.print without screen on: Today at 12:14:19 am
The picturesque technical phrase for this is the bytes are "dropped on the floor".
Technically the bytes are not necessarily dropped on the floor.
Assuming a UART serial port is being used,
all bytes are still handed to the Serial class which buffers them and sends them out the UART
since with only TX and RX UART serial signals, there is no way to tell if there is a listener.
If the TX buffer fills, the sketch will be paused/blocked while the Serial class library
is waiting on the data to exit the UART to make room in the TX buffer.

For boards like Teensy and Leonardo, I think if the USB host is not attached
the bytes are thrown away (dropped on the floor) since the USB code
can tell there is no host.



2  Development / Suggestions for the Arduino Project / Re: printf - bug (missing output device?) or "feature" to promote String class? on: Today at 12:04:35 am
Actually after small search found the solution here. I also realized that there is no "standard" output for the processor itself.
Still feel the Arduino compiler could do better job. After all it is cobbled from various resources, so why not adding another piece of code?
SOLVED
Case closed

There is no such thing as "the Arduino compiler".
You seem to be confusing the functionality of the IDE, vs the Arduino libraries vs the avr-gcc compiler
vs AVR libC.

What you are talking about here is a combination of interrelated capabilities and runtime startup responsibilities.
AVR libC provides a mechanism to redirect printf() output to an output routine.
The Arduino startup code and core libraries are not initializing the low level AVR libC library routines
to use  any sort of i/o for printf() so the printf() does exactly what it should: drops it on the floor since
it does not know who to call to output the characters.

The Arduino startup code could have initialized the AVR libC to re-direct
printf() to the default Serial class device.
But it doesn't.

For whatever reason, the Arduino team has not really ever embraced xxprintf() support.
It essentially re-invented the world with the Print class.


--- bill



3  Development / Suggestions for the Arduino Project / Re: Compiler continue to use commented out #include headers on: September 29, 2014, 11:49:22 pm
However, after commenting out the #include code the compiler continue to use these commented out headers!
Spitting out tons of errors caused by wrong enviroment path.

From the limited information provided, I think this may be a known problem, if so it has been mentioned on the dev list. The IDE does a simple regex to scan the ino file for "library includes", and it ignores comments and ifdefs, unfortunately it can pick up libraries that are not actually in use.

I think the only workaround is to delete any include lines that are not in use. To solve this properly might need a complete C parser in the IDE, which is impractical.

The compiler is not the issue. The IDE is the problem
The IDE has attempted to do way too much inside it rather than try use existing tools better or
try to coax the users to a little bit more.
It isn't just commenting out a header that will create issues for the IDE, a more common and potentially more complex
case is when conditional compilation is done.
The same problem also exists for function prototypes.
The IDE could be smarter by doing the scan for includes for libraries and functions (to generate prototypes) in multiple passes.
The first pass would scan the sketch and would set up include paths for the c-pre processor (not the compiler)
Then run the c-prepressor with those include paths to do the only pre-processing on the sketch.
The second pass would scan the pre-processed file for the actual includes used and functions used.
Then the IDE could use that list of includes (which are the includes really used) and functions
and proceed just like does now.

There are many other parsing issues in the IDE that could also be solved if the IDE would simply
use a double scan approach that involves the C pre-processor rather than trying to do all
the parsing itself.

--- bill
4  Development / Suggestions for the Arduino Project / Re: Suggestion: A Better Leonardo Bootloader. on: September 29, 2014, 11:31:51 pm
I use leonardo on Linux Mint 13.
(Not the Official one but the Itead Loenardo).
I'm assuming it uses the same bootloader.
The only issue that I have is that because of the way the bootloader works, the virtual comport
device sometimes shifts around.
This can create some issues when trying to connect to the serial monitor after unplugging and
plugging it back in after uploading since the tty device name will shift/change
but other than that it seems to work just fine.

--- bill
5  Using Arduino / Displays / Re: UART vs SPI vs I2C on: September 29, 2014, 02:49:41 pm
1 ) SPI, it is fast. Use SPI, forget the rest. You don't even have to read the rest of this post  smiley-roll-blue

2 ) I2C, it is slower but can be easier in use. Only 2 pins are needed, and it is easier to interface a 5V Arduino board with a 3.3V sensor. Although I like to use I2C for everything, it is not the best option for a graphical display because it is slower than SPI.

3 ) UART, bad choice, slow. It is to be compatible with very simple microcontrollers, or to be able to connect it to a computer (with a usb-serial-ttl converter).

From a bit rate perspective, UART can be  faster than I2c.
The default rate for i2c 100kbits/sec.
UART can be set up for baud rates faster than that.
The bus overhead for i2c can also be higher because of the i2c protocol
things like start signal, and address bytes are involved.

--- bill
6  Using Arduino / LEDs and Multiplexing / Re: I2C not working with 74HC151 multiplexer (EDIT: Trying with SoftI2C.h now) on: September 28, 2014, 09:48:18 am
Quote
  SoftI2C would have been much easier and need no external hardware... just connect up the wires.   

I can't think of any reason to disagree with this statement.

One potential issue might be that if there is an existing library for the slave device
since you can't use it if you switch to a software i2c without modifications.

But there isn't. He's posted his code.
From what I've seen, it isn't the full code. Only small snapshots
and none of it seemed to be working.


Quote
Another consideration is pins.
Since 4 devices are involved, that means using 5 pins to isolation them.
(5 pins is if you cheat and share the SCK pins so 1 pin for SCK and 4 for SDA)

How many pins will it take to control the multiplexing hardware?


From my previous post:
Quote
Whereas the external h/w solution would only use the original h/w SDA and SCK pins
for the buses plus 2 pins to control the external switch.
This is a total of 4 pins. A net savings of 1 pin.

5 pins for the s/w only solution, and 4 pins for the h/w solution.
And that assumes sharing the SCK pins for the s/w solution.
If not sharing the SCK pins the s/w i2c solution jumps from 5 pins to 8 pins.

And if there is a need to still use the h/w i2c for say other slaves
then that adds to more pins.
So s/w i2c is 5 or 8 pins plus potentially the 2 pins for h/w ic2
for a total of 7 or 10 pins
and h/w switch is 2 pins for h/w i2c and 2 pins for the switch
for a total of 4 pins.

Quote
  SoftI2C would have been much easier and need no external hardware... just connect up the wires.   
I can't think of any reason to disagree with this statement.
I can.  Eight pins used on the Arduino (as against four with the multiplexer), managing three simultaneous instances of SoftI2C.

[/quote]
I think it would MUCH easier to put all the devices on softi2c rather than leave one on h/w i2c.
So there would be 4 instances of Softi2c.
Have an object for each device makes things considerable easier since you can then treat them
all the same and use an array of objects & constructors and simply specify which device to use
by its index into the array.

7  Using Arduino / LEDs and Multiplexing / Re: I2C not working with 74HC151 multiplexer (EDIT: Trying with SoftI2C.h now) on: September 28, 2014, 09:21:55 am
Quote
  SoftI2C would have been much easier and need no external hardware... just connect up the wires.   

I can't think of any reason to disagree with this statement.

One potential issue might be that if there is an existing library for the slave device
since you can't use it if you switch to a software i2c without modifications.
The modifications to the library might be fairly extensive, whereas if using external h/w
to isolate the i2c buses, it is likely that there would be no issues with any of the existing libraries.
You simply setup the external h/w to point at the proper bus and then call
the library code.

If you are not using an existing library then it this is not a consideration;
however,  if other i2c devices and libraries are involved like LCD, real-time clock then you end up
still having to use the Wire library anyway for those libraries.

Another consideration is pins.
Since 4 devices are involved, that means using 5 pins to isolation them.
(5 pins is if you cheat and share the SCK pins so 1 pin for SCK and 4 for SDA)
Whereas the external h/w solution would only use the original h/w SDA and SCK pins
for the buses plus 2 pins to control the external switch.
This is a total of 4 pins. A net savings of 1 pin.

Not that I'm recommending either way, these are just some things
to consider.

--- bill
8  Using Arduino / Programming Questions / Re: Time and TimeAlarms Libraries – Ask here for help or suggestions on: September 28, 2014, 12:12:23 am
@PaulS
Quote
There are no Arduinos with 1024 kilobytes of memory, of any kind
Can you shed some light on this one ??
http://arduino.cc/en/Main/arduinoBoardUno
As per the spec ...
Quote
Flash Memory   32 KB (ATmega328) of which 0.5 KB used by bootloader
SRAM   2 KB (ATmega328)

1 KB is not the same as 1024 kilobytes.
(Well not unless you do math like Verizon):  
Units matter.
1024 kilobytes is 1MB.


9  Using Arduino / LEDs and Multiplexing / Re: How to use 74LS138 or 74HC595 to muliplex two I2C signals? on: September 26, 2014, 08:59:01 pm
Fewer pins than a MUX ?
But its not more Arduino pins if you are only using 2 buses.
1 pin selects between them.
And then there is the issue of power to the coil, and size, and slowness of using a relay.
http://forum.arduino.cc/index.php?topic=269115.msg1898314#msg1898314
--- bill
10  Using Arduino / LEDs and Multiplexing / Re: I2C not working with 74HC151 multiplexer (EDIT: Trying with SoftI2C.h now) on: September 26, 2014, 08:54:23 pm
or a DPDT relay...
But that now probably requires a transistor, and a diode and the processor will have to blind wait many milliseconds
(probably 10-20) to give the contacts time to move and then let the contacts settle after changing states.
Not to mention it needs quite a bit more current and is typically much larger than using a analog switch chip.
IMHO, an analog switch/mux/demux chip is a much better solution.
11  Using Arduino / LEDs and Multiplexing / Re: I2C not working with 74HC151 multiplexer (EDIT: Trying with SoftI2C.h now) on: September 26, 2014, 08:32:00 pm
I bet you can get away with only muxing SDA vs having to do both SDA and SCK. Tie all the SCK signals together.
Upon reading this somewhere else in these forums I have given this a shot, but I couldn't get it to work with the multiplexor I was using (due to it not being the wrong one, I suppose).
Both signals (SDA and SCK) are bidirectional so you still must use a bi-directional switch
even if you don't mux/switch the SCK signal.

--- bill


12  Using Arduino / LEDs and Multiplexing / Re: I2C not working with 74HC151 multiplexer (EDIT: Trying with SoftI2C.h now) on: September 26, 2014, 06:11:13 pm
You can't change where signals are connect to while data is moving, but assuming that the AVR is the only master
then you can select which bus the AVR 2Wire signals are connected to before you call the Wire routines.

I bet you can get away with only muxing SDA vs having to do both SDA and SCK.
Tie all the SCK signals together.
Since only the slave on the selected bus will see his address, only that slave will respond.
All the other slaves on the non selected buses should see an address of 0xff/0x7f from
the idle pullups and remain silent.

--- bill
13  Using Arduino / Microcontrollers / Re: Smaller substitute for Arduino uno on: September 26, 2014, 11:16:30 am
tonyT40 you have given us an ambiguous and potentially impossible
set of requirements.
Until you further qualify what:
Preferably the new board should have all the supporting hardware found on the Uno board.

means, there is no way to make any sort of recommendations.

What do you really need in the board?
(again, think what you truly need vs want)
Things that make substantial difference:
- processor
- shield compatibility
- 3v/5v

--- bill
14  Using Arduino / Displays / Re: Contrast problem using 1602A LCD over I2C on: September 25, 2014, 12:48:35 pm
 Moral of the story: Breadboard power supplies like the one I was using must be supplied with more than 5V in order to feed 5V to the breadboard. 
I find it much easier to use USB to power the breadboard adapter.
A computer is already needed to build the code, might as well use one of the USB ports
to power the breadboard.

--- bill
15  Using Arduino / Project Guidance / Re: Compile code on the arduino on: September 24, 2014, 11:26:07 pm
Also, not only did those systems have lots more RAM than the AVR but they also used files on a disk (floppy)
to do things just like our more modern systems.
I'm thinking you  guys that are thinking this is possible on an AVR don't understand how programs
and embedded images are built.
Here are the basic steps to compiling and linking an image:
- cpp processes the .c or .cpp original source file to creates the pre-processed file
it will need access to all the files are included using #include.

- the compiler processes/compiles the cpp files and creates the assembler code in a file.
- The assembler runs and builds the .o
- This repeats for all the files being built.
- The linker processes all the .o files and links against any pre-built libraries
(like the C startup & runt time libraries) to create a linked image.


Now toss in Arduino and the way it works and you have even more "mess" to deal with.
There is a LOT of goofy stuff that the IDE does to turn a .ino file
into a .cpp file. This requires access to all the library directories
(both the IDE supplied one and the user sketchbook one).

Then because the Arduino system doesn't really use libraries,
(Other than for the "core" code, Arduino doesn't use real libraries, it builds all the files in its "libraries"
and links against the individual .o files for each "library" used)
the IDE must compile all the needed files for the "libraries" it happened to notice while
doing that first pre-processing step.

So even if you had more RAM, there would not be enough FLASH in the part
to hold all the source code to all the "libraries" which have to be scanned and built.
Bring up the IDE and build a sketch then go look down in the tmp directory at all the files created.
In order to build an image you would need to have room for all those files.
The build process could be streamlined and made smarter to use real libraries
which would eliminate having to compile "library" code modules but even if you did that
there still wouldn't be enough room to hold the .a library files much less all the include files
needed to compile the sketch.

Even if you used an SD card for all the files, there still isn't enough ram to able to
support all the internal data needed to run something like a C pre-processor or a compiler.

It just isn't possible.

As far as the PIC running unix goes, if I remember correctly the PIC was not
actually running linux but emulating an ARM system which ran linux.  - This is not the same thing.
Since it was emulating, it could also create a h/w interface to use more ram.
http://www.extremetech.com/extreme/124287-the-worlds-slowest-linux-pc

--- bill
Pages: [1] 2 3 ... 185