RetroBSD

2.11BSD operating system for microcontrollers
It is currently Sun Mar 29, 2020 10:29 pm

All times are UTC




Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Thu Feb 12, 2015 4:05 pm 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi All,

I've got the basic shell of my i2c driver done and decided to try and compile the kernel. All went well once I realised I needed to add i2c.o to the fubarino makefile as that's my board type that i'm using. The only issue is that both the skel and i2c driver aren't listed under the /dev node.

Any ideas Serge, Matt et al as to why this isn't working for me? I'm a CSharp developer and haven't done a lot of ANSI C so forgive my mistakes, I've tried to pester the embedded guys here at work until I fixed the 3 errors I had before my driver would compile correctly. The resultant i2c.o file is being linked as well and I do see a change in kernel size. However the problem remains with it not appearing in the dev node.

Oh and I have followed the updated skeleton driver check in - very closely, just in case you we're wondering. I can also post the code on my dropbox as an entire zipfile if anyone wants it to take a look...

Thanks in advance for your help guys, much appreciated.

Dan


Top
 Profile  
 
PostPosted: Thu Feb 12, 2015 6:06 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
The /dev/ node is populated by a user-land process. That gets the data through a system call, so you have to make sure the right tables are populated in the right way.

You have to ensure you provide a "devspec" table which is basically a (null terminated) list of minor numbers and the names to associate with them. That devspec is then included in the cdevsw table as the last parameter.

The process "devupdate" then runs at bootup to populate the /dev from that table.

You should also create a "cfg" entry for the device. See the "sys/pic32/cfg" directory. That defines how to configure the device to the config system.

For instance, looking at the ADC device, there is the devspec table of:
Code:
const struct devspec adcdevs[] = {
    { 0, "adc0" }, { 1, "adc1" }, { 2, "adc2" }, { 3, "adc3" },
    { 4, "adc4" }, { 5, "adc5" }, { 6, "adc6" }, { 7, "adc7" },
    { 8, "adc8" }, { 9, "adc9" }, { 10, "adc10" }, { 11, "adc11" },
    { 12, "adc12" }, { 13, "adc13" }, { 14, "adc14" }, { 15, "adc15" },
    { 0, 0 }
};

and the cdevsw entry of:
Code:
#ifdef ADC_ENABLED
{
    adc_open,   adc_close,  adc_read,   adc_write,
    adc_ioctl,  nulldev,    0,              seltrue,
    nostrategy, 0, 0, adcdevs
},
#endif

and the config file for it is:
Code:
always
    file adc.o
    define ADC_ENABLED YES
end always

So then in the configuration for your kernel you add the line:
Code:
device adc

and it then automatically adds the adc.o file to the Makefile (when you reconfigure it) and adds the -DADC_ENABLED=YES to the compilation command line.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Fri Feb 13, 2015 11:23 am 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi Matt,

I've added the following to the devsw.c file:
Quote:
#ifdef I2C_ENABLED
{
i2c_open, i2c_close, i2c_read, i2c_write,
i2c_ioctl, nulldev, 0, seltrue,
nostrategy, 0, 0, i2cdevs
},
#endif


The i2cdevs is defined in the i2c.c file as follows:
Quote:
const struct devspec i2cdevs[] = {
{ 0, "i2c1" },
{ 1, "i2c2" },
{ 2, "i2c3" },
{ 3, "i2c4" },
{ 4, "i2c5" },
{ 0, 0 }
};


I also have an i2c.dev file in the cfg directory set as:
Quote:
always
file i2c.o
define I2C_ENABLED YES
end always


And lastly added the following line to my FUBARINO file: device i2c

The problem is that it still isn't actually adding it the the Makefile in the fubarino folder, however the skel.o module is being added when I add the line: device skel to the same FUBARINO file. I'm missing something here but cannot for the life of me see what it is. I think I'm going snow blind or something. If I force the Makefile it does compile the i2c.c to an i2c.o file but won't include it in the kernel, I guess because the DI2C_ENABLED isn't in the list of defines in there too.

If you've any more suggestions I'd be very grateful, and probably retain the hair on my head too :)

Thanks, Dan


Top
 Profile  
 
PostPosted: Fri Feb 13, 2015 11:29 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Ah, I think you may be running into a small naming issue actually. It may be trying to add device I, unit number 2C.

