I've not even properly proof-read this, but I only just got finished
with formatting. I expect to send a final copy to Seeed tomorrow
evening for printing. It will be published in booklet form as an A6
sized book.
There are still three graphics missing, but I expect Seeed will get
them to me in the next day.
Please review and comment.
Cheers,
g.
This board is used for test LS for hikey at initial, but now we found it is also a good board for learning IO control. So if many people like it, I can ask LeMaker RD team to make more for open sale.
BR
Tony Zhang
Making Innovation Easy
LeMaker Team -- The Professional Makers for Hardware and Software Customization.
Address:Room 501, Building 17, Maker Town of University Town, No.1201 Liuxian Avenue, Nanshan District, Shenzhen, China
Post Code: 518000
Email:
support(a)lemaker.org(Technical Support)
product(a)lemaker.org(Product Distribution)
http://www.lemaker.org/
原始邮件
发件人:Grant Likelygrant.likely(a)secretlab.ca
收件人:tony.zhangtony.zhang@lemaker.org
抄送:mezzaninemezzanine@lists.96boards.org
发送时间:2015年12月15日(周二) 08:18
主题:Re: [Mezzanine] 96Boards LED mezzanine board with USB debug port
Very cool. Looks like a fun board. Are you planning to make this board available for sale? g. On Mon, Dec 14, 2015 at 11:33 AM, tony.zhang tony.zhang(a)lemaker.org wrote: Dear all, We have designed a led board with all the LS GPIO connect to the different LEDs on the board. And also we have a usb debug port on th led board. This board can be used for study the IO control and also so some simple led experiment. Here is the link of the documents in the google drive: https://drive.google.com/file/d/0BwWMLqyfoBdaclNfTy1QdVM2ZWc/view?usp=shari… I hope know if anyone have insterest on this. BR Tony Zhang Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address:Room 501, Building 17, Maker Town of University Town, No.1201 Liuxian Avenue, Nanshan District, Shenzhen, China Post Code: 518000 Email: support(a)lemaker.org (Technical Support) product(a)lemaker.org (Product Distribution) http://www.lemaker.org/ _______________________________________________ Mezzanine mailing list Mezzanine(a)lists.96boards.org https://lists.96boards.org/mailman/listinfo/mezzanine
Dear all,
We have designed a led board with all the LS GPIO connect to the different LEDs on the board. And also we have a usb debug port on th led board.
This board can be used for study the IO control and also so some simple led experiment.
Here is the link of the documents in the google drive:
https://drive.google.com/file/d/0BwWMLqyfoBdaclNfTy1QdVM2ZWc/view?usp=shari…
I hope know if anyone have insterest on this.
BR
Tony Zhang
Making Innovation Easy
LeMaker Team -- The Professional Makers for Hardware and Software Customization.
Address:Room 501, Building 17, Maker Town of University Town, No.1201 Liuxian Avenue, Nanshan District, Shenzhen, China
Post Code: 518000
Email:
support(a)lemaker.org(Technical Support)
product(a)lemaker.org(Product Distribution)
http://www.lemaker.org/
I just made the following change to the Rev C schematic after someone
blew up their board by connecting the Sensors board off-by-one.
However, I'm not entirely sure if it is a good idea. Full description
below, but the jist is I disconnected pin 40 from GND to prevent +12V
getting shorted to +5V. There are three other GND pins on the
connector, pin 1, 2 & 39. Do you think having one GND pin on the right
hand side of the connector provide a sufficient ground connection?
g.
Change description:
Protect baseboard if Sensors board is installed incorrectly
Disconnect pins 36 (PWR_IN) and 40 (GND) to protect the baseboard if P1
gets installed off-by-one. Keeping PWR_IN pins 36 and 38 tied together
will short +12V directly to GPIO_L (34) or GND (40) if the connector was
off by one. Having pin 40 attached to GND would cause +12V to be shorted
directly to the +5V rail. To protect the baseboard, remove these direct
connections. Using only one PWR_IN pin is more than sufficient for this
board because it isn't used for anything. There are also three other GND
pins on the connector rated at 2A each. Dropping one should not be an
issue.
These changes don't guarantee to protect the baseboard. 5V would still
get shunted to the 1.8V rail which may still destroy the board, but
there is at least a fighting chance of not frying something.
Things would be so much better if we had a keyed connector
Signed-off-by: Grant Likely <grant.likely(a)linaro.org>
[cc'ing mezzanine mailing list. As much as possible, we should be
discussing these things in public forums]
Hi Sophie. Good work. Comments below.
On Wed, Nov 25, 2015 at 10:15 AM, Sophie Haynes
<sophie.haynes(a)linaro.org> wrote:
> Morning Grant!
>
> So, I had a bit of a nightmare with KiCad the past week (Libraries not being
> visible, PCBnew being unable to read the netlist, footprints not showing)
> but it all seems to be working now. The problems seemed to be caused by me
> stripping back an old template and hashing it to work for me (worried this
> may be an issue with people using my git project if the rename it?).
Might be. You'll need to experiment with clean installs to see if it
causes a problem
> Anyway, I've pushed the project to github
> (https://github.com/sophie-haynes/96boards-mezzanine-project-template.git).
> If you have a moment, would you be able to look over the schematic? Still
> not 100% sure if it's correct electronically?
This is good work. I've got lots of comments, but don't let that
discourage you. It's to be expected at this stage of a new project.
Comments on the project:
- The way most people will use this repository is they will go into
their KiCad templates directory ($HOME/kicad/templates) (which may
already contain templates for other projects) and do a "git clone
<url>" to get the template files. You need to make sure the project is
set up to support that. Right now I think the files are two levels too
deep. Move all files up so they are at the root of the directory and
it should work correctly. (You'll need to experiment though).
I found an example of a Raspberry Pi template that looks like a good
example to follow:
https://github.com/xesscorp/RPi_Hat_Template
- The project needs a license. Since we want anyone to use this
without restriction, I want to use BSD. Create a COPYING file at the
root of the directory tree containing the BSD 2-clause license:
http://choosealicense.com/licenses/bsd-2-clause/
- Copyright also needs to be specified. The readme file can list your
name as the author, but the copyright is held by Linaro, Inc. (Your
contract assigns all of your Linaro work to the company)
- Remove the specification pdf. Instead, put a link to the CE spec in
the README file. Including the specification messes anyone cloning the
project into their templates directory.
- Ask Shovan for a 64x64 png of the 96Boards Logo to put into the meta
directory as icon.png.
- I saw something in the KiCad manual about string replacement rules
when creating a project from a template, but I couldn't find out what
they are. It might be that there is something there that will fix your
library problems. Alternately, it might be that if you change the
libraries to something other than "mezza.*" that kicad will stop
renaming them and make everything work. Again, you'll need to
experiment.
Comments on the schematic:
- I would drop the second expansion connector footprint. Just use one
and we'll switch the design to using the through-hole stackable
connector that I'm using on the new Sensors board. That will make
things simpler.
- Add labels for every signal on the expansion connector, not just the
ones that are currently in use. It will make it convenient for anyone
starting a new project.
- If you flip the USB connector vertically then the shell pins will be
on the left and the data signals on the right. That will make the
schematic cleaner, and it is what the other mezzanine schematics look
like. That way the USB+/- and VBUS signals can go straight into U2
without looping around.
- +1V8 needs to be split into two separate power rails. +1V8 is
supplied by the expansion connector, but the USB FTDI device needs to
be powered independently. Create a +1V8F rail specifically for the
FTDI.
- Similarly, rename the +3V3 rail to +3V3F because it is specific to
the FTDI chip. That leaves the +3V3 signal available if someone wants
a 3.3V rail powered by the expansion connector. Rename +3V3_FTDI to
+3V3F also. (I'm suggesting to use F instead of _FTDI simply because
that's the terminology we've used on the Sensors schematic. It's not a
big deal, but consistency is nice)
- The regulator needs to be swapped out. The CJT1117-3.3 is a 3.3V
regulator, but you want to regulate down to 1.8V. There is a XC6206
regulator on the Sensors board schematic that you can use. If fact,
looking at the Sensors design is a good guide for what the schematic
should look like.
https://github.com/96boards/96boards-sensors
- Rename "GPIO-A" to "GPIO_A" (underscore instead of dash). Every
other signal is using the underscore as a separator.
- Drop the level shifter from the schematic for now. We'll talk about
adding it back later.
- Wire the FTDI up to UART1 instead of UART0. You don't need to
connect the RTS/CTS signals.
- Add a couple of LEDs to CBUS0 and CBUS1 for TX/RX indications
- Add a LED to each of the power rails. People like lights. :-)
- Insert 220R resistors between CBUS2/3 and PWR_BTN/RST_BTN. This
gives a bit of protection to the baseboard in the case of something
driving the line when it shouldn't.
Comments on the layout:
- Move the USB connector to the exact same position as it is on the
Sensors board.
- If you're not laying out traces to the components (except for
connectors) then delete them from the project entirely. There isn't
much value in placing them without traces.
Phew. That looks like a lot, but it is just a lot of little details.
When you're finished, we'll need a blog post to publicize the template
a bit and also document it on the 96boards website.
> Also, is there anything you need me to do in regards to the debugging of the
> grove board? I was thinking of doing a little post on our findings.
Not just yet. I've got other investigation I need to do. I'd like to
have a better resolution before doing another post, but I would like
to co-author something with you when I'm done.
g.
Second posting. I've made some changes to the design. Things to note:
- VIO is selectable between 3.3V and 5V with a slider switch
- A through-hole stackable header is used
- silkscreen is cleaner
I think that covers all the outstanding comments. Attached are the
schematic, design files, and a rendering.
Comments welcome. I hope to send this for a pre-production run next week.
g.
[image: Inline image 1]
Hi all,
(This got interesting enough that I ended up also making it a blog post
here: http://www.secretlab.ca/archives/164)
I've made some progress on the i2c issues seen with the sensors board. I
hooked up a pca9306 level shifter and compared the behaviour on the sensors
board using an oscilloscope. All of this testing is done with Seeed's Grove
RGB LCD module. The LCD module is useful because it actually has 2 i2c
devices embedded in it, the LCD controller at address 0x3e, and the RGB
controller at 0x62. The two devices operate independently with different
electrical properties.
On Hikey+sensors (TXS0108) the LCD locks the bus, and RGB will work, but
only after pulling the ribbon cable apart to reduce crosstalk due to
insufficient pullups
On Hikey+pca9306 the LCD isn't detected and the RGB works correctly
(undetermined if there are crosstalk issues)
The traces below show both sides of the level shifter. Green and blue on
the top for the data line. Orange and purple on the bottom with the clock.
First, what I saw on using Hikey+pca9306+RGB:
[image: Inline image 1]
And with the LCD:
[image: Inline image 2]
In both traces you can see the start condition (data goes low while clock
is high), the 7 bits of address (7 rising clock edges), the R/W bit (1
rising clock), and then the acknowledgement bit driven by the device. If
the controller doesn't see the device drive the data line low on the 9th
clock, then it decides the device isn't there and it terminates the
transaction. It is easy to recognize the ack bit because the device has a
different drive strength and the voltage level is different.
The RGB controller is a happy little device and it jumps at the chance to
drive the data line low. It goes right down pretty close to 0V. The LCD on
the other hand is sulky and doesn't drive the line quite as low as the
controller can. About to 1V. 1V is probably recognized as a logic low on a
5V device, but with 1.8V it is not even less than half. The way the pca9306
level shifter works is there are pull-up resistors on either side of the
device that draws each side up to its respective high level. In this case,
1.8V and 5V. When either side gets driven low, the level shifter begins to
conduct and the other side also gets drawn down to the same voltage, but it
can only go as low as the voltage it is driven to. If it only gets driven
down to 1V, then it will never get low enough for a 1.8V controller to
recognize it as a low state.
It may be that with weaker pull-ups the LCD will be able to drive to a
lower voltage level. I'll need to experiment more, but in the mean time
let's move onto the Sensors board. Back to the traces:
First, here is a transaction to address 0x63 with no device present:
[image: Inline image 3]
Looks perfectly normal so far. Next, the RGB device at address 0x62:
[image: Inline image 4]
Also behaving the same way as it did with the pca9306. Finally, an LCD
transaction:
[image: Inline image 5]
Again we see the start condition, the 7 data bits and 1 r/w bit, but the
ack bit looks weird. The LCD successfully drives the data bit low enough to
be recognized, but then something weird happens. The data line stays low
and the clock stops running. I don't know actually know what is happening
here, but I've got my suspicions. The LCD is continuing to drive the data
line low, (you can tell by the slightly different voltage level) but
keeping data low should not stop the clock. I suspect the txs0108 is
getting confused and driving the clock line high. I've come across reports
from others having trouble with the txs010x series on i2c. It has
'one-shot' accelerators to reduce rise time by driving the line high.
Now I need to decide what to do next. Rev B of the design is ready, but
there is still the i2c issue that needs to be solved. I may need to put the
pca9306 parts into the design which will require some more rework before it
goes to manufacturing.
g.
On Tue, Oct 20, 2015 at 9:11 PM, David Mandala <david.mandala(a)linaro.org> wrote:
> Grant,
>
> Nice work. :-D Comments below.
>
> David
>
> On 10/20/15 2:28 PM, Grant Likely wrote:
>>
>> I've completed rework, layout and routing of the Rev B Sensors board,
>> and it is now ready for review. I've attached the new schematic and
>> new component placement diagram. The design files have been pushed out
>> to the "rev-b" branch on github and git.linaro.org:
>>
>>
>> https://git.linaro.org/people/grant.likely/96boards-sensors.git/shortlog/re…
>>
>> It is ready for review, and very close to being ready for
>> manufacturing. However, I have some questions that I would like some
>> feedback on. Help and suggestions are greatly appreciated.
>>
>> First, here are the things to notice on the new design:
>> - Arduino connectors have been centered and lined up on the bottom edge
>>
>> of the board, including the SPI header. This should make it compatible
>> with more Arduino shields
>> - More grove connectors have been added as well as more 96B IO.
>> - Bottom edge uses right-angle SMD grove connectors to avoid
>> shorting against the USB ports on the baseboard.
>> - GPIO A-F are all level shifted
>> - SPI has been brought out to P7
>> - Arduino Grove connectors match naming convention of Arduino Grove
>> shield (D3-D7, A0-A2, I2C). The Arduino Grove examples should now work
>> without any changes.
>> - Grove connectors are evenly spaced on either side of the Arduino headers
>> - A CBUS connector has been added for 1.8V IO controlled from the USB
>> port. This will be an undocumented feature allowing the FTDI to be
>> used to control boot select pins on the base board, but requires the
>> signals to be manually wired up (hence I'm not going to document it -
>> It will just cause confusion)
>> - J1 added to support manufacturing test. It allows the Arduino to be
>> reset from the FTDI
>> - I2C0 & I2C1 have stronger pull-ups on the data and clock lines.
>>
>> Questions:
>> 1) Are the Grove connectors too close together. I tried to give lots
>> of space so that labels can be easily read, but there isn't much room
>> between the mounting holes. I could have more space if I dropped two
>> Grove connectors and put more space between P14,P15,P17 and
>> P11,P10,P9.
>
>
> Space wise it looks good just as it is. All of my grove cables fit
> internally to the connectors, and I can read the labels with no issues.
Okay. I'll go with it.
>> 2) The LS expansion connector is currently an SMD pin header on the
>> bottom side. Seeed has sourced a through-hole stackable connector that
>> I could use instead
>>
>> Q: Is it worth replacing the SMD pin header with a 2x40 stackable header?
>
>
> Yes it's worth it, stack-able gives a Maker or Developer access to all the
> signals and power out not just what you bring out and there are 5 pins you
> don't bring out. The cost is comparatively minimal but allows full access
> or stack-ability if needed.
Done.
> We should also make sure those through-hole stackable connectors are
> available for sale at Seeed Studios. I have at times added a stackable
> connecter with an rPi just to increase the spacing between the rPi and an
> expansion board.
I will ask Seeed about that. Shouldn't be a problem.
>> 3) The board has a solder bridge jumper (QS1) for selecting between
>> running the IO at 3.3V and 5V. 5V is the default for compatibility,
>> but someone who knows what they are doing can switch the solder bridge
>> to run at 3.3V for everything. (Most sensor devices appear to be 3.3V
>> these days. The ATMEGA will happily run at either 3.3V or 5V)
>>
>> Q: Is a solder jumper the best way to select the voltage level? Or
>> should I put a physical switch on the board?
>
>
> Personally I'd use a 3 pin jumper, pin 1-2 is 3.3VDC operations, pin 2-3
> 5VDC operations. My second choice would be a switch. Last choice would be
> a solder bridge, you might be surprised how many people shy away from a
> soldering iron.
I have a concern here. A solder jumper I'm not too worried about, but
I don't like the idea of routing all of the supply current through a
shunt. I figured I'm not the first person to deal with this, so I went
and took a look at what others have done. This is what I found on the
Seeeduino design which can be run at both 3.3V and 5V:
http://www.seeedstudio.com/wiki/images/c/ca/Seeeduino_v4.2_sch.pdf
The 3.3/5V selection switch is merely a signal routed to a couple of
mosfets which gate the power. That removes the power supply trace from
the jumper or switch entirely. I assume it is done that way to reduce
noise on the supply rails. I'm wondering if I should do the same here.
g.
+ mezzanine review mailing list.
On 20 October 2015 at 21:11, David Mandala <david.mandala(a)linaro.org> wrote:
> Grant,
>
> Nice work. :-D Comments below.
>
> David
>
> On 10/20/15 2:28 PM, Grant Likely wrote:
>
>> I've completed rework, layout and routing of the Rev B Sensors board,
>> and it is now ready for review. I've attached the new schematic and
>> new component placement diagram. The design files have been pushed out
>> to the "rev-b" branch on github and git.linaro.org:
>>
>>
>> https://git.linaro.org/people/grant.likely/96boards-sensors.git/shortlog/re…
>>
>> It is ready for review, and very close to being ready for
>> manufacturing. However, I have some questions that I would like some
>> feedback on. Help and suggestions are greatly appreciated.
>>
>> First, here are the things to notice on the new design:
>> - Arduino connectors have been centered and lined up on the bottom edge
>>
>> of the board, including the SPI header. This should make it compatible
>> with more Arduino shields
>> - More grove connectors have been added as well as more 96B IO.
>> - Bottom edge uses right-angle SMD grove connectors to avoid
>> shorting against the USB ports on the baseboard.
>> - GPIO A-F are all level shifted
>> - SPI has been brought out to P7
>> - Arduino Grove connectors match naming convention of Arduino Grove
>> shield (D3-D7, A0-A2, I2C). The Arduino Grove examples should now work
>> without any changes.
>> - Grove connectors are evenly spaced on either side of the Arduino headers
>> - A CBUS connector has been added for 1.8V IO controlled from the USB
>> port. This will be an undocumented feature allowing the FTDI to be
>> used to control boot select pins on the base board, but requires the
>> signals to be manually wired up (hence I'm not going to document it -
>> It will just cause confusion)
>> - J1 added to support manufacturing test. It allows the Arduino to be
>> reset from the FTDI
>> - I2C0 & I2C1 have stronger pull-ups on the data and clock lines.
>>
>> Questions:
>> 1) Are the Grove connectors too close together. I tried to give lots
>> of space so that labels can be easily read, but there isn't much room
>> between the mounting holes. I could have more space if I dropped two
>> Grove connectors and put more space between P14,P15,P17 and
>> P11,P10,P9.
>>
>
> Space wise it looks good just as it is. All of my grove cables fit
> internally to the connectors, and I can read the labels with no issues.
>
>
>> Q: Which is better. The current layout, or dropping 2 Grove connectors
>> and spacing them out more.
>>
>
> In this case more is better so I think keep it the way you have it now.
>
>
>> 2) The LS expansion connector is currently an SMD pin header on the
>> bottom side. Seeed has sourced a through-hole stackable connector that
>> I could use instead
>>
>> Q: Is it worth replacing the SMD pin header with a 2x40 stackable header?
>>
>
> Yes it's worth it, stack-able gives a Maker or Developer access to all the
> signals and power out not just what you bring out and there are 5 pins you
> don't bring out. The cost is comparatively minimal but allows full access
> or stack-ability if needed.
>
> We should also make sure those through-hole stackable connectors are
> available for sale at Seeed Studios. I have at times added a stackable
> connecter with an rPi just to increase the spacing between the rPi and an
> expansion board.
>
>
>> 3) The board has a solder bridge jumper (QS1) for selecting between
>> running the IO at 3.3V and 5V. 5V is the default for compatibility,
>> but someone who knows what they are doing can switch the solder bridge
>> to run at 3.3V for everything. (Most sensor devices appear to be 3.3V
>> these days. The ATMEGA will happily run at either 3.3V or 5V)
>>
>> Q: Is a solder jumper the best way to select the voltage level? Or
>> should I put a physical switch on the board?
>>
>
> Personally I'd use a 3 pin jumper, pin 1-2 is 3.3VDC operations, pin 2-3
> 5VDC operations. My second choice would be a switch. Last choice would be
> a solder bridge, you might be surprised how many people shy away from a
> soldering iron.
>
>
>> Thanks in advance,
>> g.
>>
>>
>
> --
> David Mandala <david.mandala at linaro dot org>
> http://www.linaro.org/ Public Key id: 45B2D952
> Murphy TX, 75094 +1.972.891.8436
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "96boards-team" group.
> To post to this group, send email to 96boards-team(a)linaro.org.
>
