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

[T.K]

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](< base_url >/applications/core/interface/file/attachment.php?id=4586)

[SN74HC165.pdf](< base_url >/applications/core/interface/file/attachment.php?id=4587)

[SN74HC595.pdf](< base_url >/applications/core/interface/file/attachment.php?id=5639)

[SN74HC165.pdf](< base_url >/applications/core/interface/file/attachment.php?id=5640)

[T.K]

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

[T.K]

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.

[T.K]

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..

[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.. 

[nILS]

I think stryd is refering

to the manually added

line breaks, that you

tend to add for no good

reason