You may need to rename your I2C driver to IIC instead.

Basically it splits the name on a number, so it handles things like sd0, sd1, etc as the SD device with unit numbers 0 and 1, etc.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Fri Feb 13, 2015 11:48 am 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Aha, I'll give that a go.

I also just commented out the device i2c in the FUBARINO file and uncommented the skel driver. The funny thing is that although it compiles it and the DSKEL_ENABLED is in the makefile it doesn't show up in the dev node, which I thought was strange. I'm not sure what impact that would have on my driver if any though?!

Again, thanks for the quick response!

Dan


Top
 Profile  
 
PostPosted: Fri Feb 13, 2015 12:00 pm 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Thanks Matt you're a star! I renamed the devspec struct items to iic and now it compiles and the dev node shows 5 iic devices as it should do. Yay!!

Now all I need to do is finish the code and test it. Once I've done that I'll ask someone on here to have a play with it and then request a pull on github for the i2c driver if that's ok?

Thanks again!!

Dan


Top
 Profile  
 
PostPosted: Fri Feb 13, 2015 12:12 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Brilliant! :) Looking forward to it.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
PostPosted: Fri Feb 13, 2015 6:38 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Dan and all,

An I2C driver is a good idea. I have a simple RAM loadable kernel module running which could make your efforts a lot quicker and easier.

Making a kernel driver link to kernel RAM would mean that your test code can be loaded into RAM, tested, modified either directly in RAM or recompiled/assembled and reloaded and retried. This 'user loadable kernel RAM driver link' could become a standard feature of RetroBSD?

This continues to save me a VERY HUGE amount of time.

And there is quite a bit of unused kernel RAM available to play with !!!!

In my case my bitbanging serial driver compiled as userland C was too slow for the RF chip I have been working on.

Now the assembled version is loaded into kernel RAM and then called from the user program. This has greatly speeding things up so I can now see all of the RF packets in the air.

Good luck with your driver!

Lots of fun :) :).

Wiz


Top
 Profile  
 
PostPosted: Sat Feb 14, 2015 7:38 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Dan, an iic driver would be great to have!
I do currently RTC with portio bitbanging instead.
P.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 9:47 am 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi Wiz and Pito,

I could do with the RAM loadable kernel module code, that'd be great and would definitely reduce my time debugging the code once I've finished it. So far I have the driver loaded on my diy fubarino clone with devices iic1 through to iic5 and am going to try to output a basic frame of data so I can check it on my DSO so I can be sure I'm doing things correctly. Then I'll have a go at talking to an external adc module before trying other devices such as a DS18b20 and an RTC module.

I've never written an os driver before and my day job consists of writing code in C# for Windows Embedded which isn't the same as low level c. So bear with me and I'll try to get something done asap. The module will be making use of ioctl for the read and writes rather than the usual read / write methods in the driver for char devices. This is because there are a lot of differences in the amount of bytes that are transferred to the chips that can be connected to the i2c bus. I hope that's ok for you guys?

So far so good, hopefully I'll have something useable within the next two or three weeks...

Have fun everyone,

Dan


Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 4:36 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Enclosed find a small gadget which shows you (all) i2c devices wired to retrobsd.
Maybe good for your i2c development.. :)
Do import it into retrobsd's filesystem, chmod it and run it. It uses pins 2 and 3 on fubarino sd (rd10 and rd11). Do not forget 10k pullups.

Quote:
# cd /bin
# i2cscan
I2C dev found, adr(r/w): 51(A3/A2)
#


Attachments:
i2cscan.zip [5.24 KiB]
Downloaded 441 times

_________________
Pukao Hats Cleaning Services Ltd.
Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 5:15 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
And another one, when you get the pcf8563 rtc chip.
It reads (writes) date via the above pins.
Code:
# rtcread8563
1502161906.36
#

The number above is not the unix time, but the date/time format readable by "date" (YYMMDDHHMM.SS).
Therefore this line in the cron:
Code:
9,19,29,39,49,59 * * * * date `/bin/rtcread8563`

will keep your retrobsd system clock synchronized ..
More on viewtopic.php?f=5&t=8312&p=10064&hilit=rtcwrite8563#p10064


Attachments:
rtc8563.rar [10.46 KiB]
Downloaded 462 times

_________________
Pukao Hats Cleaning Services Ltd.
Top
 Profile  
 
