RetroBSD

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

All times are UTC




Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Tue Feb 16, 2016 7:50 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
You need 16 signals in order to connect an old ISA Ethernet card.. :)
http://web.archive.org/web/201106141147 ... 452-e.html\

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Tue Feb 16, 2016 7:10 pm 
Contributor

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

Your point is well taken. Lots of wires!!

If you look at the ISA bus from the point of view of functionality, it consists of two basic types of transfers.

1. 'high speed' block and small packet type transfers.

2. low bandwidth informational type transfers.

IMHO the most important of the type 2 transfers is to stop or interrupt an extended high speed transfer.

The ISA accomodates these two cases with many wires.

But if mapped to PIC32, a low speed serial pathway and a few other wires together with the SPI pathway and a few power leads pretty well covers the waterfront!

Thus we see SPI used with a few wires added for interrupt or handshake or selection use. Having a low wire count, bus type interface to handle these few discrete signals is the missing element.

IMHO this is the 'bus' we need to define/design. So we can put many peripherals on a common set of wires. If you ask me, this was the whole advantage of the ISA bus. You could plug a given card into any slot. There was even a provision to connect multiple boxes together as an extended card cage.

Somehow this idea has been essentially lost!

That said, I do not see this happening with PIC32 or any other processor any time soon?

I hope I haven't lost you? I don't see anyone else talking about this sort of thing these days?

I have some hardware running, but it is not refined enough yet to be actually demonstrating the bus sharing I talk about above. But I do have actual hardware that can accomodate it if I get back to work on the NEW kernel we are working with :).

Wouldn't it be neat to just plug into our bus the latest hardware gizmo, maybe through an adapter, and have it just work. Easy to say, hard to do!

Of course USB tries to do this sort of thing, but USB is not a bus in the ISA sense or in the sense defined above.

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Tue Feb 16, 2016 11:30 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
USB is a "Bus" (in that it allows multiple devices to be controlled by a single master) in a star topology. ISA is a "Bus" (in that it allows multiple devices to be controlled by a single master) in a Bus topology.

You see, there's the concept of the bus as in its general functionality, and the concept of the bus as in the topology (ISA, 10Base-T, etc).

Buses (in the topological sense) are a fun thing to design, especially when it's possible to have any device request access to the bus ("Bus Master") . The Z80 handled that kind of thing with the /BUSRQ and /BUSACK signals - a device requests access to the bus with /BUSRQ and the Z80 indicates that it's relinquished control of the bus with /BUSACK. Of course, that's for a "standard" A/D/C bus arrangement, which is very similar to the ISA bus arrangement.

Both the A/D/C bus arrangement and the ISA bus require manual management of addresses. Each card in the ISA bus has to manually specify its own address in the address range of the ISA bus. In general the ISA Bus was just a direct connection to the CPU's A/D/C bus. As the CPU and support chips got more complex with DMA and things more pins were added with these extra fancy functions. That's why the ISA slots came in multiple sizes - to begin with it was just the 8086's A/D/C signals directly wired in. Later it became managed by external chips and had no direct connection to the CPU itself at all - which allowed funky things like PnP to (not) work.

Then along came PCI and ruined it all ;)

Much of what the original ISA bus (the early short slot version) does is the same as the PMP on the PIC32 coupled with the INT pins. Incidentally the Z80 only had 2 interrups - the normal IRQ and the NMI - Non-Maskable Interrupt which couldn't be disabled by software - all peripherals used a wired-OR to the IRQ and it was up to the software to then work out which device had triggered the interrupt.

The same kind of system can easily be created using SPI and IO expanders. A single MCP23S17 would do all 16 data bits, and a second one would provide a 16-bit address space. Interrupts and, if required, other control signals, could be directly wired to the PIC32, or wired into a third MCP23S17 to use almost no PIC32 pins. Just the interrupt pin from the control MCP23S17 for indicating if an interrupt has been triggered (they have Interrupt-On-Change on every pin available), and there's your ISA bus. Connect as many cards as you like (pin drive permitting) with just 5 PIC32 pins - SDI, SDO, SCK, CS and INT.

Alternatively (and maybe better) would be to use a separate PIC32 as the ISA controller using the PMP for the address and data signals, as well as most control signals (RD, WR, etc) since it can run in "8086" mode. Then you should be able to pretty much guarantee the pin control speeds (clocks of up to 33MHz) the ISA cards expect. Then it's just a matter of connecting some communication signals to it from the main LiteBSD chip - maybe SPI for that.

