Show Posts
Pages: [1] 2
1  Development / Other Hardware Development / Re: PCIeDuino: feedback on Arduino clone design on a mini-PCIe card on: September 01, 2014, 09:05:27 pm
MIght be a fun application for the upcoming Arduino ZERO.

Oh, yes, that works on 3.3V as well, thanks for pointing it out! Might not be the first version, as I'd like to keep it simple using components only from Seeed Studio's Open Parts Library but definitely good to consider. Cortex-M0+ got a lot of exposure these days, need to see how does that compare to the other available options.
2  Development / Other Hardware Development / Re: PCIeDuino: feedback on Arduino clone design on a mini-PCIe card on: August 26, 2014, 03:32:04 am
Thanks for the comment on the DTR, will check it out! The circuit is still "in progress" and some parts are more "copy-paste" than complete understanding, but won't print anything until I know exactly how the different parts work.

For the LEDs I included them because it's not 100% to be within an enclosure, it's just quite likely. E.g. the VIA Springboard I have here has the mini-PCIe on the front does not necessarily have an enclosure, and it would be great to see it right away (without any extra parts) that it works, e.g. "doing the blinky" with onboard components only. Another board, the VAB-820 has the connector on the bottom - there it's not much help. Others want to put it inside a laptop, that's nothing at all... I think, though, that it's a good general principle to be the most useful, even if it has functions that are not utilized by some users. That's why I'd like to include TX/RX LEDs, and probably add a Power LED as well for easy troubleshooting.
3  Development / Other Hardware Development / Re: PCIeDuino: feedback on Arduino clone design on a mini-PCIe card on: August 26, 2014, 01:59:37 am
In the meantime I've posted the same question to the Arduino sub-reddit, and there's a bunch of very interesting feedback. I thought I share it here as well, might be helpful for other people designing Arduino-compatible devices

1) USB-Serial

Some question of the choice of the FT232RL for USB-to-Serial. It's not clear whether it's a "bad" choice, but it's clearly "not as good as could be", because of people's experience with the newer Arduinos raised the bar: more people want USB-HUD experience (mouse/keyboard emulation). Because of that some people suggested either using the ATmega32u4 as an USB-to-Serial serial chip in addition to the core, or even just using the USB-to-Serial functionality in firmware of that chip. I got to look into that, it looks interesting idea (especially the latter), but don't understand the practicalities of it just yet.

2) Choice of MCU

It was suggested to use other chips than the ATmega328P-AU that I'm going with so far. Either the ATmega32u4 as mentioned above, or if possible then an ARM Cortex-M4 instead like Teensy 3.1. These look interesting too, though probably not at first, but as I gain more confidence and experience in designing these and the requirements of the different chips. The 328 is already proven on 3.3V, and for a start it would work "okay" for sure. Still, it's awesome how many choices there are now.

3) PCB design

