DOUT pin numbers swapped for each SR

[This N°9]

hi all,

I have a strange problem (or question) concerning the pin-numbering

of DOUT's.

I builded a testing board to test IO pins. The DIN works fine, PIN-numbering as expected.

I use 10wire ribbon cables and DIL headers with smashTV's PCB's, one DIN and one DOUT

board are connected to the core.

I wrote a simple program that just displays the DIN-pin (pressed button) and switches

the pin with the same number DOUT. The strange thing is, that the DOUT registers

seem to have swapped LSB/MSB:

DOUT 0 -> DOUT 7

DOUT 1 -> DOUT 6

..

DOUT 7 -> DOUT 1

..

DOUT 8 -> DOUT 15

..

DOUT 15 -> DOUT 8

I checked the wiring back and forth, even checked

the datasheet of the stuffed registers (SN74HC595N),

where the outputs are numbered A-H, and the forward

output is H'. nothing explains this behaviour. my only

explanation is, that the registers seem to assign the

bits from H-A, not to A-H, which looks very strange to

me.

has somebody experienced something similar? or any

explanation? I could handle this in software, but

I would like to know what is going down there.

wiring is:

LED 0 -> J3::D0

LED 1 -> J3::D1

...

LED 8 -> J4::D0

etc.

DIN::J1 -> DOUT::J1 -> CORE::J8/J9 (10wire ribbon cable, DIL headers)

thanks in advance,

this

[cimo]

74hc165 and 74hc595 have a different I/Os pinout

iirc:

DIN - DOUT

0    -  0

1    -  1

2    -  2

3    -  3

4    -  7

5    -  6

6    -  5

7    -  4

but i am not sure atm, i ll check it out

Simone

EDIT: sorry i see you have smashtv boards where you can see the pins numbering, just ignore my posting

EDIT2: sorry again (at least for being so imprecise) but now i reckon something, when i built my first board with douts and the pinout of the DOUT was not consistent so that it looked like this:

DOUT - DOUT

(ICpins)-(MIOSpins)

0    -  0

1    -  1

2    -  2

3    -  3

4    -  7

5    -  6

6    -  5

7    -  4

[TK.]

Thats normal - while DINs are scanned in backward direction (last bit received last), DOUTs are scanned in forward direction (last bit sent first).

Therefore the bit correlation is swapped on DOUTs.

If you would follow the programmers section, you would know, that I was close to decide to change the order in MIOS32:

http://www.midibox.org/forum/index.php/topic,12141.msg100435.html#msg100435

But finally decided to keep it compatible with PIC based MIOS, as most application would have to reverse the pins anyhow - e.g. to transfer DIN register values to DOUT register values:

http://www.midibox.org/forum/index.php/topic,12141.msg101954.html#msg101954

Best Regards, Thorsten.

[cimo]

thanks TK

i was trying to find an old thread where you were clarifying that to me, but couldn t find it.

[This N°9]

Thats normal - while DINs are scanned in backward direction (last bit received last), DOUTs are scanned in forward direction (last bit sent first).

I'am glad to read this.

I now had a look at the datasheets of the SN74HC165 / 595, to get clear what is

happening on hardware and software level (maybe someone else finds this info usefull):

in the sheets the IN/OUT pins are A-H, this reflects D0-D7 (smashTV boards / circuit layouts), O 0-O7 / I0-I7 (circuit layouts)

DIN chain hardware-level: CORE <- R1::qH <- R1::H <- R1 <- R1::G ..... R2::qH <- R2::H etc.

so the first bit read is DIN1::I7, I suppose this goes to the MSB on software level.

DOUT chain hardware-level: CORE -> R1::SER -> R1::A -> R1::B -> R1::C ..... R2::SER -> R2::A etc.

so the first bit pushed out goes to DOUTlast::D7, the last pushed bit goes to DOUT1::D0

what I don't understand is what is happening on software level. Suppose the Byte is pushed out

LSB -> MSB (right to left), and the input stream goes to MSB - > LSB (left to right)?

...(last bit received last).... (last bit sent first)...

..and PIN 0 is always reflected @LSB (SRGet/SRSet)?

Quite confusing. If somebody can give me the answers, I will put this infos to

a table that gives a clear overview for others with the same questions.

I attached the two datasheets.

SN74HC595.pdf

SN74HC165.pdf

SN74HC595.pdf

SN74HC165.pdf

[TK.]

There is a DIN/DOUT table in the wiki - I would propose to improve it

Best Regards, Thorsten.

[This N°9]

ok, I'll do this update on the wiki.

@TK

just for my understanding: what you do on software level is that you have

all the bytes in a array from 0 to x and push them out from LSB x to MSB 0,

