9N1 HardwareSerial support - develop for which branch?

[Bouni]

Hi,

i need a 9N1 serial connection for a vending machine that uses the MDB protocol. Unfortunately the current Arduino IDE (1.0.5) has no support for this mode.

I've found a Pull Request #1221 that has implemented 9N1 (and the other 9[E,O][1,2] modes, too) but has not yet been merged into the IDE.

I've tried to simply copy agalliazzo's HardwareSerial.* into my 1.0.5 installation, but then nothing works anymore! Possibly there has been to much changes between agalliazzo's pull request and 1.0.5!?

The pull request is about a year old and the IDE-1.5.x is in the pipe. I assume that the pull request never gets merged because the new IDE has a completely rebuilt Hardware Serial part.

My question is now simply: Does it make sense to wait for agalliazzo's pull request getting merged, or extend the new Hardware Serial of 1.5.x and submit my own pull request?

Or more generally, for which IDE should i write modifications/enhancements? 

[William "Chops" Westfield]

On Apr 8, 2014, at 3:42 AM, Bouni wrote:

> Does it make sense to wait for agalliazzo's pull request getting merged

I don't think that it is likely to ever get merged. The whole "I changed the write and read functions to accept and return an integer instead of byte" is absurdly expensive for the large majority of users who don't use 9bit characters.

WestfW

[Bouni]

Hi,

can you recommend another way of reading 9 Bit data?
reading 2 bytes instead of an integer for example or something like
that?

[Paul Stoffregen]

On 04/08/2014 11:07 AM, Bouni wrote:
> Hi,
>
> can you recommend another way of reading 9 Bit data?
> reading 2 bytes instead of an integer for example or something like that?

This issue came up for Teensy3 some time ago. A pretty good number of
people really need 9 bit support. Here's how I integrated it for
Teensy3. There's no guarantee Cristian will follow this approach for
Arduino, or ever support 9 bits at all.

First, 9 bit mode is NEVER enabled by default on Teensy3. It increases
the serial buffer sizes, which is very wasteful for the vast majority of
serial usage which deals with 8 or 7 bit data. Near the top of Teensy3's
HardwareSerial.h are these lines:

// uncomment to enable 9 bit formats
//#define SERIAL_9BIT_SUPPORT

This is the trade-off. 9 bit support is in the source, but you must
edit the core library HardwareSerial.h to enable it.

Later in HardwareSerial.h, the formats for Serial.begin(baud, format)
are conditionally defined:

#ifdef SERIAL_9BIT_SUPPORT
#define SERIAL_9N1 0x84
#define SERIAL_9E1 0x8E
#define SERIAL_9O1 0x8F
#endif

The idea is a sketch or library that needs 9 bits will fail to compile,
rather than verify & upload but fail to work, because SERIAL_9N1 isn't
defined. If a library or sketch author wants a friendly error, they can
do something like

#ifndef SERIAL_9N1
#error "You must edit HardwareSerial.h to enable 9 bit serial
#endif

Inside the actual serial code, of course SERIAL_9BIT_SUPPORT is used to
conditionally compile all the 9 bit stuff. The buffers double in size,
since 16 bits are used to hold the 9 bit data. Small chunks of extra
code are added in the interrupts to send and receive the 9th bit. When
it's not defined, there's absolutely no extra overhead for 9 bit mode.

API-wise, receiving 9 bits is easy, because Serial.read() already
returns int, where -1 indicates no data available, and 0-255 are for
real data. In 9 bit mode, 0-511 are used for real data. Easy!

But writing is the tough part, since the Arduino API is defined to write
8 bit data. On Teensy3, I added a write9bit() function. All the normal
write() and print() functions send data with the 9th bit clear. Only
this special Serial1.write9bit(data) function can set the 9th bit. That
works out fairly well, since 9 bit protocols set the 9th bit at the
beginning of a message, which is usually an address byte, but all the
real data is sent without the 9th bit set.

Pull request #1221 has many design decisions that I feel are, well,
terrible. There's no conditional compilation, so all programs are
burdened with extra overhead for 9 bit mode. At least the serial
buffers aren't increased, but instead malloc is used to allocate them,
which hides the buffers from the memory usage summary after compiling.
The write() function is changed to take a 16 bit input, which breaks
compatibility with the Print base class. I'd recommend rejecting and
closing #1221.

