In my previous job, we used SharePoint to keep our documentation organised. This was reasonably successful, but there's obviously a need to keep the site up to date, relevant and suitably setup. However, SharePoint's architecture was flexible enough for us to be able to customise it to our needs without resorting to coding. What I would suggest is that you put aside some time for managing whatever solution you go for. Without maintenance, it's very easy for a documentation repository to become either stale or disorganised. We made a point of updating our team's folders at the end of every Sprint of work (we used the Scrum agile methodology).
Wikis are a great idea for sharing knowledge, possibly in a less formal manner. I experimented with using a private WetPaint wiki, but didn't get buy-in from management. However, it's certainly worth a try. You aren't going to get away with no need for editorial control, but there's nothing wrong with making this aspect a shared responsibility between teams or doing it in a round-robin manner.
What I would recommend is booking time in your calendars for knowledge exchange sessions. It's all to easy for larger development houses to split into silos (not deliberately, but almost as a by-product of necessary specialisation) and for this to result in two or more teams working on many of the same problems. Monthly or fortnightly sessions with the whole group can be very useful. Videoed presentations are another idea, but there has to be a balance between keeping a record of technical details and the preparation required to do this effectively. (We never got this off the ground in my previous job.)
If you're split into small teams, I'd really recommend daily stand-up meetings where everyone goes through what they achieved the previous day and what they plan to do today. This is one of the keys to Scrum, it keeps everyone up to date really quickly and it saves a lot of unnecessary meetings and reviews.
I hope this helps.