and you read them (DIN) from MSB 0 to LSB x, right? this makes sense

in view of the resulting swap-effect.

what I was missing was a fat hint on this effect, for example on the very entry

page of the DOUT module. I built the hardware before I could test it (missing plugs),

and so I now had to change all the wiring to correct the effect.

I'll do this info update on the wiki, and maybe if it's done someone who has write

access adds a good visible hint on the DOUT page on ucapps.de.

thanks for the help,

this

[TK.]

just for my understanding: what you do on software level is that you have

all the bytes in a array from 0 to x and push them out from LSB x to MSB 0,

and you read them (DIN) from MSB 0 to LSB x, right? this makes sense

in view of the resulting swap-effect.

Yes - and it's an intented "effect" to simplify the handling at application side.

Simple example:

   MIOS_DOUT_SRSet(0, MIOS_DIN_SRGet(0));

works without reversing the pin positions.

and maybe if it's done someone who has write

access adds a good visible hint on the DOUT page on ucapps.de.

Please give me a phrasing which is good enough, so that nobody who creates an own PCB overlooks the reversed DOUT pin mapping. I will insert it into the schematics.

Best Regards, Thorsten.

[This N°9]

Yes - and it's an intented "effect" to simplify the handling at application side.

ok, I understand. It makes sense to have the MSB represent the highest PIN value on both DIN and DOUT.

But if the bits would be pushed out left-to-right (MSB first) instead of right-to-left, the SR 0 would be the last register in the chain physically.

This way the D0 - D7 taging would match the pin-number on software side, also the MSB-LSB story and the

order of the bytes in the array would stay the same. J3 - J6 on the schematics/boards do not imply so strong

that this reflects the order of the single registers on software level, and plugs are changed more quickly than single wires.

I think the IC's have this setup because one normally sends data left-to-right and also receives it left to right

(sending the first bit/byte of a file first, and also receive it first).

sorry to be so picky, it's just a proposition. compatibility problems: maybe a MIOS-flag for the

orientation of the push-out?

Please give me a phrasing which is good enough, so that nobody who creates an own PCB overlooks the reversed DOUT pin mapping. I will insert it into the schematics.

ok, as soon as I have some time I'll do this. right now I'am occupied with the MIDI-mapper

hardware/software. I'll document this project anyway, so I'll do the DIN/DOUT table update

then.

[TK.]

sorry to be so picky, it's just a proposition. compatibility problems: maybe a MIOS-flag for the

orientation of the push-out?

There are 4 possible ways to handle the shifting (SR bit orientation, SR chain orientation), ca. 8 years ago I selected one which matches best with my own MIDIbox HW, meanwhile 1000s of MIDIboxes exist which are using correct DOUT wiring. Now you request a software flag for more flexibility as a workaround for incorrect wiring at your side. The software flag would affect the performance of all existing MIDIboxes. And it would lead to a higher memory consumption of MIOS, so that other features would have to be removed (as MIOS already allocates most of the "system" area in flash).

Instead, I would propose one of following solutions:

• fix your DOUT wiring and help to improve documentation
  
• modify the bit order in mios_srio.inc and build your private MIOS version, so that no HW change is required
  
• add the flexibility inside your application - it's the most simple solution for both - programmers and users - and it doesn't waste memory at MIOS side (which is very very limited - I can't repeat this often enough. Fortunately it has been relaxed dramatically with the MIOS32 approach (-> modular kernel) - but please don't mix the new possibilities with the old PIC MIOS approach (-> static kernel)!)
  

Best Regards, Thorsten.

P.S.: the disadvantage of your idea: DOUT SR assignments have to be adapted whenever the number of SRs in the chain is changed via MIOS_SRIO_NumberSet() - this doesn't really make sense.

[This N°9]

fix your DOUT wiring and help to improve documentation

my wiring is already fixed. I'll do the doc improvement when I finished

the midi-mapper and write documentation to it.

Now you request a software flag for more flexibility as a workaround for incorrect wiring at your side.

no, I don't request a flag for my private use. It was just a proposition to avoid others running into the same

confusion, it was more a proposition for the new ARM based MIOS.

P.S.: the disadvantage of your idea: DOUT SR assignments have to be adapted whenever the number of SRs in the chain is changed via MIOS_SRIO_NumberSet() -

ok, this is a strong argument. I give up :-)

besides, I don't want to fall on your nerves..

thanks for help & info,

this

[doc]

besides, I don't want to fall on your nerves..

:D :D

[This N°9]

What's this "real life" everybody is talking about? ... and where can I download it?

I propose this one (german):

http://www.reset.ch/

[nILS]

http://www.dasinternetabschalten.de

:-)

[This N°9]

ok, now I updated the DIN / DOUT pin table on the wiki:

