Arduino doubts

Go To Last Post
63 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After just purchasing a Freetronics Eleven board (arduino UNO compat) with little intention of trying out the Arduino environment, I got sucked into it by having to load drivers etc to work the bootloader. So, I had a play with the examples and I was impressed, so I thought I'd dig a little into how it works. With the hardware serial port functions, I spied this:

int HardwareSerial::read(void)
{
  // if the head isn't ahead of the tail, we don't have any characters
  if (_rx_buffer->head == _rx_buffer->tail) {
    return -1;
  } else {
    unsigned char c = _rx_buffer->buffer[_rx_buffer->tail];
    _rx_buffer->tail = (unsigned int)(_rx_buffer->tail + 1) % RX_BUFFER_SIZE;
    return c;
  }
}

and where the buffer is written:

inline void store_char(unsigned char c, ring_buffer *rx_buffer)
{
  int i = (unsigned int)(rx_buffer->head + 1) % RX_BUFFER_SIZE;

  // if we should be storing the received character into the location
  // just before the tail (meaning that the head would advance to the
  // current location of the tail), we're about to overflow the buffer
  // and so we don't write the character or advance the head.
  if (i != rx_buffer->tail) {
    rx_buffer->buffer[rx_buffer->head] = c;
    rx_buffer->head = i;
  }
}

and the declaration of the buffer:

struct ring_buffer
{
  unsigned char buffer[RX_BUFFER_SIZE];
  int head;
  int tail;
};

My concern is the lack of atomic access with the shared variables rx_buffer->head and rx_buffer->tail consider they are both ints (16 bits) and there's read/modify writes happening.

So, my question to the people more experienced with the Arduino environment, is there some magic happening behind the scenes that ensures atomicity? Or is it the usual case of 'it works most of the time'?

In order to assuage my doubts, I started to search for where the generated files are stored so maybe I could look at the compiler outputs - but I could find none. Seems the evil is well hidden. Does anyone know how I can look at the generated code from gcc?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The lack of atomicity is an oft levelled criticism of the Arduino library code. I think if you search the Arduino forums you'll find this has been discussed.

BTW why "General Electronics" - surely this is on topic for AVR Forum?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, move it if you so desire, I was playing safe due to the Arduino reference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup I'll move it - Arduino actually appears to be one of the best things to happen to AVRs in years so it is very much on-topic.

I think it was bperrybap who was noting atomicity problems with Arduino and he seems to be registered under the same ID on their forum,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm just curious. If you defined the head and tail as uint8_t and kept the buffer size to <= 256, would this take care of the issue? Something creeps up in the back of my mind about type promotions that my Google-Fu isn't able to find, so I'm wondering if the uint8_t would be a problem?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Uint8_t would only work if there was no read/modify/write and the possibility of a incorrect result of old head and new tail or vice- versa. No get out of jail card unfortunately.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
My concern is the lack of atomic access with the shared variables [...]
I have proposed a couple of changes to rectify what I thought were significant defects in the Arduino code base (see, for example, this thread). As far as I can tell, the suggestions have not been implemented (and actively argued against by the admin "mellis"). After a couple of tries, I abandoned the idea of attempting to improve the Arduino code.

edit: fixed closing quote tag

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Last Edited: Sun. May 1, 2011 - 08:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Uint8_t would only work if there was no read/modify/write and the possibility of a incorrect result of old head and new tail or vice- versa. No get out of jail card unfortunately.
I hope I'm not hijacking the thread, but I'm not really following this and maybe a restatement of the problem would help.

What I thought was being said is the the head and tail indexes being 16-bits might be in the middle of being changed (one of the two bytes gets loaded) when along comes and interrupt that does who knows what and when the interrupt returns the rest of the index gets changed (the other byte of the index gets loaded) possibly incorrectly due to what ever happened in the interrupt.

I suggested just using byte sized indexes as a possible solution since the byte loading takes place in one operation and wouldn't be interrupted. I'm sort of in a brain fog today so what am I missing?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even with a byte sized index if you have to load it, change it, and store it as separate operations you can have problems. Consider that after you've loaded it, the interrupt happens and the handler changes the value you just loaded. Later, when you store your "new" value you are losing what the handler did.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's a bit like the Kaos agent popping something into your coffee when you're not looking. "That trick again?? that's the third time this week!"