If 9 bit mode is ever accepted, I'd highly recommend making it
conditionally compiled, disabled by default, and create a write9bit()
function to allow sending data with the 9th bit set, so the rest of the
API remains intact.

[Matthijs Kooijman]

Hey Paul,

thanks for your detailed write-up! I'm not particularly interested in
9-bit mode myself, but having spent quite some time recently in the
HardwareSerial code, I think your proposal looks like the right way to
solve things. Just my €0.02 :-)

Gr.

Matthijs

[Massimo Banzi]

Paul

this sounds like a good approach. would it be possible to find a way
to enable the 9bit mode from within the sketch?

m

> --
> You received this message because you are subscribed to the Google Groups
> "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to developers+...@arduino.cc.



--
Massimo Banzi <m.b...@arduino.cc>

[Randall Routh]

Is there a way to enable the 9 bit support from within project environment?

I was thinking of putting a configuration file in the project directory called something like HardwareSerialConfig.h. 
You then put your
  "#define SERIAL_9BIT_SUPPORT"

in that file.

You would then include that file into HardwareSerial.h.

To prevent compile errors you would include the config file the core directory as well with all the default values.

The project directory would be place in the include search path for all compiles.

Therefore, you would not need to keep changing HardwareSerial.h for when you did or did not need 9 bit support.

Just a thought.

[Matthijs Kooijman]

(I've changed the subject, let's keep discussion in the main thread
about the serial implementation and keep this discussion here?)

Hey Randall,

> Is there a way to enable the 9 bit support from within project environment?
>
> I was thinking of putting a configuration file in the project directory
> called something like HardwareSerialConfig.h.
> You then put your
> "#define SERIAL_9BIT_SUPPORT"
> in that file.

This is not currently possible, but it seems to a wanted feature. There
has been some limited discussion and patches about this recently,

https://groups.google.com/a/arduino.cc/d/msg/developers/sIzspklcvQk/MzEDNeqApFgJ
https://groups.google.com/a/arduino.cc/forum/#!topic/developers/eG4o8TeiuAo
https://github.com/arduino/Arduino/issues/421
https://github.com/arduino/Arduino/pull/1808

I think there was at least one more thread or github issue about this,
but I can't find it right now.

I'm very much interested in implementing this, but I'm not so sure what
the best solution is. I haven't looked closely at #1808 yet, but I'm not
so sure that any solution based on include paths is really robust enough
(though they are mostly _simple_, which is a good feature in itself).
Anyway, no time to dig into this right now, just wanted to supply a bit
of context.

Gr.

Matthijs

[Brian Cook]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


For what it's worth I've been using variants with Tiny Core 2 to
implement build options. So far it was worked well.

- - Brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNEbeIACgkQvL/25DjR/vnyewCfdslMFU8wQ9nDzwzJS9g/BZYo
QxEAnjBholIhoU7m4SogL9fip164/YfC
=Gxba
-----END PGP SIGNATURE-----

[William "Chops" Westfield]

On Apr 8, 2014, at 1:07 PM, Massimo Banzi wrote:

> would it be possible to find a way to enable the 9bit mode from within the sketch?

Well, there's a long-standing and frequently-mentioned feature request to somehow pass compile-time options for the core from the users' sketch environment. That would make this sort of thing really easy.

WestfW

[Bouni]

Hi,

if this feature would be integrated, this would allow us to use much
more features of the AVR's without building up a lot of overhead for the
people who just need the "basic" features (i assume there are more
features like 9N1 in the AVR's that are not yet implemented for the same
reason). I would highly appreciate if someone with the knowledge could
develop such a feature!

Thanks for your great work so far!

[William "Chops" Westfield]

>> something like HardwareSerialConfig.h.

If you DO do something like this, I vote for a single file ("config-core.h" ?), rather than a config for each core sub-system…

WestfW

[Randall Routh]

I would agree with you but ...

Any issues that have been discussed with HardwareSerial would also apply to SoftSerial, how do you address third party libraries that have all the same sort of issues?

I would think ... maybe ... a "config" subdirectory and an include file with the same name as the library.  So the configuration header for the "Wire" library would be

"./conf/Wire.h" or "./conf/Wire_conf.h".

That's as much since as I can make before coffee.

On Wed, Apr 9, 2014 at 3:21 AM, William "Chops" Westfield <wes...@mac.com> wrote:

>> something like HardwareSerialConfig.h.