http://www.midibox.org/dokuwiki/doku.php?id=din_dout_pintable

@TK:

Please give me a phrasing which is good enough, so that nobody who creates an own PCB overlooks the reversed DOUT pin mapping. I will insert it into the schematics.

I propose this one:

"Please Note: in contrast to DIN boards, hardware pins are swapped for each SR.

Pin D7/O7 reflects the lowest, D0/O0 the highest software-pin-value for each SR."

[stryd_one]

Excellent work, this :)

Just, next time... use the preview button before saving, so there aren't 9 saves in the revision history ;)

[This N°9]

Just, next time... use the preview button before saving, so there aren't 9 saves in the revision history

yes, I know.. this is because the table got kind of "radioactive", means it looked

different every time I looked at it.. the spacer lines had not as many cells as the

content lines. anyway, I removed the spacer lines totally now, because the SR num

gives enough visible structure to the table.

second I mixed up DOUT's DIN's on the first revisions, and had to correct that afterwards  :)

[stryd_one]

the spacer lines had not as many cells as the

content lines. anyway, I removed the spacer lines totally now,

Don't forget the playground area when you're playing with unfamiliar syntax.

Why are you still doing that annoying trimming with your text?

[This N°9]

Why are you still doing that annoying trimming with your text?

please be more specific

Don't forget the playground area when you're playing with unfamiliar syntax.

I can't forget what I don't know..  ;) just found it..

besides this was not a not-knowing-the-syntax-related thing. check the difference:

||||||

|||||||

it's not a nuclear reactor, it's just a wiki..  :D

[nILS]

I think stryd is refering

to the manually added

line breaks, that you

tend to add for no good

reason ;-)

[stryd_one]

please be more specific

Compare this:

Your posts have the ends of the lines

cut off so that the paragraph does

not reach the end of the text box

and scroll to the next line like it

should

it makes it difficult to quote you because

i have to delete the unnecessary line

returns

to this:

Your posts have the ends of the lines cut off so that the paragraph does not reach the end of the text box and scroll to the next line like it should

it makes it difficult to quote you because i have to delete the unnecessary line returns

I can't forget what I don't know..  ;) just found it..

It's linked at the top of the page when you edit ;)

besides this was not a not-knowing-the-syntax-related thing

Actually, it is - the tables are supposed to behave that way. Have a play in the playground, You'll see it

You don't have to add all those spaces in there. The column will fit the longest entry, which in this case, is the header of the column. I've fixed that for you, you may want to tidy up a little more.

While I'm at it, you've commited the cardinal sin of wiki doco today - updated a page without checking for dupes.

http://www.midibox.org/dokuwiki/doku.php?id=dout_module&do=backlink

Fix those backlinks

Or... better still, get rid of this strangely named page,

http://www.midibox.org/dokuwiki/doku.php?id=dout_module_digital_output

put it's content on the dout_module page, and don't forget to fix the backlinks to the removed page

Orr... even better than all those..... don't work on old wiki doco - get involved in the overhaul, make your edits in the new pages.

it's not a nuclear reactor, it's just a wiki..  :D

Still can be confusing though :)

[This N°9]

While I'm at it, you've commited the cardinal sin of wiki doco today - updated a page without checking for dupes.

hm... ok, to be honest, I never worked with docuwiki before, so before I screw it up even more: how did this happen? I can only remember that I

- edited the page "din_dout_pintable"

- added a comment to "dout_module"

how and when did I create "dout_module_digital_output"  ??? tell me a bit more about dupes.

Orr... even better than all those..... don't work on old wiki doco - get involved in the overhaul, make your edits in the new pages.

I must

have

missed

this.

where?

besides, the strange random table-loosing-border behaviour seem to be a result of empty rows (<tr></tr>) generated. I will try to remove them on my next try.

[This N°9]

I think this dupe story was not my fault, some "moebius" seems to have created this page:

2006/05/01 15:16 Show differences to current revisions dout_module_digital_output – created moebius

[This N°9]

ok, I'am fixing the stuff, but I found other (old) sind, for ex. on the page index_test, which links back to the dout_module_digital_out - page:

* [[LCD Module (Liquid Crystal Display)|LCD Module]] - Liquid Crystal Display

* [[AOUT Module (Analog Out)|AOUT Module]] - Analog Out to output Voltages (for Controls)

looks like the other link on page "mbhp", THIS is a bad sytax!

I don't like to be blamed for stuff that other before me screwed up!!  :)

UPDATE: also fixed links / dupes for aout_module_analog_out -> aout_module; on mbhp, LCD-link-to-nowhere -> lcd

[This N°9]

guess I found the door to the new wiki:

http://www.midibox.org/dokuwiki/doku.php?id=new_wiki_layout