Jeremy g.Fun with I2C and SPI..
Good thing I ordered a bunch of tiny Soic 8 breakout boards :)
So it's been a while.. or a few days since my last post. Work8ng without asf and for that matter working with asf drivers is difficult especially when ones c foo in micro controllers is new and in ARM for that matter.
Also @Atmel Corporation I understand the need for a higher level c driver (kind of) but please provide some examples in pure c these micro's don't have alot of room and stuffing asf drivers into these things take quite a lot of space also the drivers are confusing..
here's how I2C is going:
I finaly managed to get the I2C module on SERCOM0 to configure properly, or so I think. I can somewhat talk to the eeprom but all I get back is garbage. So either something is not translating right (ie I am not processing the data properly) or its a baud rate issue etc. I have not thrown the micro into the scope yet.. I will look at the SCL line with a scope soon.
I created a function to scan the I2C bus and spit out the proper address of the device after an ACK is received. This seems to work but I get an address of 0xD0 when I expect an address of 0x50. This may be a pointer issue as well. I'll look into this tomorrow.
I2C update
I put the micro under the scope last night again for the I2C lines and they seem to be working. With a 24lc64 if I send it's address in write mode I get a ACK back(so says my scopes i2c decode functuon) and data is 0xFF witch I assume to be correct since the chips have never been programed.
I2C update 2:
So far it seems that I2C is working. I hooked up the board to my logic analyzer and the data seems to be good. I'm continually sending a read address to the chip. This is what it looks like.
So all the ACK's are there and the data being sent back is understandably 0xFF this is what I would expect. Now to read reviews, write and read again to make sure the data is being stored.
@al1's SPI code:
al1 has managed to get a simple spi interface up and running and has successfully read the device id of some random flash chip he pulled from a board.
I am not having such good luck with this yet. I need to make sure the lines are acting properly. Everything is running from a base 1Mhz clock.
I get an rx event when I send the spi device a read instruction for its device id but nothing is in the rx buffer. Again it's probably my lack of reading the devices datasheet.
Update on SPI:
It would seem I'm not initializing the SPI pins properly. As I'm seeing jack on the scope...
Scope pic.
Getting nada, not even a wiggle.. I know I'm toggling the cs line.. somethings gata be up. Time to re program the chip.
Until next time.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Did you connect your SERCOM pads with any IO? like this:
pin_set_peripheral_function(PINMUX_PA14C_SERCOM0_PAD0); // mosi pin_set_peripheral_function(PINMUX_PA15C_SERCOM0_PAD1); // clk
pin_set_peripheral_function(PINMUX_PA08D_SERCOM0_PAD2); // miso
SPI_setup(3);
PORT->Group[0].DIRSET.reg = PORT_PA02; // pa as sw ss
PORT->Group[0].OUTSET.reg = PORT_PA02; // SS idle high
The pin_set_peripheral_function() function is also used in my UART code.
Are you sure? yes | no
a I have the pin_set_peripheral_function() set for all three pins. And have also set /CS as putput etc. It gets its own library currently (awsome function.)
I was not sure what mode to use for the spi_setup function. Although I'm sure it's stated somewhere and I just missed it.
I put the micro under the scope last night again for the I2C lines and they seem to be working. With a 24lc64 if I send it's address in write mode I get a ACK back(so says my scopes i2c decode functuon) and data is 0xFF witch I assume to be correct since the chips have never been programed.
Don't know if I'll get time to mess with the spi pins more today or not. The very messy code is uploaded to my github account under the branch dev in the test folder.
Are you sure? yes | no
also I've mapped mine to pa4,6,7 pa 5 is cs.
Are you sure? yes | no