Why would you go with the PIC18F2550 instead of the PIC18F24J60 - for the 5V/TTL compatible outputs to drive 5V/TTL LCDs?
I must admit that I was a bit uneasy about the missing backlight poti and the 5V/TTL compatibility when I took a close look at the design - which was after you had sent the designs off to Seeed for PCBs
PIC18F24J50 is considerably cheaper than PIC18F2550 ... adding two HC244 line drivers (Vcc = 5V/3.3V selectable) will drive all 3.3V and 5V compatible LCDs around. The only other downside with the PIC18F24J50 I can see is that you need a special debug version of the chip if you want to debug it in-circuit with ICD2/3.
[s:]Did you check the hex file with a hex editor (e.g. HxD) ... maybe the addresses are really filled with 0xFF.[/s:]
You can't use the simulator/debugger to disassemble code if it contains no debug information! I'd expect a bootloader to be stripped of all debug information.
If people want to find something to complain about, they will find something!
I will not waste my time by going into every single detail Moogle posted to make the Arduino Uno PCBs/design look bad. Let me just quote what he says regarding the octagonal pads used for vias on the Uno:
Quote
... They wanted to make the arduino uno fcc approved… so they used octagonal pads for vias… If my knowledge is correct then these edges can make more noise then a standard round via. There are also many traces that are poorly placed and have very zig zag patterns with non rounded corners…
We had the discussion about right-angle bends in full-speed USB traces ... it started out very similar (to my knowledge, what I have heard/read ...) and fortunately led to a discussion based on scientific research results and common logic rather than on assumptions, gossip and emotions. Ardunio (Uno) runs on a 16MHz clock ... 33% more than 12MHz full-speed USB 2.0 ...
If someone has a working board in his hands and "thinks" that it may not comply with EMC regulations/guidlines than he/she should set up/go to a lab and test it for EMC or explain by use of accepted guidlines or scientific arguments why it will or better does not comply before instinuating that it's a bad design (regaring EMC).
The next day Moogle posted an apology which is rather half-hearted and does neither take back nor address his unsound instinuation that the Arduino Uno may have EMI (noise???) issues. At least he figured out what "making" is all about when filing and sanding off the sharp edges and resoldering the badly aligned header the other day ...
I agree with rsdio's last post regarding production cost/quality and with what he said about the USB and power supply part of the Arduino Uno. Regardless if the next Arduino design will have a dedicated USB MCU besides the main MCU or use one MCU with integrated USB the designers will have to address/improve on two issues:
The idea may not be rediculous at all ... but I am inclined to say that I don't expect any of the next revisions of the OLS (!) to include a fast ADC nor any Cypress EZ-USB HS controller. The reasons are simple:
1. a lone (single channel) ADC without input buffers/stage on the OLS makes no sense in a tool (the purpose of the OLS) however, a fast two channel ADC without an input stage would make sense as it would allow to "experiment" with different input stage designs like the unbuffered wing header allows to experiment with different probe buffers or even I/O extensions.
2. The Cypress EZ-USB MCUs are rather limited regarding their general MCU performance and USB features - if we'd move to a specialized USB controller I think it will rather be a FT2232H or Vinculum-II (it would add fast JTAG capability among other features basically for free). However, if we want to give the OLS stand-alone capability or streaming capture capability (with a bandwith sufficient for fast SPI capture) we will have to look at 32-bit MCUs with a USB 2.0 HS controller (e.g. AVR32UC3A3/A4, SAM3U ...)
I see common ground between a fast ADC/FPGA based software/digital radio receiver, a spectrum analyzer and a RFID spoofer/analyzer making use of the same hardware design ... those who are interested could join and start such a project and I am quite sure they will get support if needed by those members who have experience with FPGAs and fast ADCs
I am very sorry to see this obvious QA issue with irrenhaus' OLS. We should consider to add a step in the final testing instructions for Seeed that will actually test the SPI connection between the PIC and the S3E ... and have Seeed preload both the latest firmware for the PIC as well as the latest (most stable) bitstream for the FPGA starting with the next batch.
The OLS Watterott sells are from Seeed originally (so they seem to have received them via Sparkfun). However, the OLS boards Watterott sells are identical with the latest version Seeed sells except that they may have 20MHz crystals for the PIC instead of the 16MHz crystals used on the latest batches. This has no influence on the functionality as long as the 16MHz PIC firmware is used with boards that have a 16MHz crystal and 20MHz PIC firmware is used with boards that have a 20MHz crystal.
@irrenhaus: From some info you posted I take it that you are just a few miles (actually less than 15km) from where I am. If you need a replacement fast and are at DA or even at TU DA I could give you a working, updated OLS in exchange for the one you have. I will take care of the return/replacement process then ... send me a PM if
The DEM16217-SYH-PY has anode and cathode for the backlight at pos 1 and 2 of the header so I had to "pull them to the back" on the backpack (see attached picture).
Your package with the 3 boards/kits/PCBs arrived this afternoon - Thanks!
Thanks for the notes regarding the GND pin of the vcontrast/vee pot on the mini and the micro. Will fix/check this and start testing later this afternoon after I have packed the shipment for Michael.
I haven't sent the other parts yet as I am still waiting for the 16MHz SMD crystals which were due to arrive last Friday but are supposed to arrive tomorrow now.
Switch on the stove/microwave so the meal is ready when you enter your home or turn up the AC/heater on the way home ... alarm systems on rather large real estates ... activate some sleeping beauty you don't want to be any close to when she wakes up.
It makes for a rather interesting read and it seems that ITead can be considered a good (spirited) source ... The projects they seem to be developing on their own display creativity, imagination and innovation:
Those are examples of not just cloning other designs but advancing/improving designs (Iteaduino v1.1 and ITDB01) and creating interesting new designs (ITDB02 and PCI POST diagnostic card)! This is a design house & shop to be watched.
/EDIT/ What I forgot (because I intended to keep it to myself ): ITeads STM32 Development Platform : IFLAT-32 is by far the most flexible low-cost STM32F103 development platform I have seen so far. It combines compatibility with Arduino shields, XBeee modules, Nordic 2.4GHz modules and a header that breaks out all remaining I/O pins of the STM32F103 and accomodates all their ITDB02 2.4" and 3.2" TFT LCD modules (not to mention the microSD card holder and the 20-pin JTAG header + a 7-pin header for the Cortex-M X-Link debugger). A very creative design. /EDIT/
Over the years I have come to the conclusion that all (root but also virtual) servers of the big server providers/hosters - that is those in the known IP address ranges of their server farms - are constant priority target of professional attacks. The reason seems simple: a lot of users without any profound knowledge of security and how to make a server secure rent those servers and it's fairly easy to highjack many ... by looking at the log files of my servers it became obvious that the hackers use bots/automated tools to try for passwords, known ports and exploits in standard applications that run on many servers (Apache, MySQL, SMF, TeamSpeak etc ...). An administrator who works for one of the largest hosted server centers in Germany told me that on most servers attacks (attempts) generate more traffic than the regular/intended use.
Jack should rather stay on the safe side than make his security too lax ... in the end he provides the server space for the SVN for free and those who want to download code can contact him in the rare cases when access is denied.
Pinguino is a great concept ... I tested it with a PIC18F4550 based board and was surprised how well the integration of the Arduino IDE, the SDCC and GPUTILs has progressed. It's a real open source environment (makes no use of the Microchip toolchain) and all PIC fans who always wanted an Arduino-like PIC18 environment should give it a try.
): ITeads