Only thing to watch is that ISA is 5V and the PIC32 is 3.3V - which is why the IO expanders would be good - they can run at 5V.

All of this is perfectly doable.

Why haven't I done it though? Simple - I haven't *seen* an ISA card in about 15 years or so.

_________________
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: Wed Feb 17, 2016 7:18 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
http://www.nomad.ee/micros/isapic.gif
Btw it could be done with a single 9536XL CPLD in a single winter evening. And the CPLD is 5V tolerant ..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Wed Feb 17, 2016 9:31 am 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Matt and Pito,

I see we are all thinking along the same lines :).

Hmmm....

What can we come up with that is:

1. Simple, cheap and easy to understand and get right.

2. Low wire count.

3. Has the option of device handler software on the device. [Like Apple II e]

4. Can optionally shift bus speeds like Knowledge Network and later USB.


I think we could start with a list of specs.

As I said, I have some hardware stuff built, but I think we need an overall plan.

The whole change in voltage business as already noted has really made things much more difficult. Do we need two voltage pins? Power - 5V and CPU 3.3v? I hope not. But maybe that is the answer?

Do we need differential data - 2 wires as opposed to 1 wire and ground? To keep signals clean? Over distance?

I guess in some sense we are designing a bus interface.

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Wed Feb 17, 2016 10:36 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
You only need the hassle of LVDS for either long distances or high speeds. We have neither of those, I would hope.


By high speeds I'm talking Gbps like PCIe, and by long distance I am talking off-board communication. For this kind of bus I would expect it to be on-board since you need the board there to hold the ISA slots in place.

I would propose just simple SPI for the control interface, and then "something" - be that a CPLD, FPGA, PIC32, set of IO expanders, whatever, as a bus controller / interface.

SPI is already well defined, and on the MZ can do 50MHz. Also the MZ can do SQI for 4x the data throughput - great for bulk transfers.

Then it's really just down to the "whatever". I know Pito likes his CPLDs. I quite like them too, but my Verilog or VHLD isn't as good as my C programming, so I would probably lean towards a PIC32 as the bus controller.

_________________
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: Wed Feb 17, 2016 10:57 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
We are talking about a "RetroBus" for years already. But with little outcome. That is because we have a little idea what to do with it :)
ISA - if we have a card of a strategic importance we can interface, but today, when we have W5100 and ESP2866 and ESP32 and zillion of other XYZ chips and modules handy...
I've used term "academic exercise" above - unless we can access pic32 internals and make them easily available for Users (so they can use HW out of Unix), then it is in case of pic32mz an AE for me.. (as nobody will use pic32mx/mz with Unix as a server or network component).
Let start with I2C for example, or INTs, ADC, PWM, TIMx, SQI, CAN, etc..
Attachment:
pic32mz.JPG
pic32mz.JPG [ 143.87 KiB | Viewed 14929 times ]

Great thing would be to have "something" running "below OS", "close to HW", receiving "scripts" from above userland, and "executing on internal HW" such it will not be slowed down by Unix layer. "Something" like "virtual HW coprocessor".
And the Unix itself will provide a "supporting presentation layer" for users as we like its user friendliness.

For example "do ADC from this 4 inputs every 5ms and store it via DMA into an external SQI ram, till the LOW at pin H7 appears or TIM5=0 or INT1 or SQI ram is full and then stop and tell OS the data are ready". And the OS will send it via wifi, or save to the sdcard under name "My lovely data.txt" in /usr/share/mydata/".

Or, "stabilize this quadcopter and navigate heading north", while we may connect via wifi to the OS as an User, and cat the temp.log with recent temperatures of the engines.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Wed Feb 17, 2016 4:36 pm 
Contributor

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

Hmmm...

Maybe a 2nd PIC32 as a hardware co-processor?

Reminds me of the IBM Microchannel arch. idea of years ago.

I like your idea of a script that tells the hardware what to do and when done signals the 'main' processor when the output is ready.

This could be designed to accomodate multiple PIC32s.

So the issue becomes inter processor communications.

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Thu Feb 18, 2016 8:09 pm 
Contributor

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

So, Matt, I guess we use SPI? I am thinking we need 4 pins for it. I am assuming that some SPI devices need /CS handshake as you talk to them? Maybe a 5th pin is also included to accomodate jtag?

What other pins are needed?