If you DO do something like this, I vote for a single file ("config-core.h" ?), rather than a config for each core sub-system...

WestfW

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--
Randall Routh
404-276-8373

[Paul Stoffregen]

Indeed, this subject has come up many, many times. Historically, David
has had strong concerns about doing this sort of thing, so hopefully
he'll comment.

Allowing sketches to override stuff in the core library, or the other
libraries, potentially adds tremendous flexibility but also complexity
to Arduino as a platform. The obvious gain is enabling features users
want. Another positive is relatively little/easy code or design is
needed in the IDE to make it happen.

But there are potentially serious possible downsides...

Depending on how it's implemented, this may expand the Arduino API from
fairly simple and easily understood functions (eg, the reference page)
to dependencies on special preprocessor macro names. This may or may
not be easy for novices to understand. It may or may not be feasible to
document. The more powerful and flexible the symbol overriding is, the
more opportunity it has to grow the Arduino API in terribly complicated
ways.

Also depending on how it's implemented, these new sketch-library
preprocessor dependencies may create platform-specific dependencies or
issues. Certainly 9 bit serial mode and buffer sizes seems fairly
platform agnostic. But if we're talking about .h files including into
each other in ways that allow directly overriding stuff within the core
library, it's almost certain to be used by novices or even experts with
little care for compatibility between different cores, boards, variants,
and so on. At a time when Arduino as a platform is rapidly expanding
from AVR-centric to AVR, ARM, Intel and others, this may be a step
backwards for compatibility.

I'm pretty sure other concerns have been expressed in the past.

I'd advise caution....

[Venkat Gmail]

Everyone, is there a thought to have an arduino beta or a arduino pro release that can stay nimble, and cutting edge. And use that experience feedback to feed changes to arduino standard platform.

The obvious advantage eliminates too much criticism from people wanting to move faster than current platform evolves. Downside is there as you might lose a highly productive ecosystem of developers focusing on the beta or pro.

Any thoughts ...

Venkat M. Reddy
venka...@gmail.com

[Tom Igoe]

I’d be against it, personally.

I think the result would be that too much development effort would go to the pro version, and not enough to the main branch, and the non-pro people would lose out.

t.

[Randall Routh]

It sounds like a good idea, but given the choice between a safe and simple basic version and powerful and complex pro version how many new users, even though they should, are going to pick the basic version.

For the same price do you pick MyWidget or MyWidget Pro?

[Peter Feerick]

I agree that it may be a bad idea as far as actual usability, but I think that Venkat's point may be more a 'bleeding-edge' version of arduino that allows for different ideas to be tested without affecting the mainstream version unless proven successful or worthwhile of implementation in the main line. As much as this might stimulate development of features, etc., I don't know how or if this would fit it in with the core teams work flow. 

Pete

Peter Feerick
BIT, BLDes CQU

0413 431 284

174 Cummins Rd
Bundaberg Q 4670

peter....@gmail.com
peter....@cqumail.com

On Thu, Apr 10, 2014 at 12:45 AM, Randall Routh <randal...@gmail.com> wrote:

It sounds like a good idea, but given the choice between a safe and simple basic version and powerful and complex pro version how many new users, even though they should, are going to pick the basic version.

For the same price do you pick MyWidget or MyWidget Pro?

--

[Tom Igoe]

Plenty of folks fork the repo for just this purpose, and I think that’s fine. As for the core team maintaining it, I’d put it lower on the priority list, personally. Right now, between maintenance of the main core and new product development, the core team  have a lot to manage for a small staff.

t.

[Bouni]

Hi,

i forked the repo as well for this purpose :-)

During the weekend I worked on a 9 bit modification for the existing
HardwareSerial that makes it as easy to use as any other mode and does
not require int size buffers. I simply use 2 bytes for storing the 9
bits instead of changing the buffer for all other modes to int.

This also deals in a nice way with the concern of Paul he mentioned
before:

> It increases the serial buffer sizes, which is very wasteful for the
> vast majority of serial usage which deals with 8 or 7 bit data.

I would really like if anybody of you could take a look at my
modifications before i file a pull request:
https://github.com/Bouni/Arduino/tree/hardware-serial-9bit