It's a bit of a worry when the framework you're heavily depending on is suspect.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I get it now. I'm in the midst of writing a serial library that uses a circular buffer with interrupt based Tx and Rx so now I'll go back and revisit my indexes to see if this is going to be an issue.

Thanks,
Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think there is any atomicity problem in the serial driver. The "process level" code reads the buffer head buy only modifies tail. The ISR code writes tail but has read-only access to head. The worst that can happen is that read() could miss a character that arrives during its own processing, or the ISR could decide the buffer is full when in fact it might have fit one more character in there. Neither of those should be a real problem.

Do you see an actual failure scenario, or are you just bothered by the lack of cli instructions?

(There are a number of ways that the serial code could be better for several definitions of "better.")

The Arduino IDE puts object code in some weird temporary directory picked by the Java runtime environment (as far as I can tell. Blech.) You can see where by holding down "shift" when you compile with the "verify" button, or by setting build.verbose in the preferences. You can also specify a different build directory in the preferences (I think these both require manually editing the preferences file; they're not one of the bits changeable via the GUI.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've yet to figure out how to do an Arduino project with multiple .h and .cpp files.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dkinzer wrote:
I have proposed a couple of changes to rectify what I thought were significant defects in the Arduino code base
Some months back I pressed for the rationale for not having buffered/interrupt driven UART output. Or at least tell the Auduino neophytes that a wait-loop for serial.print is likely to cause timing problems.

I was curtly dismissed by the Arduino (a non-profit) principals with the defense that the typical Arduino user would find this befuddling.

I thought the typical user should at least know there's a timing issue that, with experience, they'll know needs to be considered for some projects.

It smells like a profit motive, or ego amok.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Westy, I think you're right. I've been on pain killers recently and been jumping at shadows(literally!). Thanks for the hints regarding where it puts things.

Steve, I did ponder the issue of buffered tx. Sometimes having to actually wait for the tx to complete is advantageous, other times it's handy to decouple it. It would be simple enough to add a method to enable tx buffering and keep everyone happy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Yup I'll move it - Arduino actually appears to be one of the best things to happen to AVRs in years so it is very much on-topic.

I think it was bperrybap who was noting atomicity problems with Arduino and he seems to be registered under the same ID on their forum,

That atomicity stuff I was pointing out (which was finally fixed after about year) was in the digitalWrite() code.

I ran into it about 1 week in to playing with Arduino.

Because of the way they implemented their code they can never get optimized SBI/CBI instructions so all digital pin operations are interruptible. It was causing all kinds of subtle little bugs but mainly was screwing up servo operations since it was interrupt driven and could interrupt other foreground digital operations which might clobber the servo library's pins.

BTW, if you use Paul's Teensy boards, he has different
core code, and if you use constants for the pin #s, and constants for the data values, you will get single instructions SBI/CBI instructions vs the standard Arduino core
which takes several microseconds to figure out what to do.

To me Arduino is kind of like Microsoft Windows. It can be very useful and even allow you to get lots of useful stuff done quickly, but it is a bit bloated and very "my way or the highway" when it comes to certain user features all in the name of making things easier for the user, and when pushed hard it might tip over and die.

--- bill

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
I don't think there is any atomicity problem in the serial driver.
I think you're right but only because the existing code only uses head/tail values that are less than 256. In HarwareSerial.cpp, the RX_BUFFER_SIZE is defined to be either 32 or 128 so the head/tail values range from 0 to RX_BUFFER_SIZE-1. Someone using a mega1280 Arduino with external RAM might be tempted to increase the buffer size to a value larger than 256 and *then* there would be problems. This issue could be prevented by adding code to force the buffer size to be 256 or less, by making the indices byte values or by adding proper atomic access code, none of which, apparently, the Arduino authors are inclined to do.

This is but one example of the poor coding practices used by the authors that make the Arduino code base a maintenance nightmare.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been following the Arudino mailing list for quite a while and I disagree with the assessments here.

These guys understand their intended base and keep a laser-like focus on that audience. It seems that half the posts on the mailing list are from folks who want to add little improvements to the Arduino but don't seem to understand that this system is designed for absolute novices who wouldn't have a clue about most of what is being spoken of here.

And I personally see no good reason to add or change anything - it works great as is for novices - the rest of us have the option of using the standard AVR tools with the board if we want to optimize it for our particular use. I do this all the time. I do quick and dirty tests with the Arduino IDE and then when I need something that is weak in the Arduino, I just spin my own version.

Somewhere I say:

Quote:
Massimo Banzi begins his book, Getting Started with Arduino:
“A few years ago I was given the very interesting challenge: teach designers the bare minimum in electronics so that they could build interactive prototypes of the objects they were designing.” He summarizes his philosophy of ‘learning by tinkering’ with a quote from www.exploratorium.edu/tinkering: “Tinkering is what happens when you try something you don’t quite know how to do, guided by whim, imagination, and curiosity. When you tinker, there are no instructions – but there are also no failures, no right or wrong ways of doing things. It’s about figuring out how things work and reworking them.”

Arduino provides a great toolset for designers, tinkers, and even some of us surly old engineers who sometimes just want to play with an idea. The genius of Arduino is that it provides just enough access to get specific tasks done without exposing the underlying complexities that can be truly daunting for folks new at this stuff.

IMHO the core team doing an admirable job in resisting the temptation to improve the Arduino unto death. You say it is like Windows? Well if Windows was improved to the satisfaction of software engineers it would be Linux and your Mom wouldn't be able to use it. There is a reason both Windows and Arduino are winning the market and it would pay to understand that reason before expending too much energy trying to improve either.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Well if Windows was improved to the satisfaction of software engineers it would be Linux and your Mom wouldn't be able to use it.

Not so, Smiley

It would be elevated to the height's of an Apple Mac, and everybody would be able to use it :)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, but I have to disagree. The Mac is designed in a locked room somewhere and nobody has any input other than the Mac folks. It is the ultimate take-it-or-leave-it system. What this thread is about is how 'we' have so many good ideas that 'they' ought to implement. Linux is all about 'we' and at least the Windows hardware is open and hackable. I'd be inclined to say that Arduino software >is< like the Mac - both are carefully closed to keep it simple for the novice user. Both Bansi and Jobs understand the KISS principle, something few of the Arduino critics seem to get.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The Mac is designed in a locked room somewhere and nobody has any input other than the Mac folks. It is the ultimate take-it-or-leave-it system.

And Windoze is different in this matter?

While you can install e.g. GNU tools on Windows, and with stuff like MinGW, or perhaps CygWin, you can build and execute applications expecting a GNU/Linux/Unix/Whateverix environment I'd expect this to actually be a lot easier on a Mac (since system X is, if I understand it correctly, based on BSD. Windows hardware might be more open than Mac hardware, so what?

It must be years since I last re-built a PC. And I've never used anything "out of the ordinary" - all things where fairy straight forward things with drivers available.

Looking at the operating software it becomes more interesting, and here it seems like Mac OS software is more open than Windows per se.

I tend to agree on the Arduino and KISS principle though. I suspect that those who want to "fix just this" in Arduino likes the simplicity, but has one thing that Arduino can't do for them, and if only that was fixed... Trouble is that differnt people have different "only this'es". I believe you when you say that the Arduino people do a good job at protecting the framework from fixing-to-death.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Re things like the coding errors for interrupted sequences, and the gotcha like lack of buffered UART out (spin-loops)... The Arduino novices shouldn't be given these bugs, anymore than a child should be given a bicycle with training wheels that fall off.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe I'm misunderstanding something. I was thinking folks were proposing things that would require changes to the current API, but are you saying that the API stays the same and that what is being proposed are bug fixes and that the Arudino core team rejected those fixes?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
Maybe I'm misunderstanding something. I was thinking folks were proposing things that would require changes to the current API, but are you saying that the API stays the same and that what is being proposed are bug fixes and that the Arudino core team rejected those fixes?

Smiley

For me, yes. My suggestion wasn't a bug but rather, a trap for the neophites. The UART input is interrupt-driven and buffered; the UART out is not, it's a busy-loop that affects timing. Timing impact is not mentioned in terse writeup for users.
(there are other UART/serial libraries, but typ. user wouldn't know)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The Mac is designed in a locked room somewhere and nobody has any input other than the Mac folks.


I'm sorry to have to drift OT here, but you are completely wrong about this. I run Snow Leopard Server on one of my boxen and you would surely gawk at the amount of 'open source' modules which are implemented 'out of the box'!
In fact, almost all of the services which this box runs are entirely open source. Come on.. even the kernel is based on Darwin! There are elements of BSD scattered throughout the system. You can implement any GUI or package manager that you choose to.
Just open a terminal window on ANY Mac box and feel free to use practically ANY unix(derivative) command set to hearts desire.
It's about as proprietary as my left foot!
Yes, they package it all up and shove a pretty front end on it, for the average user, but, at the end of the day... IT JUST WORKS!

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, my example wasn't good. I haven't looked a Macs in a long time and last I looked it was proprietary hardware and software. I'll accept your statement that the software is open now. Sorry.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am depressed at how few people seem to understand that buffering uart output doesn't solve "timing problems." In fact, the busy-wait code is much more predictable.

(meanwhile, I'm also waiting for an explanation of how th current uart code would go bad if buffersize was larger than 256. I still don't see it.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
I am depressed at how few people seem to understand that buffering uart output doesn't solve "timing problems." In fact, the busy-wait code is much more predictable.

(meanwhile, I'm also waiting for an explanation of how th current uart code would go bad if buffersize was larger than 256. I still don't see it.)

? If the CPU spins in a loop for one character-time rather than doing work that the user naively thought would always be done, then there is a problem. These kinds of users (Arduino beginners) don't know about state machines or interrupt service routines, etc.

as to the 256 byte issue.. the code could have been written to use a ring buffer mask size of 8 bits. This is bad but commonly done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
westfw wrote:
I am depressed at how few people seem to understand that buffering uart output doesn't solve "timing problems." In fact, the busy-wait code is much more predictable.

(meanwhile, I'm also waiting for an explanation of how th current uart code would go bad if buffersize was larger than 256. I still don't see it.)

? If the CPU spins in a loop for one character-time rather than doing work that the user naively thought would always be done, then there is a problem. These kinds of users (Arduino beginners) don't know about state machines or interrupt service routines, etc.

as to the 256 byte issue.. the code could have been written to use a ring buffer pointer mask size (modulo) of 8 bits. This is bad but commonly done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that buffered routines are not good for a beginner as they effectively introduce concurrency and that's a bridge too far.

For example

Serial.print ("123456788");
// ok that's done now let's get the response
if (Serial.avaliable > 0)
   // get response from remove uC

Clearly (to an experienced coder) in a buffered system the "if" is executed probably half way through the start bit of the "1", but a beginner would assume the entire string had been transmitted.

OK I know we started talking about RX, but I often see confusion about this sort of timing on the Arduino forum and I don't think buffering helps. A beginner has enough on his/her plate understanding things when they happen in a defined order.

Note: I believe the next Arduino release has buffered Tx as well.

On the RX side I often see this

if (Serial.available > 0)
  for (x = 0; x < 10; x++)  // get 10 charcaters
     Serial.read()

Which normally gets the first character and no more (or 9 NULLs or whatever is the error return) because the 10 iterations are performed before the second character has even started.

I think there is a good argument for beginners to use blocking functions

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If the CPU spins in a loop for one character-time rather than doing work that the user naively thought would always be done, then there is a problem.

And if the cpu spins in a loop waiting for the buffer to have room, instead of for the UART to have room, the situation is improved how, exactly ? The same beginners are going to be unclear on the concept of "IO limited." Sure, there will be some cases where they only output ten bytes every second and buffering will help. But many cases will have exactly the same problem with a 64 byte buffer that they do with the 2 byte (uart hardware) buffer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
These kinds of users (Arduino beginners) don't know about state machines ...
Just to make state machines easier for "them" ;-)
http://www.state-machine.com/arduino/index.php
Also Quantum Leaps has a CASE tool to diagram, test, and generate code to create state machines.

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Serial.print ("123456788"); 
// ok that's done now let's get the response 
if (Serial.avaliable > 0) 
   // get response from remove uC

Surely just as likely to fail, and for the same reason, even if a buffer is not used?

Cheers,

Joey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah you're right, I guess there still wouldn't be a response for at least 2 byte times (or one if you block until TX done), I couldn't find a real example but that's the sort of thing and the "// ok that's done now" part of the comment is what people think when is isn't "done" at all.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is in fact a common Arduino problem for people to try to do:

if (Serial.available()) {
   char1 = Serial.read();
   char2 = Serial.read();
   char3 = Serial.read();
}

And not understand why they get something different than the three characters that the "other side" transmitted.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If stuff like that is a common need for the Arduino users, then the Arduino developers might be well off implementing something like

string = Serial.ReadString(numberOfCharactersExpected, timeout);

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If stuff like that is a common need for the Arduino users,

I think it is for beginners, but that's just my observation.

The timeout is already used on the pulseIn() function because that does block, so yes I think a set of similar functions for serial would be good.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A function serial.ext(Characters_in_buffer) might help with understanding.

Cheers,

Joey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to clarify, the Arduino provides a novice friendly library that, among other things, has some simple serial functions. However, there is absolutely nothing to prevent you from using printf() or any other standard C library function. The trick of course is knowing how to set up the standard output stream, which is hardly a novice friendly chore.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know sprintf() works so I just tried printf(), it compiles but I have no hardware to try it out on.

IIRC all you have to do is implement a version of putchar() to handle the platform-specific IO (I seem to recall doing that years ago on an embedded board), however I never see anyone using printf() so I would bet that hasn't been done.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

IIRC all you have to do is implement a version of putchar() to handle the platform-specific IO (I seem to recall doing that years ago on an embedded board), however I never see anyone using printf() so I would bet that hasn't been done.

http://www.nongnu.org/avr-libc/u...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm now a bit of an Arduino convert. It is by no means perfect, but I can well understand its popularity. Think of a common chip and there seems to be some arduino code for it. With all the threads we get with people struggling with lcd's, RTC's and tne cheapy 433MHz rf modules, there's examples on how to connect a drive these. The rf module one seems particularly good as it uses 4to6 bit encoding along with a crc check on the payload. Theres also an example using a enc28j60 ethernet chip. Whilst I'm no stranger to writing low level code, just being able to get something that hopefully works and having immediate success is always encouraging.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'm now a bit of an Arduino convert.
I was always an Arduino convert. I started with just one, and built quite a collection of different variants and sizes before I focused on the underlying AVR, then started building my own prototypes from the ground up. I still 'sketch' out an idea using one of my Aclones and a breadboard to see how it's likley to function before I start burning my fingers with the soldering iron :)

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

IIRC all you have to do is implement a version of putchar() to handle the platform-specific IO (I seem to recall doing that years ago on an embedded board), however I never see anyone using printf() so I would bet that hasn't been done.

I do it all the time. I use:

// Keep this in the same file as the usart_put_char function
FILE mystdout = FDEV_SETUP_STREAM(usart_put_char, NULL, _FDEV_SETUP_WRITE);

Smiley

[edit]
Didn't see Johan's post.
[/edit]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you do the FDEV thing do you just make a wrapper to serial.write() or specifically implement a usart_put_char that messes direct with UART registers?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you do the FDEV thing it provides printf() with the usart_put_char() to use eponymously*.

I wrote the usart_put_char() as part of a usart library.

I just finished up a library that does put a serial wrapper around it for novice use, sort of a transitional step from the Arduino serial.print() allow folks to access the underlying C code if they want to learn how the serial communication is done - next month's Nuts&Volts has the article, I think. I dump it all here one of these days.

Wait, um... what did you ask?

Smiley

*Yes, I too hate people who use words like eponymously.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone is eponymous when they give their name to an organisation, like Sinclair or Dell. I used to do quite a lot of freelance journalism, and once referred to Sinclair as the avuncular and formerly eponymous Sir Clive Sinclair after he sold his company to Amstrad. He used to be known as "Uncle" Clive.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

once referred to Sinclair as the avuncular and formerly eponymous Sir Clive Sinclair

Quote:

I used to do quite a lot

No causal relationship implied...

Cheers,

Joey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
Linux is all about 'we' and at least the Windows hardware is open and hackable.
Smiley

Well mostly. The problem is that a lot of Windows hardware is NOT open unless you pay $$$$ to buy in as a developer and sign your life away with NDA's. That's why there is no support for some hardware in Linux (at least not until the hardware in question is no longer cutting edge and some geek has had time to reverse engineer it).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You can see where by holding down "shift" when you compile with the "verify" button, or by setting build.verbose in the preferences.

I know this is an old thread but I now have Arduino 1.0 and it seems that holding [Shift] while clicking the Verify icon no longer shows the build output - have they removed this feature? I guess I'll just have to edit preferences.txt?

EDIT: Ok so preferences.txt no longer has build.verbose :-(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like you're right, there has to be some way of getting that info ?

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

Pages