Add DTS for MikroBus Cape for BBB

[Michael Carr]

Hi Robert,

I've ordered a MikroBus cape from MikroElektronica. They have a device tree source file to support the cape. May I pass it along to you to add to github?

The eeprom on the card is empty and I will need to generate the contents. Does anyone have a tool to create/read/write eeprom contents via cloud9? I tried running eeprom-web.js and I get a cloud9 error.

Thanks,

Mike

[Michael Carr]

I wrote an EEProm binary file generator. I would like to share it and also get some feedback. What's the best way to do that?

[William Hermans]

I wrote an EEProm binary file generator. I would like to share it and also get some feedback. What's the best way to do that?

http://beagleboard.org/project

and source on github would probably be good too.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

And . .. http://forum.43oh.com/ there is a subsection for beagle systems. Used to be a whole dns name for it( Beaglefu ), but I guess not enough traffic for ads to pick up the slack ?

[Michael Carr]

Hi William,

I just added a description to the BBB projects. I couldn't add the zip files and it's a complete Visual Studio project so adding the source was going to be complicated. I will be out of town until Friday. When I get back I will see about getting the project and source available. Thanks for your help.

Mike

On Thursday, July 16, 2015 at 8:59:42 AM UTC-7, Michael Carr wrote:

[William Hermans]

HI Mike,

I'm actually not a part of beagelboard.org, so I can not assist you any further than giving you some information. However, Gerald, or Jason are the two you should be contacting about adding source files - To the project.

--

[William Hermans]

errr, you're welcome, and have a good weekend.

[Jason Kridner]

Source files should be added to github, as mentioned before. I suggest
using github's deploy feature if you need to release binaries.

[Jason Kridner]

On Thu, Jul 16, 2015 at 11:59 AM, Michael Carr <mac...@msn.com> wrote:
> Hi Robert,
>
> I've ordered a MikroBus cape from MikroElektronica. They have a device tree
> source file to support the cape. May I pass it along to you to add to
> github?

Please do send a github pull request. Thanks for posting here as well.

>
> The eeprom on the card is empty and I will need to generate the contents.
> Does anyone have a tool to create/read/write eeprom contents via cloud9? I
> tried running eeprom-web.js and I get a cloud9 error.

If the other replies on this thread aren't sufficient, consider
http://papermint-designs.com/community/node/338. Note that the kernel
and bootloader both currently ignore the pin allocations, but it is
still nice to put them in. The pin allocations all get set by the
.dtbo files now simply based upon the name and board version. Serial
numbers are desired.

[Robert Nelson]

Thanks! Pushed as part of:

https://github.com/RobertCNelson/bb-kernel/commit/c43f83c076c30cfbd98d4c00f962ca22a9563933

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
Robert Nelson
https://rcn-ee.com/

[Michael Carr]

Hi Robert, Jason and William,

Sorry for not pulling the device tree files, I've been out of town. I hope the files help someone in the future if they purchase a mikroBus cape.

This morning I found that the mikroBus cape is using a Microchip 24AA01 (1K, 128 x 8) eeprom not a 24C256. Two questions came to mind after I found this out.

1.) The Microchip 24AA01 doesn't use A0 ~ A2 (Don't Care). Responds to any 0x5X address. Potential cape addressing conflicts here.

2.) The non-B version clock is limited to 100Khz.

Is the default clock for i2c bus 1 > 100khz? Ex. 400Khz 1000Khz? Can I force it to 100 Khz?

Yep, having problems writing to the eeprom. The schematics don't agree with the delivered board.

Looks like they intended to use the 24C256 but in manufacturing they used the 24AA01 instead.

Mike

[Michael Carr]

I have a quick question about supported i2c eeprom types.

From the user side is there a way to query/list supported types (ie. 24c256)?
Conversely, is there a way to define a new type from user space and add it, maybe through i2c-1/new_device?

Documentation other than the SRM?

Thanks!

[Michael Carr]

I found the solution ATMEL used to manufacture a 24c01.

I performed the following-

root@beaglebone:~# echo 24c01 0x50 > /sys/bus/i2c/devices/i2c-1/new_device
root@beaglebone:~/BBB-mikroBus-Cape# echo "This is a test" > /sys/bus/i2c/devices/1-0050/eeprom
root@beaglebone:~/BBB-mikroBus-Cape# cat /sys/bus/i2c/devices/1-0050/eeprom | hexdump -C | more
00000000  54 68 69 73 20 69 73 20  61 20 74 65 73 74 0a ff  |This is a test..|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000080

I think the mikroBus capes and click boards are going to be a lot of fun. I'm going to use the ADFruit python libraries as a basis.

The Logibone FPGA cape is also working well for me. Really having fun.

[Harvey White]

On Sat, 1 Aug 2015 18:27:14 -0700 (PDT), you wrote:

>I have a quick question about supported i2c eeprom types.
>
>From the user side is there a way to query/list supported types (ie.
>24c256)?