I've done a few tests so far:
- Send 9 bit as well as 8 bit data on a Arduino Leonardo and receive
them on the same port (USART1), verifying that they are equal.
- Send 9 bit as well as 8 bit data on a Arduino Mega2560 R3 and receive
them on the next port (USART0 -> USART1, USART2 -> USART3) and vice
versa, verifying that the received byte matches.
- For all the tests i've verified the sent bytes with a logic analyzer
(https://www.saleae.com/ ,Logic8 but the old version)

The only thing I'm not sure about is if i have to cli() and sei() while
reading 2 bytes from the buffer for merging them into an int!?

Please send some feedback what you think about my changes and if there
is a chance getting them merged into the master branch!

Best regards,

Elias

Am 11.04.2014 19:14, schrieb Tom Igoe:
> Plenty of folks fork the repo for just this purpose, and I think
> that's fine. As for the core team maintaining it, I'd put it lower on
> the priority list, personally. Right now, between maintenance of the
> main core and new product development, the core team have a lot to
> manage for a small staff.
>
> t.
>
> On Apr 11, 2014, at 5:51 PM, Peter Feerick <peter....@gmail.com>
> wrote:
>
>> I agree that it may be a bad idea as far as actual usability, but I
>> think that Venkat's point may be more a 'bleeding-edge' version of
>> arduino that allows for different ideas to be tested without
>> affecting the mainstream version unless proven successful or
>> worthwhile of implementation in the main line. As much as this might
>> stimulate development of features, etc., I don't know how or if this
>> would fit it in with the core teams work flow.
>>
>> Pete
>>
>> Peter Feerick

>> BIT, BLDes _CQU_

[Matthijs Kooijman]

Hi Elias,

> During the weekend I worked on a 9 bit modification for the existing
> HardwareSerial that makes it as easy to use as any other mode and
> does not require int size buffers. I simply use 2 bytes for storing
> the 9 bits instead of changing the buffer for all other modes to
> int.

That sounds like a better approach to me.

> I would really like if anybody of you could take a look at my
> modifications before i file a pull request:
> https://github.com/Bouni/Arduino/tree/hardware-serial-9bit

I've left some minor remarks in comments on the commits. I also have
some general remarks below.

> The only thing I'm not sure about is if i have to cli() and sei()
> while reading 2 bytes from the buffer for merging them into an int!?

I don't think this is needed. This is really needed only if you're
reading or writing a value in parallel (e.g., writing it in an ISR and
reading from the main loop or vice versa). In this case, the head of the
queue is only written to by the ISR and the tail of the queue is only
read by the main loop, so I don't think you'll need to disable
interrupts. However, I do think it's important to update the head and
tail pointers atomically (e.g. do the +2 in one go instead of in two
steps).


- Regarding the commits, I like that you've tried to provide clarity by
splitting things into separate commits. However, you've now grouped
changes based on where in the source code they occur (constructor
changes, ISR changes, etc.), which does not really make review of the
pullrequest or later review of the history easier. Also, this means
that after your first commit, the build is broken and it's not fixed
until your last commit.

A better approach is to group logical changes, like "Allow
configuring 9-bit operation" and "Handle 9-bit operation" in this
case (though a single commit for everything might even make more
sense for this case).

- I think it might be good to swap the bytes in the buffer, essentially
using a "big endian" notation. This means that the lower 8 bits are
stored in buffer[i], while the 9th bit is stored in buffer[i+1]. I
think this allows simplifying the code here and there (since you can
process buffer[i] as normal and then optionally process/write
buffer[i+1] as well. This should also make the atomicity thing
described above possible, I expect.

- Perhaps you could let read() call peek() to assemble the byte, that
might reduce the code size overhead a tiny bit (though register
saving might actually increase the overhead, so be sure to test).

- You've been working against the master branch, but there have been
some significant changes in HardwareSerial in ide-1.5.x. Since that
branch is intended to become the new master in a while, you should
base your changes on ide-1.5.x instead of master.

Thanks for diving into this!

Gr.

Matthijs

[Bouni]

Hi Matthijs,

Thanks a lot for this detailed reply!

I will try to change the code in this way and post an update here on the
list as soon as I'm ready.

>
> - Regarding the commits, I like that you've tried to provide clarity
> by
> splitting things into separate commits. However, you've now grouped
> changes based on where in the source code they occur (constructor
> changes, ISR changes, etc.), which does not really make review of
> the
> pullrequest or later review of the history easier. Also, this means
> that after your first commit, the build is broken and it's not fixed
> until your last commit.
>
> A better approach is to group logical changes, like "Allow
> configuring 9-bit operation" and "Handle 9-bit operation" in this
> case (though a single commit for everything might even make more
> sense for this case).

You caught me :) I did the changes and messed with my commits and tried
to fix that, but obvious not very well.
But that's the first i really use git in the way its meant, so i hope
you can forgive a novice :-)

> - I think it might be good to swap the bytes in the buffer,
> essentially
> using a "big endian" notation. This means that the lower 8 bits are
> stored in buffer[i], while the 9th bit is stored in buffer[i+1]. I
> think this allows simplifying the code here and there (since you can
> process buffer[i] as normal and then optionally process/write
> buffer[i+1] as well. This should also make the atomicity thing
> described above possible, I expect.

here is why i did it this way:
As mentioned in the AVR datasheet, i have to read the 9th bit before
reading the UDR register. So i decided to write the byte containing the
9th bit first to the buffer.
I can not see your point with little and big endian to be honest.
Am i correct that 0x100 in binary notation is:
0b00000001 0b00000000 -> little endian
0b00000000 0b10000000 -> big endian!?
For me little endian looks much more clear than big endian.

> - Perhaps you could let read() call peek() to assemble the byte, that
> might reduce the code size overhead a tiny bit (though register
> saving might actually increase the overhead, so be sure to test).

can you give a little bit more detailed explanation?

> - You've been working against the master branch, but there have been
> some significant changes in HardwareSerial in ide-1.5.x. Since that
> branch is intended to become the new master in a while, you should
> base your changes on ide-1.5.x instead of master.

I thought that this is going to happen, but i don't hesitate to write
the changes for both branches.
Is there a date when this is going to happen (or an estimation at
least)?

> Thanks for diving into this!

Thank you for helping me doing this!

> Gr.
>
> Matthijs

[Matthijs Kooijman]

Hi Elias,

> > A better approach is to group logical changes, like "Allow
> > configuring 9-bit operation" and "Handle 9-bit operation" in this
> > case (though a single commit for everything might even make more
> > sense for this case).
> You caught me :) I did the changes and messed with my commits and
> tried to fix that, but obvious not very well.
> But that's the first i really use git in the way its meant, so i
> hope you can forgive a novice :-)

No problem! If you're new to git, you might want to look into "git
rebase -i" and "git add -p", they're life savers if you want to produce
clean and logically separated commits :-)

> > - I think it might be good to swap the bytes in the buffer,
> > essentially using a "big endian" notation. This means that the
> > lower 8 bits are stored in buffer[i], while the 9th bit is stored
> > in buffer[i+1]. I think this allows simplifying the code here and
> > there (since you can process buffer[i] as normal and then
> > optionally process/write buffer[i+1] as well. This should also
> > make the atomicity thing described above possible, I expect.

Wait. I messed up here, you're already using big endian, I'm proposing
you switch to little-endian. Sorry for the confusion.

> here is why i did it this way: As mentioned in the AVR datasheet, i
> have to read the 9th bit before reading the UDR register. So i decided
> to write the byte containing the 9th bit first to the buffer.

Oh, right. Still, I think you could first (optionally) process
buffer[i+1] and then (unconditionally) process buffer[i].

> I can not see your point with little and big endian to be honest.
> Am i correct that 0x100 in binary notation is:
> 0b00000001 0b00000000 -> little endian
> 0b00000000 0b10000000 -> big endian!?

That's exactly reversed. "big endian" is the obvious one, little endian
is the tricky one.

> For me little endian looks much more clear than big endian.

Ok, so you really mean big endian here. Totally agreed, I usually prefer
big endian as well.

However, consider the case where you have two bytes of memory somewhere,
and use a uint16_t* pointer to access that memory. I'll get both the
upper and lower bytes this way. Now, if I use that same pointer, but
cast it to uint8_t*, in a little endian system I'll get the lower byte,
while a big endian system will give me the upper byte.

In a lot of cases, getting the lower byte is what you'd want (it also
matches things like casting a uint16_t value to uint8_t variable, for
example).

AFAIK, this is the main reason why little endian exists. In your code,
this is also the reason why using little endian would make sense:
buffer[i] will always contain the lower byte, regardless of wether there
is an upper byte or not, which can make the code shorter.

> > - Perhaps you could let read() call peek() to assemble the byte, that
> > might reduce the code size overhead a tiny bit (though register
> > saving might actually increase the overhead, so be sure to test).
> can you give a little bit more detailed explanation?

