PDA

View Full Version : Connect One Ethernet shield



dhouston
- 29th May 2011, 17:47
I'll finish the laying out connections after I get my XINO basic kit.

5580

Now back to waiting for the long-promised Tibbo EM500/GA1000 firmware.:(

dhouston
- 30th May 2011, 20:31
Stll waiting for the long-promised Tibbo EM500/GA1000 firmware so I'm trying to fill the time productively. The ConnectOne shield now supports 2 WiFi and 1 NoFi module.

Oh, no! Now I'm also waiting for mackrackit to decide on an EEPROM and to start coding.:D

mackrackit
- 30th May 2011, 22:22
uhmm,
I need to quit falling asleep. I missed the part about volunteering..;)

I do not have a whole lot of time to dedicate to a new project as much as I want too. But I will try to find some time to play :)

As far as EEPROMs... FRAM seems kind of expensive. Not sure how big of one would be needed, maybe a 24FC1025 would be "OK" ? After it is all setup should be just READS....

Need to sleep on it some more :D

dhouston
- 30th May 2011, 23:28
As far as EEPROMs... I already have board designs for a battery backed RTC and for an EEPROM. Both are I2C and they might be plugins on shields that should require one or the other. I use 64KB in another application so it would be simplest to just use it, as is. Or, it might be best to just provide for a DIP that the user could add.

I'm also kicking around my own design for a slightly more costly but much easier and much more powerful Arduino clone that would make a great test bed and development system It's all this time on my idle hands...:)

dhouston
- 31st May 2011, 05:51
I think I can forget about seeing the Tibbo firmware anytime soon so here is what I think is the final layout for the ConnectOne ethernet shield. The TX, RX connections are dictated by the PICAXE and Xino. I still need to check this with the Xino designer but I think it's ready to have CircuitMart make some prototype PCBs.

5595 5596

When the Tibbo firmware is released I hope someone will consult a medium and let me know.

I'm going to spend my time finalizing the design of yet another Arduino clone. This will use a ZBasic ZX328n (http://www.zbasic.net/Microcontrollers/ZX-328n-Microcontroller/p-68.html) but it will be socketed so it can be replaced with a AVR Mega328P.

When my Xino kit arrives I'll see whether it is practical to modify to use the comparators as inverters for TX, RX. That should work with 16F88, 16F886/887 and 18P25K20/22, lowering the chip count.

mister_e
- 31st May 2011, 05:56
When the Tibbo firmware is released I hope someone will consult a medium and let me know.
Ask your supplier to let you know :D

mackrackit
- 31st May 2011, 06:38
I must have missed something ..
Where/when did a picaxe come in and why???

dhouston
- 31st May 2011, 13:57
I must have missed something ..
Where/when did a picaxe come in and why???Sleeping again, huh? :rolleyes:

The Xino basic Arduino form factor main board (http://www.ciseco.co.uk/content/?p=1563) was designed to be a super low cost way for educators to make use of the myriad of shields available. It can use 18-pin or 28-pin PICAXE or PIC. I have a kit en route and hope to modify it to add series resistors in the TX, RX lines so that the comparators in the 16F88, 16F886/887 & 18F25K20/22 can be configured as inverters for TX, RX further reducing the parts count. There are pinouts for both 18-pin and 28-pin PICAXE chips at the above link.

I am not really familiar with PICAXE but it appears the software UART pins are predefined so that's why I connected them per the pinouts. Also, the newer PICAXE 18M2 and 28X2 chips are custom made by Microchip for PICAXE. I have no idea whether this just means they have their logo printed on them or whether there are changes to the designs. I haven't seen datasheets for them. But, if they can justify custom chips from Microchip, PICAXE must be very popular.

Since all the PBP software UART pins can be defined at compile time by the user, this should not be problem for PBP users.

And, I still have to study the pinouts to see where the I2C connections need to be made. I2C presents one problem in that there's no way to easily deal with address conflicts should another shield also use I2C. I'll probably just tie all the address pins high with the leads exposed in such a way that the user can cut PCB traces to change the address. Also, multiple pull-ups could be problematic

Also, I already have small I2C boards with 64KB EEPROM (SMT) which could be an optional item. I also have a similar board with a battery-backed RTC which uses the same pinout . But, I don't want to become a supplier (My next change of address may make me inaccessible.) so I'll have to see if the Xino folks will make them. Still, it might be best just to design for a DIP-8 socket and through-hole pull-ups.

dhouston
- 31st May 2011, 14:29
I just noticed that the Xino Pro, which uses the same pin arrangements, has a pinout for the 18F25K20 on its web page (http://www.ciseco.co.uk/content/?p=1315). That should help in determining which PICs are compatible.

mackrackit
- 31st May 2011, 14:48
I2C presents one problem in that there's no way to easily deal with address conflicts should another shield also use I2C. I'll probably just tie all the address pins high with the leads exposed in such a way that the user can cut PCB traces to change the address.

What about jumpers? Add a little to the cost but it might be worth it in the long run.

cncmachineguy
- 31st May 2011, 14:54
or how about solder jumpers? No added cost at all.

iwalker
- 31st May 2011, 15:57
The wait is over

http://blog.tibbo.com/

The new firmware was updated yesterday.

Regards
Ian

dhouston
- 31st May 2011, 16:42
What about jumpers? Add a little to the cost but it might be worth it in the long run.


or how about solder jumpers? No added cost at all..
I've done a bit of both and also added through-hole pads to each of the five interface lines so they can be rerouted by cutting traces and adding wires.

One remaining issue - the socket for the mini iWiFi is taller than those for the other two modules.It's not a problem for end users but is for testing. I guess I'll have to find people with each who are willing to test and maybe write a short tutorial in exchange for one of the prototype boards.

56005601

dhouston
- 31st May 2011, 16:47
The new firmware was updated yesterday.Thanks.

Now I'm patiently awaiting the documentation and newsletter.;)

dhouston
- 31st May 2011, 18:08
The new firmware was updated yesterday.Perhaps. The time between laboratory and release with documentation varies from a few days to a few years. The product manager told me they had it working about 10 days ago so nothing is really new. I'll go back to patiently waiting.

Their web site has said for the other long supported EMxxxx modules that the 5 interface lines are (in essence) programmable. I just need confirmation that this is also the case for EM500.
The module utilizes SPI interace and only requires five I/O line to control. Flexible mapping allows your application to use any five available I/O pins.

dhouston
- 1st June 2011, 06:09
OK. I found the new firmware and documentation for the Tibbo. As soon as I'm satisfied with the details I'll get the prototype ethernet shield PCBs on order. They should be here within 2 weeks.

I can do the Tibbo testing. For ConnectOne, I have a nano LanReach but would have to solder headers to it to turn it into a nano SocketLan. I would rather not do that so I need volunteers to test all three ConnectOne modules. I'll give the volunteers an unpopulated PCB and maybe I'll install the SMT resistors and caps as I have those on hand. I cannot supply the rest.

mackrackit
- 1st June 2011, 08:54
I have a iL-SM2144N1-I with headers.

Something looks wrong on your board or maybe I have the wrong part or.... is the top view the bottom of the top view?

dhouston
- 1st June 2011, 12:34
I have a iL-SM2144N1-I with headers.I think Mouser has the PNs confused. I have this one (http://www.connectone.com/media/upload/Nano_LANReach_DS.pdf) and I think you have this one (http://www.connectone.com/media/upload/Nano_Socket_LAN_DS.pdf). The only difference is one has headers and one does not and the one with headers does not have the teensy-weensy humanoid-unfriendly connector shown in Fig. 3-1-1 of the datasheet (p4-1) for ours.

I've been working off the drawings in the datasheets so I think things are OK but I have been jumping back and forth between the two shields as well as two other projects. I'll print out a life-size copy of the .PNG and see if things fit. What, specifically, looks wrong? It mounts in the 10 leftmost holes of the two 15-pin sockets (the nano Socket iWiFi uses all 30 & the iWiFi uses the 2x6x100 socket) with the RJ45 to the left. (Spark Fun has 10-pin and 5-pin 2mm sockets which I hope will work end-to-end for the 30-pinner. They will mail small shipments, saving cost.)

dhouston
- 1st June 2011, 13:06
I now have the Edit function back but with a 10-minute limit which is too short for slow, dim-witted geezers. At least I no longer am pestered by the random phrases - any semi-intelligent bot would quickly figure out there were only 5-6 answers, anyway.

The actual connections for our modules are shown in this post (http://www.picbasic.co.uk/forum/showthread.php?t=14934). That is part of another, much larger project. The other project taking up most of my time is shown here (http://www.davehouston.org/ZarduinoOnoFront.jpg).:D

mackrackit
- 1st June 2011, 13:33
The ones I have been using have the 30 pin molex on the bottom and have been coming with the two ten pin headers on the sides installed. I also purchased 2mm headers that I have not used yet. Maybe the next batch will need them...

The thing that looks wrong, and it is probably the way I am looking at the drawing. When looking down my module with the RJ45 to the right, the serial pins are on the upper header, J7. To me it looks like your drawings show a view from the bottom of both layers. Putting the RJ45 over the EEPROM...

dhouston
- 1st June 2011, 15:14
The thing that looks wrong, and it is probably the way I am looking at the drawing. When looking down my module with the RJ45 to the right, the serial pins are on the upper header, J7. To me it looks like your drawings show a view from the bottom of both layers. Putting the RJ45 over the EEPROM...

That's possible - I was using the pinouts from the data sheets and they may be top views when I was thinking the opposite (or vice versa). Try it with the RJ11 on the left, using the top (coppertone) view.

Here's the latest layout. Can you reduce the size the way scalerobotics was doing? If I do it in Paint Shop Pro, it loses too much detail.
56085609

dhouston
- 1st June 2011, 17:45
That's possible - I was using the pinouts from the data sheets and they may be top views when I was thinking the opposite (or vice versa).Below is the pinout from the data sheet with the drawing flipped over to give a top view and the outline of the RJ45 added.
5610

mackrackit
- 1st June 2011, 18:18
Dave,
Does your data sheet show J8, pins 1-4 being VDD, VSS, RX, and TX (I may have the order off but those are the four pins used on the module I have)

Thanks Walter for scaling.

dhouston
- 1st June 2011, 19:20
Does your data sheet show J8, pins 1-4 being VDD, VSS, RX, and TX I'm using this datasheet. (http://www.connectone.com/media/upload/Nano_Socket_LAN_DS.pdf) A tech at ConnectOne told me the pinout was the same on my pinless version.
5612

dhouston
- 1st June 2011, 19:38
I have changed the arrows on the silkscreen to reflect signal direction. That may help.

RX <- 10 (Serial Out)
TX -> A4 (Serial In)
RST <- 11 (In/Out)

mackrackit
- 1st June 2011, 20:10
Doh... I thought I was awake, guess I was not.
I see everything now except J8 PIN 1. GND connection.

dhouston
- 1st June 2011, 20:20
I see everything now except J8 PIN 1. GND connection.Right click the JPG, View Image, then magnify. The GNDs are all just thermal pads that connect to the ground plane which covers both surfaces.

mackrackit
- 1st June 2011, 21:21
Right click the JPG, View Image, then magnify. The GNDs are all just thermal pads that connect to the ground plane which covers both surfaces.
Hmmm, :o
Now I can see it... :D
5621

dhouston
- 2nd June 2011, 02:05
I should have had you look at the others. I think the mini Socket iWiFi is upside down, backwards and, maybe, inside out. I'll try to straighten it out and double check the others tomorrow after getting a bit of rest. I've been putting in more time than is good for a geezer.

dhouston
- 2nd June 2011, 06:03
I think this fixes the problem with the mini Docket iWiFi being upside down, backwards and inside out. The Connect One drawings in the datasheet do not identify whether the views are top or bottom and some even complicate things further by showing topside components on what is a bottom view drawing.

I would appreciate it if those of you who are interested in these shields would download the Connect One datasheets and double-check my work. These all start to look alike after 2-3 days.
56245625

Here is the list of connections for the mini Socket iWiFi with my modified pinout drawing that presents a top view.
5626

There is a mistake in the above drawing - pin 1 should be on the left. I caught it in the layout but forgot to fix the drawing.

mackrackit
- 2nd June 2011, 13:01
I will try to get a chance to study them in the next day or so. Got a client with a problem... luckily it is not on one of my systems :)

dhouston
- 2nd June 2011, 14:54
I will try to get a chance to study them in the next day or so.PM me with your email and I'll email the line drawings I made. You can check them against the datasheets and, if they jibe, check them against the layout .PNGs

dhouston
- 3rd June 2011, 19:21
I have offered the Gerbers to Connect One in exchange for their reviewing the layout. Stay tuned.

5639

Demon
- 4th June 2011, 16:30
Why the offset square pads?

Why not place them at right angles, or make them round?

The one on the left above the I2C eeprom looks like a recipe for disaster (from a home-brewed PCB perspective).

HenrikOlsson
- 4th June 2011, 18:05
Hi,
I had decided not to stick my nose into this but I'm going to anyway....
What are the reasons for not using the USART pins but instead using some ordinary I/O pins for serial in and out? The USARTs RX and TX pins are on 00 and 01 on the AMICUS18 which is what this forum section is about. Taking a quick look at the XINO Basic it TOO lists pins 00 and 01 as the USART RX and TX pins when used with the PICAXE chips listed there.

The PICAXE28X2 is just an 18F25K22 with some firmware so it TOO has the USART pins on RC6 and RC7 which then connects to pins 0 and 1. The AMICUS18 uses the 25K20 which also have the USART on RC6 and RC7.

Are these devices (nanoSocketLAN) not meant to be connected directly to a microcontroler with an USART thus expecting "true" data? Is the reason for not using the USART that they expect inverted data (I can't imagine that) and therfor you are using plain I/O and bit-banged serial where the polarity can be inverted instead of the microcontrolers onbaord USART?

I know you're providing pads so it can be re-wired but there must be a very specific reason for not wiring RX and TX to microcontrolers USART where they belong.

/Henrik.

mackrackit
- 4th June 2011, 18:29
The ConnectOne uses TRUE mode.
I like to leave the USART open for interruptible input to the MCU.

dhouston
- 4th June 2011, 21:23
I know you're providing pads so it can be re-wired but there must be a very specific reason for not wiring RX and TX to microcontrolers USART where they belong..It's mostly because the various bootloaders are coded to use the hardware USART. And, I tend to think of these as development systems for READ (Rapid Embedded Application Development) where there will be a lot of changes, trials, errors, etc. rather than as finished products that stand on their own although they can certainly be used that way, as well.

DISCLAIMER: This thread and the Tibbo thread were not intended to disparage your WizNET approach. I'm just of the opinion that most folk are as lazy as me and use various Basic dialects so they don't have to learn ASM, C, etc. In that vein, both the ConnectOne and Tibbo modules do most of the heavy lifting that you're doing with SPI in your thread, making life easier for those of us inclined to take the easy way out. The Tibbo module requires coding but it's all in another Basic dialect and gets loaded as firmware into the Tibbo module rather than using much code space in the MCU be it PIC, PICAXE, Arduino AVR, or ZBasic AVR. And, it was fairly easy to design the shields so all the various modules (except for the 4 Mb flash) are plug-ins - no soldering required (I suspect the Tibbo & ConnectOne shields will have the SMT components preinstalled.) :)

dhouston
- 4th June 2011, 21:36
Why the offset square pads?.The diamond shaped pads are those that the user will likely need to solder in wire jumpers to make connections for pull-ups, set the address, etc.

The slightly askew square pads can be used to reroute the IO lines if needed. Cut the trace between pad and the sockets at the board edges and run a wire as needed.

The octagon pads are those which are unused for the hardware setup.

Round pads are in use by the hardware or hidden beneath the sockets.

The one on the left above the I2C eeprom looks like a recipe for disaster (from a home-brewed PCB perspective).I'm not sure how. If you mean for those who make their own boards, I think these will be available with all of the etching, etc. done and even with most of the SMT components preinstalled. The one I think you are referring to is for installing a jumper in case a pull-up is needed on the serial line - I just forgot the pull-up.:o

dhouston
- 4th June 2011, 21:56
I think this really is the final version. It's been reviewed ab blessed by macrackit. I've asked ConnectOne to review it but haven't heard back, yet. This is an x-ray vision (top) view which makes it easier to follow the connections between features.

5641

HenrikOlsson
- 4th June 2011, 23:36
Hi Dave,
OK, but the bootloader does not hold up the UART once the main program starts to execute, you're free to use it as you wish then. But I guess you have your reasons, I just had to ask.

Am I right in that you have the SPI pins on the ConnectOne module connected to the MSSP module on the AMICUS18 so that it can use that interface instead of the bit-banged serial? Never having used the device in question I don't know exactly how much information needs to passed betwteen the module and the microcontroler but bit-banged serial isn't directly fast. I'm guessing it's not that much since any web-content doesn't have to pass "thru" the PIC.

As for the disclaimer. I didn't take it as such and I have absolutely no problem with this, on the contrary, it's why we're here - to share ideas and learn from each other. But it should stays on topic for this forum, which I must admit I sometimes think it doesn't. If these shields can be used with other devices programmed in whatever language that's great but I think we should try keeping it on topic which is MELABS PBP, not ZBasic, BasicX, PICAXE, PROTON, MikroBASIC, C or anything else.

Keep it up!
/Henrik.

dhouston
- 4th June 2011, 23:58
you are using plain I/O and bit-banged serial where the polarity can be inverted instead of the microcontrolers onbaord USART?Ahh, methinks you presume too much.;)

On the rare occasions when I use a PIC bigger than the 8-pinners, I use ones where the comparator inputs and outputs are exposed. I use them as inverters for TX & RX. (@Bruce: On the 16F88, this uses up 6 pins so I'm just barely violating my 8-pin limit.:p) Most of the PICs, PICAXEs discussed in relation to these shields qualify and the Xino designers have agreed to look into making this optional in the DS30 bootloader. You only need current limiting resistors in TX & RX and it looks easy to add these to most of the Arduino clone main boards I've seen.

dhouston
- 5th June 2011, 00:25
Am I right in that you have the SPI pins on the ConnectOne module connected to the MSSP module on the AMICUS18 so that it can use that interface instead of the bit-banged serial?.
All that I've connected in these designs are the serial IO pins along with any modem control lines that they expose. I've never explored the other pins on the ConnectOne modules so I did not want to complicate things (nor add to the support burden for a project where I'm donating the design). Some of their modules also have a USB interface but I have no clue as to how to apply it. Readers are free to discuss these and even suggest how to add connections to handle them but I have no such plans.

mackrackit had earlier published example code (http://mackrackit.com/mac/ichip/ichip.html) for one of the ConnectOne boards and I posted a link to it in the new Ethernet section. As you can see, all you need to send it are AT command strings like we did with modems back in prehistoric times. Crude, but effective and easy, even for novices. The code burden adds up and mackrackit suggested the EEPROM might help address that but I really haven't explored idea that either.

As for whether the ConnectOne and Tibbo shield threads are 100% on topic I'm not sure there's any other section that would be more appropriate. While my design goals were to make these shields as universal as possible, they will work with the Amicus18 system as well as with most of the other Arduino and Arduino-inspired systems. And while I have mentioned some others, I've refrained from promoting them - I've merely noted that some design decisions were made to maintain PICAXE compatibility - usually in response to questions.

dhouston
- 5th June 2011, 00:49
OK, but the bootloader does not hold up the UART once the main program starts to execute, you're free to use it as you wish then. But I guess you have your reasons, I just had to ask.Well, I had never heard of Amicus18 nor any of the other Arduino clones before a few days ago so it may be partly due to ignorance. And wanting to make my designs as universal (and low cost) as possible, I thought the safest route was to use the software UARTs for access to these ethernet<->serial adapters. I usually use DEBUG/DEBUG_IN myself so it was somewhat out of habit that I chose this route. In most cases, the software UARTs should be fast enough for the types of things we might want to do via these adapters. There's also the possibility that another shield in the stack might need the USART. But feel free to cut the traces* and reroute as you wish.

*jump the traces (http://www.sky-net-eye.com/eng/english/idioms/american/i_k/4421-kick-over-the-traces) seems somehow appropriate here - but you probably need to be my age and remember teams of horses pulling things (beyond Budweiser wagons) to understand why.

dhouston
- 5th June 2011, 06:10
Am I right in that you have the SPI pins on the ConnectOne module connected to the MSSP module on the AMICUS18 so that it can use that interface instead of the bit-banged serial? Never having used the device in question I don't know exactly how much information needs to passed betwteen the module and the microcontroler but bit-banged serial isn't directly fast. I'm guessing it's not that much since any web-content doesn't have to pass "thru" the PIC.I could have done a little better job of addressing this. Perhaps, not for Henrik who, I think, understands, but for others who might be lurking (maybe even Darrel's brothers Darrell and Larry). To take the nano Socket iWiFi as an example, its SPI, USB & RMII pins are available to the user but only in the octagonal pads adjacent to the socket into which the module is plugged. The user can add wires and route them to the card edges where the pins of the system bus (for lack of a better term) are available. Since I was trying for a universal design in keeping with the phrugality philosophy of the Xino cards, it did not make sense to connect features that might not exist in the 18 pin PICAXE. And, the information that needs to pass between the MCU and ethernet module is much less than is needed with the SPI and registers approach of other shields and ethernet<=>serial adapters. Bruce has posted that DEBUG works up to 115200 for him and that's much faster than we might need here. The Tibbo module requires even less traffic between it and the MCU as it does even more with less input.
As for the disclaimer. ... If these shields can be used with other devices programmed in whatever language that's great but I think we should try keeping it on topic which is MELABS PBP, not ZBasic, BasicX, PICAXE, PROTON, MikroBASIC, C or anything else.I've tried to keep with the spirit of that but it is easy to stray given the history of my involvement with the topic. I only started with shields in the past week or so but I had designed a much larger project just over three years ago that was to have used the Tibbo EM202. When it was suddenly withdrawn, I was stuck with about 100 nearly fully assembled PCBs. I learned much of what I know about the other ethernet<=>serial adapters because I was desperately searching for a way to salvage a few thousand dollars in inventory and labor. None was suitable with all requiring Goldbergian methods to fit them into my enclosure and connect them to existing pads. I finally gave up. I had major health issues that also intervened. When Tibbo finally released the EM500 (which they had promised me would be a matter of weeks) two years later, my interest was revived but I wanted to wait until they released the firmware to allow it to support the GA1000. And I am still leery of ordering newly designed boards before I can thoroughly test the combination. The whole concept behind the shields caught my attention because it allowed a way to test "subsystems" without the cost of building the full system. My Tibbo shield will allow me to do this with the side effect of giving all of the Amicus18, Arduino, et al another useful shield designed to be easily assembled.

The PCB below is most definitely "off topic" but it should give everyone an idea of why I want to be able to use the shields as platforms for rapid development and testing. It is my redesigned PCB for my 3 year old project. It is also why I find the idea of doing it or similar projects on a more modular basis with multiple shields attractive. Developing a new shield that used a different ethernet<=>serial module would have been much easier than trying to shoehorn one into the existing, more complex design. Right now, I'm undecided between using the board below and designing 4-5 shield to duplicate its functions.

5643

dhouston
- 6th June 2011, 12:41
The shield development is on hiatus. I have medical appointments & procedures scheduled for most of this week. I'll pick it up once those are behind me.

There is an issue to be solved before I get prototypes made - all official Arduinos are 5V only so these 3V3 devices cannot be used with them. I do not want to add voltage regulators to the shields so need to find a practical solution for a 3V3 clone. There are 3V3 compatibles but the overall picture is very murky.

mackrackit
- 6th June 2011, 13:15
all official Arduinos are 5V only

Seems that Arduino is behind the times and needs to catch up then.

HenrikOlsson
- 6th June 2011, 14:08
Hi Dave,

Arduino is not AMICUS18 and XINO is not Arduino - simple as that. I looked at the datasheet for the ATMega 328 which I believe is what is used on the Arduino. It operates on anything from 1.8 to 5.5V so THAT won't be a problem. If the Arduino contains a voltage regulator and the option to actually RUN it at 3.3V instead of 5V is another question.

I think it, in the end, boils down to this: Either you make these shields of yours compatible with "everything" that happends to have the same same board shape as the Arduino, meaning you include voltage regultors and level translators or you don't.

If you don't want voltage regulators and level translators on the shield(s) then the decision is made: Your shield will work with boards operating at 3.3V, which is good because that's what the AMICUS18 does. It won't directly work with boards running on 5V.

One possibillity is to include foot prints for voltage regulator and level translators and more pads allowing them to "wired in" but then it'll soon start to look like a breadboard and not a "plug and play shield".

/Henrik.

Gevo
- 6th June 2011, 15:01
Hi Dave,

My again.

Arduino (Atmel) and Amicus18 (PIC) are different platforms. The board and shields are outline the same. Not electrical.

You can update a Amicus18 board (or clone like the Ami18 board) to a PIC18F25K22 The Amicus IDE and free Proton Compiler (V 1.0.1.6) support the PIC18F25K20 (3V3) and the PIC18F25K22 (5-volt)

Regards,
Gevo

dhouston
- 6th June 2011, 21:37
Arduino is not AMICUS18 and XINO is not Arduino - simple as that. I looked at the datasheet for the ATMega 328 which I believe is what is used on the Arduino. It operates on anything from 1.8 to 5.5V so THAT won't be a problem. If the Arduino contains a voltage regulator and the option to actually RUN it at 3.3V instead of 5V is another question.
Henrik, I agree with your points.

I envisioned this more as a prototyping/testing platform in the spirit of the Arduino ethos: Open Source Electronics Prototyping Platform (printed on the Arduino Uno box) and wanted to keep it as universal as possible. But, the different voltage requirements add complications I had not forseen. Had I designed the Arduino or the Amicus18 I would have made both powered externally from either 5V or 3V3 Switch Mode Power Supplies which can supply high amperage. But, I'm having to adapt to what's already on the ground. I've never had any plans to produce these myself.

I will stay with 3V3 and make it necessary for the end user to verify the supply voltage and solder in a jumper as needed. I will look at adding the footprints for a regulator and necessary caps, etc. but these will be SMT (there's limited free space) so neophytes will be better off with a 3V3 main board (Amicus18 or compatibles). If Xino or others want to offer the boards, it will be up to them whether to stock them with/without regulator, et al or supply one version with regulator and jumpers. The ConnectOne (and Tibbo) modules plug-in so these still are good for testing before deciding on a final (perhaps unrelated to this form factor) design.

For my own testing and protyping, I think I can adapt an Arduino Duemilanove to use only external power and then use 5V or 3V3 as needed. I also need to replace the 20MHz crystal with a socket so I can choose 14.7456MHz or 7.37MHz depending on MCU (ZX-328n, ZX-328l) The Mega328P can use lower voltages but needs a slower clock speed to reduce the current draw.

Finally, ConnectOne has agreed to have an engineer review the plans. This means I do not need to find testers for each incarnation.

dhouston
- 7th June 2011, 05:11
I will stay with 3V3 and make it necessary for the end user to verify the supply voltage and solder in a jumper as needed. I will look at adding the footprints for a regulator and necessary caps, etc. but these will be SMT (there's limited free space) so neophytes will be better off with a 3V3 main board (Amicus18 or compatibles). The last post was written shortly after returning from several medical appointments. After, I had a bit of rest and then looked at what is involved, i think it will be a simple matter to add a 3V3 LDO (low dropout regulator) and and just one jumper arrangement so the user can solder in a wire based on wehether the system voltage is 3V3 or 5V.

For Connect One, none of the three modules have 5V tolerant inputs and 3V3 may not be seen as logical high by the MCU running on system power of 5V so I will need to add level conversion to the RX, TX & RESET lines. I'll use transistors for this and the same circuit will work at 3.3V as well, meaning no additional jumpers are required.

For the Tibbo shield, the EM500 inputs are 5V tolerant and its output circuitry is such that merely adding a pull-up to 5V works on TX. This also will work equally well whether the system voltage is 5V or 3V3 so, again, no additional jumpers.

I think this is about as straightforward as is possible. I want to use just solder pads rather than a jumper/header so the user will have to think a bit and focus in order to understand the why and wherefore before installing the semi-permanent wire jumper and, hopefully, reduce the possibility of users quickly inserting a jumper on a header in error and blowing a ConnectOne module worth $30-60. But, I'll leave the final decision to Xino and anyone else who wishes to build & distribute these.

dhouston
- 9th June 2011, 22:22
Am I right in that you have the SPI pins on the ConnectOne module connected to the MSSP module on the AMICUS18 so that it can use that interface instead of the bit-banged serial?As I responded earlier, all pins are accessible and the user can route them as desired. However, I need to add the caveat that they should only be connected to a 3V3 device. While I have added the LDO and have added circuitry needed for level conversion on the TX, RX & RESET, I will not be adding level conversion to the other lines, not even SCL & SDA used for the I2C bus so these features will need a 3V3 system. There's just not enough real estate on these boards for the additional circuitry.

dhouston
- 9th June 2011, 23:52
Never mind - I had not thought the 5V-to-3V3 conversion through. While 5V-to-3V3 conversion is straightforward, things get complicated when trying to use the same circuitry in a 3V3 system - it requires far too many jumpers. Adding to that are the other pins on some of the ConnectOne modules, SPI, RMII, etc. which complicate things even further.

So I'll just go back to a silkscreen warning that the ConnectOne shield is 3V3 only. It will work with the Amicus18 and other compatibles with 3V3 system voltage.

OTOH, the Tibbo ethernet shield is easy to use with either voltage, requiring only a single jumper to select the system voltage so I will add an LDO regulator to that PCB.

An interesting side note is that the Arduino Uno reference design shows optional 5V and 3V3 regulators so there are probably a lot of Arduino compatibles that are 3V3.

dhouston
- 18th June 2011, 19:46
What are the reasons for not using the USART pins but instead using some ordinary I/O pins for serial in and out?Henrik,

Looks like I need to rephrase my previous response.:o

I had assumed PICAXE was using the hardware USART to download their program. While reading their user manual, I learned they are instead using SerIn/SerOut (i.e. software UART) for downloading and recommend leaving it free to avoid false triggers or interference with downloads. I will modify the ConnectOne and Tibbo shields, accordingly.

mackrackit
- 22nd June 2011, 16:16
An EEPROM sample can be found here.
http://www.picbasic.co.uk/forum/showthread.php?t=15059&p=104461#post104461

dhouston
- 2nd July 2011, 21:27
I have made some changes in order to use this with my Zarduino system boards (http://davehouston.org/Arduino.htm). In addition to rerouting the I2C bus and RESET lines, I have also modified it to work with 3V3 or 5V but only when using the default serial connection. You can use SPI, USB or RMII with 3V3 but will need to do your own level shifting for 5V (which is not very practical).

jellis00
- 11th July 2011, 01:24
One remaining issue - the socket for the mini iWiFi is taller than those for the other two modules.It's not a problem for end users but is for testing. I guess I'll have to find people with each who are willing to test and maybe write a short tutorial in exchange for one of the prototype boards.
56005601
Dave, I am in process of developing an embedded MCU application that will use the ConnectOne Mini iWiFi module. However, your use of the term "ethernet sheild" confuses me. By shield do you mean it provides an RF shield to protect the rest of the PCB containing the MCU from RF emissions? Is this PCB for use only with Arduino boards? Please explain so I know whether your "ethernet shield" would be of use to me.
I would also appreciate your comments regarding whether my PCB layout must take any specific precautions in the layout and grounding techniques to properly interface to the iWiFi via its 2x6 pin header. I am currently planning on creating a "copper pour" area on my PCB that lies under the overlying iWiFi module, but not sure what is really required. I am kind of new to trying to integrate an RF module with an embedded MCU PCB.

dhouston
- 11th July 2011, 02:29
Dave, I am in process of developing an embedded MCU application that will use the ConnectOne Mini iWiFi module. However, your use of the term "ethernet sheild" confuses me.
"Shield" is the term used for all of the boards designed to interface with the Arduino and its many clones - its derivation is a mystery to me.. So, yes, my ConnectOne shield is designed to work with Arduino system boards. You can see JPGs of my various shield layouts on my web site (http://davehouston.org/Arduino.htm).

I usually leave as much copper as possible, both to help reduce EMI and to make the acid etchant last longer. Since the mini uses an external antenna, you will not need the clear area I provided for the onboard patch antenna of the nano.

Unless your application is a one-off design, it might be worth while to buy their evaluation board both for testing and to see how they handle the ground plane.