People commented that besides the "row-of-pins" arrangement like on the Arduino boards, there are other ways for breaking out the I/O in a more usable way (especially for a board that might be inside another computer like this.

  • More pads on the PCB surface for easy soldering to
  • I/O+VCC+GND combo pins like some servos
  • Break out additional lines from the mini-PCIe if available

These can be tricky, because the surface real estate is quite small (51x30mm altogether, and some of it is lost to the mandatory screws), so definitely cannot cater for everyone. Will need some more input on this, and likely more research on how others are doing this.

That's mostly it so far... I'm trying to figure out some more details about the PCIe connector (in particular whether I should use AC coupling capacitors on the USB2.0 lines coming in? and wiring the power lines for PCIe specs compliance and low noise.).

4  Development / Other Hardware Development / PCIeDuino: feedback on Arduino clone design on a mini-PCIe card on: August 24, 2014, 10:53:03 am
Hi,

At work I have a bunch of single-board embedded computers that have a mini-PCIe card slot onboard, which provides access to one USB 2.0 line. I thought that it would be cool to put an Arduino on a mini-PCIe card, and thus having pretty much an onboard Arduino for these computers.

Here's an "artist's impression" of what it might look like:

This is not to scale, the mini-PCIe card is 51x30mm in size, but the Nano is even smaller so it should work. The power line of the card is 3.3V so my inspiration is a mixture of the Arduino Pro (ATmega328P, 3.3V, 8MHz) and the Nano (onboard FTDI).

I've made a draft schematic with KiCAD, and would love to have some feedback on it! I'm not 100% sure if I have connected everything the right way...

The schematic is here: http://www.slideshare.net/imrehg/pcieduino (or if you suggest me a better way to share it I'd love to hear).
One part I'm not entirely sure is which of the multiple 3V3 and GND pins of the mini-PCIe connector I should get my power and ground. Does it really matter?

So, what do you think? Anything I've messed up? Missed? Should include? Should exclude?
5  Using Arduino / Interfacing w/ Software on the Computer / Re: Arduino Mega ADK Serial.print stale data issue on: October 18, 2012, 11:30:18 pm
The header is in the receiver code (so I can pipe it into a file just like that), and should signify the point where my PC is ready to receive the data.

The code on the Mega ADK is this one: https://github.com/imrehg/sketchbook/blob/master/Thermocouple5/Thermocouple5.ino

The receiver code is something like this in Python (with just the relevant parts shown):
Code:
dev = serial.Serial('/dev/ttyACM0', baud, timeout=1)
print "#HotJunction(C),ColdJunction(C)"
while True:
    print dev.readline()

I got around the problem a bit by throwing away the first 50ms data or so:
Code:
dev = serial.Serial('/dev/ttyACM0', baud, timeout=1)
delay = 0.05    # seconds
finish = time.time() + delay
while time.time() < finish:
    dev.readline()   # just reads but not prints
print "#HotJunction(C),ColdJunction(C)"
while True:
    print dev.readline()
In this case the buffer is received but not printed first, then later started to print the real (new) data.
6  Using Arduino / Interfacing w/ Software on the Computer / Arduino Mega ADK Serial.print stale data issue on: October 05, 2012, 03:25:35 am
Hi!

I was using a sketch that sends some sensor data over Serial to the computer, and had a python script to read it. It was running on a Diecimila-equivalent board. Now I have an Arduino Mega ADK, and run the sketch on that one. The problem I have, that first when read the serial on the computer, all I receive is a lot of stale buffer, then the board resets, then starts to read correctly.

To illustrate it, one example output reading the data received in on the computer side:

Code:
#HotJunction(C),ColdJunction(C)
31.25,0.69,9046
31.25,30.69,9548
31.25,30.69,10050
31.25,30.69,10553
31.25,30.69,11056
31.25,30.69,11558
31.00,30.69,12061
25,30.69,9046
31.25,30.69,9548
31.25,30.69,10050
31.25,30.69,10553
31.25,30.69,11056
31.25,30.69,11558
31.00,30.69,12061
0.00,0.00,0
30.25,30.25,501
30.25,30.31,1004
30.50,30.37,1506
30.50,30.44,2009

The first line is the header, printed after I connected to the board, but haven't read anything yet. Every line then is 3 comma-separated values: sensor reading, another sensor reading, finally a timestep in milliseconds since bootup. E.g the data line 31.25,30.69,9548 would be Sensor1=31.25, Sensor2=30.69, timestamp=9.548s since bootup.

Looking at the data, what I actually received:
  • 7 lines of stale data (lines 1-7)
  • A broken repeat of that stale data (lines 8-14)
  • Correct data after reboot (lines 15 up)
The amount of stale data is different run by run.

Where does this behaviour come from? I feel it's some buffering issue. Is there a way to avoid it? I guess it's a Mega ADK issue, because with the old board I haven't seen this. Might have to do something with the fact that there are so many serial lines on that board, and I guess the firmware control is different?

What I do now, is that I throw away whatver I read in the first 10ms of starting the computer-side script. It fixes things in a hackish way, but I'd love to understand what is actually going on there, and have a better way to do that.
7  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 05, 2012, 01:53:58 am
Try halving the baud rate in boards.txt and restarting the IDE.

It has the same result.
8  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 10:56:22 pm
I wouldn't be too worried about non-implemented bits reading back with 1 set. That does happen. According to the fuse calculator:

http://www.engbedded.com/fusecalc

both settings of the extended byte mean the same thing (the boot size).

Quote
Any other pointers what else to try?

I am wondering about the clock rate. Is this board running at 16 MHz? Also have you got the correct board selected in the Board menu? (Yes, I know it is a beginner question, but that is what I would be checking).

Also can you turn on verbose uploading information, and copy and paste the output you get when trying to upload a new sketch? Thanks.

It's 8Mhz. Yeah, I keep checking the settings in the boards menu as well to be sure. Since I burned the the Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168 firmware, I keep choosing that one.

The output is this:

Code:
hardware/tools/avrdude -C/home/lab/Greg/arduino/hardware/tools/avrdude.conf -v -v -v -v -patmega168 -carduino -P/dev/ttyUSB0 -b19200 -D -Uflash:w:/tmp/build7496679973925227559.tmp/Blink.cpp:i

avrdude: Version 5.11, compiled on Sep  9 2011 at 16:00:41
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/home/lab/Greg/arduino/hardware/tools/avrdude.conf"
         User configuration file is "/home/lab/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : arduino
         Overriding Baud Rate          : 19200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

avrdude done.  Thank you.
9  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 05:06:42 am
The flashing works, verifies. Noticed that after flashing, the reported Extended Byte and Lock Bits are not the same in the detection code as set here. Is that normal behaviour?

What are they, then?

Flashing this:

Code:
{ { 0x1E, 0x94, 0x06 }, "ATmega168V",  16 * kb,       256,
        ATmegaBOOT_168_atmega328_pro_8MHz_hex,   // loader image
        0x3E00,               // start address
        sizeof ATmegaBOOT_168_atmega328_pro_8MHz_hex,
        128,          // page size (for committing)
        0xC6,         // fuse low byte: external full-swing crystal
        0xDD,         // fuse high byte: SPI enable, brown-out detection at 2.7V
        0x04,         // fuse extended byte: boot into bootloader, 512 byte bootloader
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

i get

Code:
LFuse = 0xC6
HFuse = 0xDD
EFuse = 0xFC
Lock byte = 0xEF

As another try, if I flash 0x0F for lock byte (as in the boards.txt), i get 0xCF as lock byte in the verification part.

From the fuse checker site it seems to me that 0x00 or 0x04 (the code and in boards.txt) are not really valid values for the Extended Fuse? E.g. 0xFF is a valid value, and that indeed flashes as such.

Hm.... Any clue in this?
10  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 03:59:00 am
- the fuse values are quite different from what I used before, the settings I got from this blog post.

Conceivably what happened was you interrupted the fuse writing at a bad moment. Also what that blog says (the parts I can understand) relate to what the fuse settings are changed to when you upload a bootloader, not when you upload a sketch.

I found some supplementary material from the magazine where I got this Japanimo board. They have an instructional pdf, where they basically say it is an Arduino Pro Mini (3.3V,8MHz)w/ATmega168.

Thus, looking at your code, I tried to flash with these settings:
Code:
  { { 0x1E, 0x94, 0x06 }, "ATmega168V",  16 * kb,       256,
        ATmegaBOOT_168_atmega328_pro_8MHz_hex,   // loader image
        0x3E00,               // start address
        sizeof ATmegaBOOT_168_atmega328_pro_8MHz_hex,
        128,          // page size (for committing)
        0xC6,         // fuse low byte: external full-swing crystal
        0xDD,         // fuse high byte: SPI enable, brown-out detection at 2.7V
        0x04,         // fuse extended byte: boot into bootloader, 512 byte bootloader
        0x2F },       // lock bits: SPM is not allowed to write to the Boot Loader section.

The low byte and high byte are copied from the boards.txt appropriate for that Arduino Pro Mini. The extended byte and lock bits are from the ATmega168PA settings of your code. The  start address is also copied, I have no idea where I could get the correct value.

The flashing works, verifies. Noticed that after flashing, the reported Extended Byte and Lock Bits are not the same in the detection code as set here. Is that normal behaviour?

After flashing, still nothing happens. Meaning, connecting the board to the PC the USB shows up, but no communication, not able to flash a new sketch. The loopback test works just fine.

Any other pointers what else to try?
11  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 01:39:14 am
The chip detector does not erase or change anything.

Yeah, of course, the chip detector just reads. I meant that the original problem of interrupted upload or something that I did before hand, messed up the bootloader.

I would not expect the bootloader to start with zeroes. And if the sketch is all 0xFF that looks like an erased program.

So should I try to reflash the bootloader (probably with your Atmega Board Programmer sketch) and see what happens?
12  Using Arduino / Installation & Troubleshooting / Re: Interrupted sketch upload results in bricking? on: October 04, 2012, 12:50:02 am
Hi, finally got the Chip Detector sketch working. The chip on Japanimo is ATmega168V-10AU, added the signature to the sketch such as:

Code:
{ { 0x1E, 0x94, 0x06 }, "ATmega168V", 16 * kb,       256 },

The 16kb I know, the 256 bootloader size I just guessed based on the rest of the chips. The output of the detection is the following:

Code:
Atmega chip detector.
Entered programming mode OK.
Signature = 1E 94 06
Processor = ATmega168V
Flash memory size = 16384
LFuse = D2
HFuse = DE
EFuse = F8
Lock byte = FF
Clock calibration = B3
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 256 bytes starting at 3F00

Bootloader:

3F00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3F80: 57 00 E8 95 00 91 57 00 01 70 01 30 D9 F3 01 E1
3F90: 00 93 57 00 E8 95 32 96 02 97 09 F0 C7 CF 10 30
3FA0: 11 F0 02 96 E5 CF 11 24 5C CF F8 94 FF CF 80 00
3FB0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FC0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FD0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FE0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
3FF0: FF FF FF FF FF FF FF FF FF FF FF FF 07 04 06 B3

MD5 sum of bootloader = C5 0A 34 A2 77 92 2E D2 70 BF 65 70 2B 7C 3F 4F

First 256 bytes of program memory:

0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Some observations:
- there was uploaded sketch on this board before, does it mean that it got erased?
- the bootloader area starts with a bunch of 00s, is that normal? Or does that show that there's a problem?
- the fuse values are quite different from what I used before, the settings I got from this blog post.

Any recommendation to get this board working again? smiley
13  Using Arduino / General Electronics / Re: decoupling capacitor size on: October 03, 2012, 06:13:39 am
Quote
so I'll just try some bigger caps than so far.

It is not terribly critical. I usually use whatever I have and I tend to stay small. But starting with what the datasheet suggests helps. And for highspeed circuits, starting with a ceramic disc (monolithic or otherwise) helps as well. I usually avoid tantalum as they tend to fail short. 10nf - 110nf is fairly common.

Tantalum are rubbish for decoupling. So are most electrolytics.

Here's Atmel's advice on decoupling capacitors: http://www.atmel.com/Images/doc0484.pdf


Thanks a lot, this is very useful in general!
14  Using Arduino / General Electronics / Re: decoupling capacitor size on: October 03, 2012, 05:19:54 am
Thanks, it pretty much confirms my understanding. In this particular case I was working on the frequency response is not an issue, so I'll just try some bigger caps than so far.

Cheers!
15  Using Arduino / General Electronics / decoupling capacitor size on: October 02, 2012, 09:28:13 pm
Hi!

I'm making a project with a MAX31855 thermocouple amplifier chip. It has to have decoupling capacitors on the power lines, and also on the input lines. It is a very sensitive chip, and I found I have to increase and increase the decoupling capacitor to have a better behaviour. The spec sheet recommends 10nF, but I found even 1uF has some noise spikes every now and then.

This got me thinking, is there a "too high" value of decoupling capacitor, if my time scale is not too small (0.1-1s) ? Is there any reason why people recommend certain size of decoupling capacitors for power lines or signal lines? How could I think about these in general?
Pages: [1] 2