I mean something like this:

int read() {
if (head == tail)
return -1;

int res = peek();

if (/* use 9 bit */)
tail = (tail + 2) % SERIAL_BUFFER_SIZE;
else
tail = (tail + 1) % SERIAL_BUFFER_SIZE;
return res;
}

Does that help?

> > - You've been working against the master branch, but there have been
> > some significant changes in HardwareSerial in ide-1.5.x. Since that
> > branch is intended to become the new master in a while, you should
> > base your changes on ide-1.5.x instead of master.
> I thought that this is going to happen, but i don't hesitate to
> write the changes for both branches.

My previous change to HardwareSerial were only added to ide-1.5.x, so
I'm not sure if these (fairly intrusive) changes should be added to the
master branch. The Arduino devs should comment on this, though.

> Is there a date when this is going to happen (or an estimation at
> least)?

I'm not sure. A few months ago, the idea was "soon", but then the
library specification thing was revamped, so possibly that needs a bit
more testing now.

Gr.

Matthijs

[David Mellis]

I think that's a good summary, Paul. Also, by not having a way to provide compile-time constants from a sketch to the core / libraries, we force people to come up with alternative, more "Arduino-like" solutions to these issues -- which probably wouldn't happen if you could just hack in an #ifdef.

In general, I think it would make sense to have some way to do this if it were only used when there's no other option -- but I assume it would get abused. If we had an official way to build Arduino sketches with a makefile or external IDE, for example, it would probably make sense to provide custom compile-time options there. Or maybe even when using the Arduino IDE command line. But I think that putting it in the IDE would quickly create all the problems you mention.

--
You received this message because you are subscribed to the Google Groups "Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[William "Chops" Westfield]

On Apr 15, 2014, at 4:28 AM, Matthijs Kooijman wrote:

> if (/* use 9 bit */)
> tail = (tail + 2) % SERIAL_BUFFER_SIZE;
> else
> tail = (tail + 1) % SERIAL_BUFFER_SIZE;

You could save a lot of buffer space by using an "escape character" to indicate a character with the 9th bit set. It would probably simplify the patch as well.

if (_9bitmode && c == bit9IsOneEscape) {
/* get next c from fifo */
return c | 0x100;
}

(something similar in the ISR, and for the other direction, and a little extra code to handle the case when the character actually IS the escape character.)
This way, only characters that actually have the 9th bit set would occupy additional buffer space.

WestfW

[punam kalbande]

Hello guys,

  I am using arduino mega 2560 board with marlin firmware and want to change vendor ID and Product ID in it, How to set these things(serial number, vendor ID and Product ID) programmatically by firmware in EEPROM or is there any other way to change this things in firmware..???

Punam

[Bouni]

Hi William,

To me it seems that this makes the complete thing much more complex. I
think a obvious and readable version is better than a hacky piece of
code to save a little space in buffer.

Elias

[Matthijs Kooijman]

Hey Punam,

a good start would be to start a new mail if you need to ask an
unrelated question, instead of replying to a previous mail. Replying
makes the threading and history confusing (even if you change the
subject, there are hidden headers that link to the original mail!).

> I am using arduino mega 2560 board with marlin firmware and want to
> change vendor ID and Product ID in it, How to set these things(serial
> number, vendor ID and Product ID) programmatically by firmware in EEPROM or
> is there any other way to change this things in firmware..???

AFAIU, you'll have to change the firmware in the 16u2 / 8u2 chip that
does USB -> Serial conversion. See the "Programming" section here for
more info:

http://arduino.cc/en/Main/arduinoBoardMega2560

Gr.

Matthijs

[kowalski]

Seems like a lot of work and rippel effects to implement MDB. I checked the protocol and the 9th bit is used to indicated the address when package is sent from master and end of package when sent from slave. This logic could be achieved by sub-classing the hardware serial class. Please see Cosa UART and RS485 support for an example.

Cheers! Mikael

[punam kalbande]

hi Matthijs,

Sorry for this....

Again i have a question...

I have a little confusion with VID and PID.. I am using FT232R USB UART board and its VID/PID is 0403/6001, ok and i am using marlin firmware in that board. Is this firmware having any vid pid in its source code,..?? I have my v4 printer driver which contains VID and PID in inf file.
 Which VID and PID I should compare with  V4 Printer driver's VID & PID..??? i mean whether it firmware's vid/pid or boards vid/pid (i.e- 0403/6001)...????