Probably what I sometimes call reverse interrupt. Peripheral tells 'main' CPU I have traffic for you right now. 'main' PIC scans this common wire when idle or it causes an interrupt.

Some sort of selection mechanism. Maybe a cheap PIC on a single wire to send/receive serial of some sort with a gate in series with the local /cs wire [assuming that cs inactive takes unit off SPI bus]. [ I suppose all/some of the SPI wires could be 'turned off' as well?]

Peripheral Reset pin activation? Maybe the cheap PIC does this?

Is complete peripheral voltage removal needed? This is an open question for me. It allows recovery from a wide variety of peripheral problems both hardware latchup and software bugs. Not cheap. But probably needed especially for unattended situations.

Bus protocol, product identity, software upload. I assume these can be handled by the cheap PIC?

Comments appreciated :)

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 6:27 am 
Committer
User avatar

Joined: Wed Oct 10, 2012 11:01 pm
Posts: 1081
Location: Sunnyvale, CA
Hi Wiz,
wiz wrote:
Serge if I understand you correctly, a J60 interfaced to the kernel would be able to do it all at least at 10baseT rates?
As would an old ISA style ethernet card?

Yes, a driver for ENC28J60 should do the task, but it's limited to 10BaseT only. I would prefer ENC424J600. The development effort is mostly the same, but you get 100BaseT interface and 3x times more internal data memory.

I also had some experience with J60 and some time ago developed a driver for it for some RTOS: https://github.com/sergev/uos-embedded/blob/master/sources/enc28j60/enc28j60.c


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 10:17 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
The j60 is available in a n00b friendly dip. The j600 is (iirc) tqfp. While 100mbps would be nice, 10mbps is adequate for most things and easier for an ardueenie to wire up.

Sent from my SM-T555 using Tapatalk

_________________
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 19, 2016 2:04 pm 
Contributor

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

Thanks for your clarification. I agree with your which chip to use comment!

I am not sure how much work would be needed to add a 'user' network device.

What I have in mind is a user defined kernel mode 'network' interface that I can write a test driver for. Load it into kernel RAM. Test it, patch it. etc. All without recompiling anything but the driver itself.

Things should be arranged so the kernel can boot normally with no 'user' driver present.

Lots of fun :).

Wiz


Top
 Profile  
 
PostPosted: Fri Feb 19, 2016 2:45 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
That's the kind of thing you'd do with the TAP driver. Except you don't have to faff around with kernel space since your program is just user-land.

Once you have your driver working in user-land it would then be a simple enough matter to replace the tap stuff with actual kernel interface stuff and add it to the kernel. The hard part is really getting your hardware working, which is easier to do in userland.

It should be a simple enough matter to port the tap driver from openbsd or somewhere.

_________________
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: Mon Feb 29, 2016 2:53 pm 

Joined: Mon Nov 24, 2014 1:07 pm
Posts: 58
I have to say that I think the TAP driver interface and then just hang a J60 / J600 off of the SPI bus is the way to go. I think the ISA bus route has issues in that it's clunky, uses too many interface chips and there are the added problems of sourcing the cards too. A nice el-cheapo J60 would be my favourite as there's no real need for 100Mbps Ethernet, albeit rather nice it is an overkill. My other preference is to add a Micrel network PHY and switch chip like the KS8873RLL to the RMII port so I can sniff data and have two data routes if I wanted or another device connected to it via Ethernet locally and one port going to a router.

The old wide bus system is very antiquated and not really necessary as almost all the peripherals you'd want to connect to the MZ are going to be SPI or I2C anyway.

Just my two pennies...


Top
 Profile  
 
PostPosted: Mon Feb 29, 2016 9:00 pm 
Contributor

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

I guess what I had in mind in mentioning the ISA bus was two fold:

1. It worked :). Some would even say it worked well?

2. With a cheap PIC you can make your gizmo look like a J60, J600 or whatever with a minimum of PIC32 pins needed.

IIRC That is what essentially was done on the PDP series.

The only real issue seems to me to be the driver(s).

Which brings us back to the obvious issue that it would be nicest if the driver was loaded from the device itself so the main LiteBSD code stays the same when different devices are 'plugged in'.

While we are now talking about networking, there were serial port cards, parallel port cards, audio cards, etc. There was a 'custom' card to put your own stuff easily on the 'bus' of the system.

Cards doing those types of things, that could just plug in and work, would really make our LiteBSD system very much more useful [ IMHO ].

Anyways that is where I am headed :).

Wiz


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

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