Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reworked connections to 74*165s to put the sense pins #7

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

Reworked connections to 74*165s to put the sense pins #7

wants to merge 7 commits into from

Conversation

owendelong
Copy link
Contributor

This puts the sense pins on the 74*165 serial chips in an order closer to the position of the attached sensors and puts them in a rational order on the SIP resistors as well.

The layout out of the chips is:

16 15 14 13 12 11 10 9
      D  C  B  A
>
      E  F  G  H
1  2  3  4  5  6  7  8

This new schematic results in the SIP pack being connected as follows:

E F G H D C B A <COMMON>

This results in a left to right pin order on the resistor pack which is (e.g.)
1 Outside
1 Inside
2 Outside
2 Inside
3 Outside
3 Inside
4 Outside
4 Inside

(This is repeated for packs 5/6/7/8, 9/10/11/12, etc.)

Doing it this way made it possible to route the sense lines in a much more compact manner on the board which freed up space to place headers to connect servos.

@owendelong
Copy link
Contributor Author

I'll submit a second pull request with the board file when I finish routing the board. So far, I've routed everything left of column 12 (U4, U5, power, expansion connectors, micro controllers), All of the Servos, All of the CA/AN connections on the sensors, all of the 3v3 on the sensors, both power lines for the LED drive. I've got everything pretty well placed and it's just a matter of finishing the routing which is a bit of a slog, but mostly a copy of the left half of the board, so the hard work is done.

@owendelong
Copy link
Contributor Author

owendelong commented May 8, 2020 •
edited
Loading

Obviously, this new order will also require some reworking of the software. I'll do that after I finish routing the board.

@hydronics2
Copy link
Owner

hydronics2 commented May 8, 2020 via email

@owendelong
Copy link
Contributor Author

I haven't had a chance to examine the code yet, but I think it's just a matter of redefining which bits coming from the serial chips represent which sensors. I'm presuming there's some form of map defined in the software that just needs to be updated.

@hydronics2
Copy link
Owner

hydronics2 commented May 9, 2020 via email

@owendelong
Copy link
Contributor Author

DO NOT MERGE

I discovered that I hadn't reconnected several of the sensors yet. (OOPS!).

At this point, I'll push that correction at the same time as I push the fully routed board.

The software changes look like they'll be fairly straight forward and I'll work on them after I finish routing.

@owendelong
Finalized all connections on schematic (missed some sensors last comm…
6bd7241 
…it).

Fully routed board using new component names and new pinouts for SIP packs.
@owendelong
Copy link
Contributor Author

OK... This new commit includes a board and schematic.
They match. They pass DRC and ERC.

This uses the improved SIP layout described above, but it means that instead of being in the order 1I=A, 1O=B, 2I=C, 2O=D, 3I=E, 3O=F, 4I=G, 4O=H on the serial chips, the sensors are in the order 4I=A, 4O=B, 3I=C, 3O=D, 1O=E, 1I=F, 2O=G, 2I=H.

This will complicate the code slightly, but it makes the board layout a whole lot simpler. I'll work on the code next.

@owendelong
Copy link
Contributor Author

Now without using input-only pins for servo output.

owendelong added 2 commits May 11, 2020 02:02
@owendelong
Improvements to test_shift_registers.ino
0c68d7a 
Works with new serial pinout
Optimized code quite a bit, removed repetitive code.
Added ability to remap serial pinout by editing simple binary array.
Set up SPI reads to transfer all 6 octets in one call.
@owendelong
Improved clarity in documentation at beginning of file.
d58c3c1
@owendelong
Copy link
Contributor Author

OK... I want to checkpoint this with you before I go crazy with the other sketches...

Check out test_shift_registers.ino in this pull request and let me know what you think.

I created a simple map and some functions to use it for mapping sensor numbers to names and for retrieving the current and old values given a sensor number.

I also simplified the copy of the current data into the old data.

Most of these simplifications were achieved by switching from named variables to two arrays (sensors[] and o_sensors[]).

This is a fairly radical departure from your initial approach to the code, so I want to see how you feel about it before I do similar things to the other sketches.

@owendelong
Copy link
Contributor Author

Oh, and I switched some of your constants to compiler macros and made use of the predefined values in boards.txt to detect which hardware we are being compiled for.

@hydronics2
Copy link
Owner

hydronics2 commented May 11, 2020 via email

@owendelong
Copy link
Contributor Author