The 24C256 is 32K * 8, and as such, needs a 16 bit address. This
particular chip ignores the most significant bit of the address. With
this same addressing model, the maximum capacity would be 64K, which
would use all 16 bits, and would be a 24C512.

The 24C1024 will need 3 address bytes, not two, and unless the driver
knows to put in that third address byte, the maximum addressable range
is 64K.

Further, there are several ways of writing data, either page mode or
byte mode. Byte mode needs an address for each byte. Page mode must
be written so that the data does NOT cross an absolute page boundary,
otherwise it wraps without an error and you get bad data written. Page
size does vary amongst the various chips in the family. You write a
page (or part of a page) without wrapping, and then the chip refreshes
and writes the new page.

Reading must be done by starting a write (chip address and 16 address
bits), a repeated start, and then the chip address as read. Data can
be read as long as the read sequence is active, page boundaries are
not significant here. If no address is provided, the previous address
is used as a start and automatically incremented each byte read.

So basically, 24C01, 24C02, 24C04, 24C08, 24C16, 24C32, 24C64, 24C128,
24C256 and 24C512 can all be handled with 16 bit addresses. The
24C1024 and above need the 24 bit address driver. If the driver knows
the page size, then all of these chips can be written by the same
driver. Reading can handle any of these chips.

Had to write a driver for these chips a few weeks back.

Pretty much anything in the 24C series below a 24C1024 can be read and
written by the same driver if you know the parameters. 1024 and above
can be handled if the driver is smart enough.

No idea how the existing driver is written, but this is what's
involved.

Harvey

[William Hermans]

Sounds like the two of you have it "surrounded". Good info Harvey :)

[Harvey White]

On Sat, 1 Aug 2015 19:43:42 -0700, you wrote:

>Sounds like the two of you have it "surrounded". Good info Harvey :)

Thanks. Came from deciphering the data sheet and figuring out what
they *really* meant.

I do a similar thing as the capes with an Xmega design (got a bunch of
them, and they come in packages I can deal with). Some pin
multiplexing is done, but the configuration EEPROM is used as a system
resource to any other processor in the system (it's multiprocessor by
intent), and additional data storage when needed. Much of the
configuration data is in the processors EEPROM store, which allows a
graphics board (generic, supports 128x64 up to VGA with the same chip)
to be built for a particular display, keep the programming "off site"
and have the programming updated without losing the customization.

Internal EEPROM can be memory mapped and is thus easier to access.

AT24CXXXX driver should work for just about any of the chips.


Harvey

[Michael Carr]

the following command line does indeed instantiate the 24c256 eeprom special file.

root@beaglebone:~# echo 24c256 0x50 > /sys/bus/i2c/devices/i2c-1/new_device

While using this definition to write to a 24c01 did seem to work, it seems that once I wrote past the last byte it started over writing the contents at the beginning again (No errors reported). Defining a new device as a 24C01 gets everything aligned size wise.

Anyways, the click boards sound like a fun effort. I'm going to start with their MPU 9DOF IMU board. Bosch has a device- a BNO0055 that implements euler angles or quarternions. It would be nice to implement that as well otherwise I'll have to do that on the ARM FP. Hope it can keep up.

Thanks for your help Harvey!

Best,

Mike

[Harvey White]

On Mon, 3 Aug 2015 19:57:03 -0700 (PDT), you wrote:

>the following command line does indeed instantiate the 24c256 eeprom
>special file.
>
>root@beaglebone:~# echo 24c256 0x50 > /sys/bus/i2c/devices/i2c-1/new_device
>
>While using this definition to write to a 24c01 did seem to work, it seems
>that once I wrote past the last byte it started over writing the contents
>at the beginning again (No errors reported). Defining a new device as a
>24C01 gets everything aligned size wise.

Right. To be expected. The larger chip has a 128 byte page size, and
that's the size of the whole 24C01. The 24C01 has a page size of 16
or 32 (think it's 16). What ought to happen is that you will wrap in
an absolute page of 16 (0-16, 17-32, etc) when you write at say
location 8 and try to do 16 bytes, it writes the upper 8, wraps to the
lower 8, and never tells you).... (nasty).

The driver will split things up based on the absolute address, so
you'd get a write on 8-15, then a second one from 16 to 23. That
works.

Specifying a larger chip simply let's it try to write that page size
as an entire block, rather than breaking it up.

if the driver knows about chip sizes, then someone did their job right
and you just need to know the chip type to figure out what the chip
really is. Good job.

>
>Anyways, the click boards sound like a fun effort. I'm going to start with
>their MPU 9DOF IMU board. Bosch has a device- a BNO0055 that implements
>euler angles or quarternions. It would be nice to implement that as well
>otherwise I'll have to do that on the ARM FP. Hope it can keep up.
>
>Thanks for your help Harvey!

Glad to help. Convenient that I had to solve the problem so I
remembered the details.

Harvey

>> >> email to beagleboard...@googlegroups.com <javascript:>.