-punam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlNOKjkACgkQz0nQ5oovr7xnOwCgzyOWjAsG6ssDlHT+IEwkSAWK
CtcAoKOiz592Qh/RSa2It+rxn2OmXLlB
=tv7Q
-----END PGP SIGNATURE-----

[Matthijs Kooijman]

Hi Punam,

> Again i have a question...
> I have a little confusion with VID and PID.. I am using FT232R USB UART
> board and its VID/PID is 0403/6001, ok and i am using marlin firmware in
> that board. Is this firmware having any vid pid in its source code,..?? I
> have my v4 printer driver which contains VID and PID in inf file.
> Which VID and PID I should compare with V4 Printer driver's VID &
> PID..??? i mean whether it firmware's vid/pid or boards vid/pid (i.e-
> 0403/6001)...????

I'm not sure I understand your question exactly, but let me explain
something, tell me if it answers your question.

Inside every USB device (usually within firmware, but sometimes also
hardcoded in the hardware), there is a vidpid. This is the vidpid that
the USB device sends to the PC when connecting ("enumerating") the USB
device. It basically says "Hi there, I'm 1234:4567".

The PC, then looks among its drivers if it has any driver that knows how
to talk to vidpid "1234:4567". This is where the .inf files come in -
they define the vidpids that a driver will try to talk to.

Note that in addition to the vidpid, an USB device also gives the USB
device a list of things (device classes, interfaces) it supports. Some
drivers on the PC don't care about the vidpid, but for example know how
to talk to all devices that support the "USB Mass Storage device class".
I don't think this applies to your question, but I wanted to mention it
for completeness.

Gr.

Matthijs

[punam kalbande]

Thanks Matthijs,

 I have cleared almost points related to it because of your this answer..Now again my same question is "Is it possible to change VID and PID  at the time of  uploading firmware in firmware's source code..??" 

-Punam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlNOMpEACgkQz0nQ5oovr7yBUQCg28q27l4SsD/cRwlaKlT/AxG8
F/EAoOFahk9UiowXSvtQwsRnrTi8FT/9
=u07U
-----END PGP SIGNATURE-----

[Matthijs Kooijman]

Hey Punam,

> answer..Now again my same question is "Is it possible to change VID and PID
> at the time of uploading firmware in firmware's source code..??"

Not when uploading, only when compiling the source code. See the earlier
link I sent you, which links to the firmware source code. In particular,
see:

https://github.com/arduino/Arduino/blob/master/hardware/arduino/firmwares/atmegaxxu2/arduino-usbserial/Descriptors.c#L68-L70
https://github.com/arduino/Arduino/blob/master/hardware/arduino/firmwares/atmegaxxu2/arduino-usbserial/makefile#L72
https://github.com/arduino/Arduino/blob/master/hardware/arduino/firmwares/atmegaxxu2/arduino-usbserial/Descriptors.c#L215-L227

(note that the PID set in the Makefile seems to be used only to set the
descriptor string, not the actual PID :-S)

Gr.

Matthijs

[punam kalbande]

Now i got your point..

Thanks

-punam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlNOOhoACgkQz0nQ5oovr7x3SgCeJNLhEEU6zehom9UXQnwCxhqh
uHoAoJOpBIs8CcyC2YFPB3thpeL+L1P2
=yQ+U
-----END PGP SIGNATURE-----

[punam kalbande]

Hey Matthijs,

 Flashing USB firmware means what..??? Is it same with uploading firmware into device..???

-Punam

[Matthijs Kooijman]

Hey Punam,

> Flashing USB firmware means what..??? Is it same with uploading firmware
> into device..???

The pages I linked talk about this using the "DFU bootloader", but I'm
not sure how that process works (I've never done it). I don't think I
can help you beyond this - you're certainly into very advanced
territory now...

Gr.

Matthijs

[Paul Duke]

Yes, it's the same. Flashing means uploading firmware into a devices flash memory.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAlNOnvcACgkQz0nQ5oovr7z0NwCdH4RvIPuNGi5QfJE0X1EqB+/q
9vIAoI6i9bYsz8hzYC4Y58DZpBthJE8Y
=V1CQ
-----END PGP SIGNATURE-----

[punam kalbande]

Thank you..

-Punam