Cool... Yeah, I have no hardware yet and am probably more than 2 weeks from building any, so if someone can test it against real hardware and make sure I got the mapping right, that would be very useful.

@owendelong
Copy link
Contributor Author

I'll get to work on the other two sketches shortly.

@owendelong
Ported to new pin map
11c73db 
Optimized code similarly to previous efforts on test_shift_registers sketch
I believe there are other opportunities for optimization, but this took care of the low hanging fruit and is sufficient to work with the new hardware layout.
@owendelong
Copy link
Contributor Author

OK... I've uploaded a new version of bee_counting now as well.

When you have him test with his hardware, make sure he knows that the gate map isn't going to work right for his hardware.

I believe that if he replaces the gateman declaration with the following:

uint8_t gatemap[] = {
        0b00000001,     // Gate 0 (1I)
        0b00000010,     // Gate 1 (1O)
        0b00000100,     // Gate 2 (2I)
        0b00001000,     // Gate 3 (2O)
        0b00010000,     // Gate 4 (3I)
        0b00100000,     // Gate 5 (3O)
        0b01000000,     // Gate 6 (4I)
        0b10000000,     // Gate 7 (4O)
};

That should work with the unmodified schematic/PCB layout.

@owendelong
Copy link
Contributor Author

I believe this is now ready for merge, but I'm not sure what the best way to deal with the fact that the new code requires modification to be used with the old board.

@hydronics2
Copy link
Owner

hydronics2 commented May 12, 2020 via email

@owendelong
Copy link
Contributor Author

I am planning on building one, but I'd like to make sure that the new code works with the old hardware too.

So I've pushed a change which includes a definition for the board revision (I'm calling what I submitted "2", but we can easily change that to any value you prefer).

If the REV is defined as anything < 2, it uses the map that should work with the original board. If REV is >= 2, then it uses the map for the layout I created. In the version I pushed, I left REV defined as 1 so it should be compatible with existing boards.

@hydronics2
Copy link
Owner

hydronics2 commented May 13, 2020 via email

@owendelong
Copy link
Contributor Author

Also, when you get a chance, let me know what you think of my board solution to the resistor bypass. Basically, I put a couple of vias close to each other (one to the resistor pin and one on the power line from the MOSFET) with a "cream" area encompassing them. This should make it pretty quick and easy to solder bridge them (especially if you have paste solder and hot-air available) to bypass the SIP.

The board design also sports 5 headers for servos to operate "reducer" doors. My plan on the reducer doors is to arrange them to cover 12,6,3,2,1 entrances, respectively which enables the opening of any arbitrary number of entrance gates from 1 to 24.

It also includes holes for mounting possible hinge attachments (still thinking through the mechanical design for the reducer gates and actuators).

In general, I tried to make the layout as simple and consistent as possible. To that end, the bottom layer is mostly horizontal runs (power and ground busses, servo signals, etc.) and the top layer is mostly vertical connections (primarily 74*165 sense lines, IR LED power/ground connections, etc.

Things are a little busy at the end of the board where the micro controllers attach and I haven't added support for the servos to the code yet. The GPIO pins for the servos are not quite identical due to variations between the two micro controllers support for PWM, but were kept as similar as possible.

You should be able to view the board with Eagle free even if you can't make significant changes to it.

@hydronics2
Copy link
Owner

hydronics2 commented May 19, 2020 via email

@owendelong
Copy link
Contributor Author

owendelong commented May 19, 2020 via email

@bnfinet
Copy link

bnfinet commented Jun 2, 2020

hello @owendelong !

@hydronics2 and I have collaborated on this project on and off over the years. I'm currently working on getting an mqtt based server solution in place to be able to receive data from the counter and will be turning my attention to the bee counter esp32 code after that's setup (a few weeks more I hope). It's unfortunately a side project atm.

@hydronics2 and I were talking IRL (I know, crazy in this day an age) about board versioning. I think it would be helpful as new iterations of the board are created if version info could be detected by the software at startup.

These methods seem interesting, but I'm not a hardware nerd, I'm a software/devops/sysadmin type...
https://electronics.stackexchange.com/questions/371696/encoding-version-or-configuration-on-pcb

@owendelong @hydronics2 I'd love to hear your opinion on that. The goal is to support a diverse array of hardware from one codebase.

This might be good fodder for a separate issue and I'm happy to open up an issue and move this conversation there.

@owendelong
Copy link
Contributor Author

owendelong commented Jun 9, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@owendelong @hydronics2 @bnfinet