PostPosted: Mon Feb 16, 2015 9:26 pm 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA
Hi Dan,
DanTheMan wrote:
The module will be making use of ioctl for the read and writes rather than the usual read / write methods in the driver for char devices. This is because there are a lot of differences in the amount of bytes that are transferred to the chips that can be connected to the i2c bus. I hope that's ok for you guys?

Using ioctl() for i2c bus transfer is OK. We do the same for DPIO and SPI. Say, the 32-bit write operation for SPI looks like:
Code:
    unsigned char data[4];
    data[0] = 0xF0;
    data[1] = addr >> 8;
    data[2] = addr;
    data[3] = byte;
    ioctl (spi, SPICTL_IO8(4), data);

--Serge


Top
 Profile  
 
PostPosted: Tue Feb 17, 2015 12:58 pm 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Pito,

That'll certainly help out checking that my devices are consistent with both your i2cscan and an internal scan function that I'll add to the ioctl list in the driver. I don't have a pcf8563 rtc so I'll get hold of one when the driver is working with the adc / dac module I currently have.

Serge,

At least I now know I'm on the right track. I'm hoping I can perform a simple read in about a weeks time. I'll report back once I've got that done.

Thanks everyone and have fun :)

Dan


Top
 Profile  
 
PostPosted: Tue Feb 17, 2015 2:14 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi All,

Pito: how about sources for i2cscan?

And can it be compiled on RetroBSD?

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Tue Feb 17, 2015 2:37 pm 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi Wiz,

Iirc Pito posted the sources a while ago and they needed to be compiled under uecide. I never managed to get them to compile myself but then I only spent a little while with uecide before wishing there was a driver in retrobsd. I ran out of time at that point and my attention moved to other things. Now I've got back to my fubarino and playing with that with gas sensors which use i2c hence the reason why I've been reading up on nix development and readying myself to write the i2c driver.

Do you have your ram kernel module source available? That'd really help out if you could post it on here.

Thanks and have fun,

Dan


Top
 Profile  
 
PostPosted: Tue Feb 17, 2015 3:54 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Dan,

No problem. I'll get them put together and put them up on my site. You may copy and do whatever with them from there.

I have yet to post anything real directly on this site. Probably easy, but more to figure out....

Basically my Retro system starts in a debugger. From there I start Retro itself. This leads to me wanting to have 4 words that are not touched by Retro. I put these at the beginning of physical memory. This is followed by a 512 byte block so Retro can reprogram its own boot loader or itself (from RAM). Retro RAM is next. This leaves at the end Retro RAM a rather large piece of kernel RAM. This is where I put my drivers.

Since I barely understand linker stuff, I consider this as beginning at a fixed address, 0x80006100.

I have added three commands to the kernel which allow a user program to peak, poke and execute a program in kernel memory space.

While it sounds complicated. It works well.

I compile/assemble my driver to binary. Write it to fixed kernel RAM (with the peek and poke) and then execute from my user program with the execute option.

Serge pointed out that some sort of management of kernel RAM is probably needed. I agree but haven't done that yet.

My driver start script looks like:

./fixram -- fixes RAM pointers. Writes 0x6000 to 0xbf882010
./f2ram test -- writes binary into fixed kernel ram 0x80006100
./jmhtst1 -- starts my RF monitoring user program

Works well. All compiled and assembled under RetroBSD and friends !!!!!

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Tue Feb 17, 2015 11:05 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
i2cscan:
viewtopic.php?f=5&t=8389&hilit=i2cscan#p10080

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Wed Feb 18, 2015 8:33 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA
As you probably aware, some time ago, there was PIC32 I2C driver included in the Linux kernel sources, donated by Microchip. Later it has beed removed for some reason. You can find it here:
https://github.com/grate-driver/linux/blob/master/arch/mips/mti-sead3/sead3-pic32-i2c-drv.c

Documentation: http://ww1.microchip.com/downloads/en/D ... PI-I2C.pdf

Seems like this driver uses read/write calls for data transfer, not ioctls.


Top
 Profile  
 
PostPosted: Wed Feb 18, 2015 1:18 pm 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
Hi Serge,

Maybe I should implement that after I get the nuts and bolts of it working with ioctl. It's probably a good idea and means it will then be a 'proper' char device driver rather than a half attempt. If it's worth doing then it's worth doing properly :)

Dan


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission