-
Hi,
im still working on building a scanning controller for my SEM, the first prototype works for a few months now but im at the limit of what a small ATmega can do.
The scan controller is there to output two Voltages for controlling the X and Y position of the electron beam like in any old Oscilloscope. The Voltages are scanned like a TV signal and the Detector usually produces an analog Voltage that has to be read back for each pixel measured.
The Microscope can handle speeds up to normal Video signal at 30 fps with decent resolution but for a high quality image (>1000x1000px) there is several seconds available because of the electron physics involved so the task is not all that crazy.
Now my controller does all this using only one atmega328 and two OPs but this limits me on one hand by the adc speed, the dac resolution and most importantly the transmission speed via the serial interface to my computer that handles the actual image generation and further processing in python.
Something id really like ist just to skip the entire slave controller thing and put DAC and ADC on the raspis gpio but this will not work because everything is timing critical (im open to suggestions though if i messed out on something). So id like to connect an external relatively dumb microcontroler to the raspi, taking the "drive to xy and take a measurement" outside and just returning the pixel value. Either by actually transmitting the coordinates every time or for fast mode sending some short signal to just increment the position after setting the image size before starting the scan.
This will also be limited by the interface between the controller and the raspi. What paths could i choose here? SPI is the best choice i can think of right now.
To give some more specific numbers of what i imagine:
DAC: 2x 14-16 bit
ADC: 1x 14-16 Bit
Slow scan: at least 1500x1500px in 2-5s
Fast scan: 500x500px in 1s
XY Mode: Controlling the beam freely without having to scan by a specific pattern (for lithography)
Data will always end up on a linux machine to be used in python, the closer to that it is generated the better.
An example of what the atmel talking via uart does in 5min so faar:
-
First off....Wow your own SEM...congratulations
How do you coat the subjects? Nice images BTW, please identify.
SPI from the RPi can be configured for various speeds, maybe SPI could be fast enough to directly control the DAC and ADC?
Best, -
Hi & thanks
Yes, it can be used to control the adc and dac directly but timing is an issue, especially unpredictable timing like when the cpu does stuff randomly. Since image quality is the optimization goal and the analog part will behave differently with different timings i dont really want to risk it. One path may be first setting the coordinates, waiting for the dacs and then taking a measurement but the waiting to be on the safe side will throw speed out of the window that i think i will need.
The images are a wasps jaws, a dental implant and the surface of the implant in closeup. -
Wonder if you could use the RPi pigpio hardware output along with the CS to "trigger" the ADC which should produce a stable period. We've experienced the RPi variation in I/O due to internal RPi operations and used the hardware pigpio as an alternative pulse output, we found it stable and accurate in period. So thinking if you used this pigpio to trigger the ADC, results should be a stable sampling period.
BTW how to you coat the subjects, thought subjects need to be "conductive" for SEM?
Best, -
Mhm, like triggering with a fixed delay after the CS of the second DAC has come back from setting new values and then reading the adcs gesults whenever the pi is ready for it? Does the pi have some sort of hardware interrupt on the gpio?
I mean, its not only the period that has to be stable, its also (actually more importantly) the timing between setting new values and measuring.
Ah sry, i overlooked your conductivity question at first.
i dont
i had a borrowed sputter coater for a while but i had to give it back after several months. I tried building my own but actually making one is much harder than the internet suggests, there is a ton of parameters taht need to be figured out mostly by trial and error, like pressures, geometries, materials, current, voltage, power supply impedance and output capacitance, gas and so on. You can just get lucky and nail it if you get the geometry right but well, i didnt. Also gold sputters much better than lets say copper but a >50mm diameter gold plate is an investment i dont want to make before knowing it will work
So right now im stuck with conductive samples but its surprising how many things do conduct at 30kV and just a few nA current. -
Not well versed in the RPi details, I'm sure others here are much more qualified to help regarding the interrupts, but does seem possible to do this directly with the RPi.
The sputtering does sound difficult.
Best,
-
Hi,
im still working on building a scanning controller for my SEM, the first prototype works for a few months now but im at the limit of what a small ATmega can do.
...
This will also be limited by the interface between the controller and the raspi. What paths could i choose here? SPI is the best choice i can think of right now.
...
To give some more specific numbers of what i imagine:
DAC: 2x 14-16 bit
ADC: 1x 14-16 Bit
Slow scan: at least 1500x1500px in 2-5s
Fast scan: 500x500px in 1s
XY Mode: Controlling the beam freely without having to scan by a specific pattern (for lithography)
Congrats, impressive pics already!
What scale are those posted scans?
About the acquisition, it just happens that I've used recently a FRDM-KL25Z board (ARM core MCU based):
https://www.nxp.com/design/development-boards/freedom-development-boards/mcu-boards/freedom-development-platform-for-kinetis-kl14-kl15-kl24-kl25-mcus:FRDM-KL25Z
Mine is from around 2015, when I went to one of the Arrow workshops about Freescale MCUs, but the devboard is still available to order for about $15. In case you pick this board, I still have those workshop classes to start with the board in less than a day or so.
What sets this devboard apart from many others out there is that this model of Freescale MCU has 24 channels of 16 bits ADC, and also two of 12 bits DACs, SPIs, I2Cs, UARTs, DMA, etc. The board can be program as bare metal or with the Freescale MQX OS and interrupt driven, so the time jitter wouldn't be a problem even when you use the MQX OS.
There is a free IDE+config wizards (called Processor Expert) from Freescale for free, so you won't need to learn each bit and each register to initialize the peripherals. The Freescale IDE is based on Eclipse, but the board can be programed as bare metal, too, with nothing but a terminal, a text editor and the GCC compiler, no additional programmer needed (the board uses OpenSDA over USB, with hardware debugging and programming capabilities).
About the data transfer, Raspberry Pi also has SPI, so it would be a breeze to interconnect them by SPI.
Regarding the speed, only a few days ago I've read a couple of SPI Flash memories (to dump the BIOS of a PC motherboard), and to my surprise the max reliable SPI CLK for my setup was 60 MHz (with about 20cm, or 8 inches, of DuPont wires and a RPi from about 10 years ago, model 1B with 256MB, as seen in the pic).
No serial goes that fast, so I'll say SPI would be a better choice to link no matter what acquisition board to a RPi. If you go with SPI link with RPi, you'll need first to enable the SPI module (sudo raspi-config), then to give access rights for the spi devices (sudo chmod a+rw /dev/spi*) then install the spidev module for Python (already installed in more recent OSs, on Wheezy it was not preinstalled), and that's it, capture and process the data from Python.
-
I'm working on the same type of project (electronics for SEM). I settled on the idea that (due to exact timing required), the easiest way to achieve this is with a small FPGA (ICE40). I have a few other things to do before I start on this subsystem, but I hope that the distributor selection of DACs and ADCs will be wider then.
Congrats on the images! -
For the FPGA route, worth considering the $39 DECA board https://www.arrow.com/en/products/deca/arrow-development-tools (apart from a beefy Intel/ALTERA MAX10 FPGA and its internal ADC peripherals, the DECA board also has 512MB of DDR and between others, a stereo CODEC aic3204 from TI https://www.ti.com/lit/ds/symlink/tlv320aic3204.pdf , 24bits/192kHz capable IIRC).
If Xilinx is prefered over Altera, then would worth considering the second hand control boards coming from various deprecated models of dedicated crypto-miners. From China, these boards used to be on AliExpress anywhere between $5-$25 each, depending of the exact model, usually with a Xilinx Zync 7010 or 7020 FPGA and 128-256MB of onboard DDR, e.g. the EBAZ boards https://www.eevblog.com/forum/fpga/ebaz4205-(zynq-7000-based-development-board)/
Both of these FPGA boards can run Linux and have LAN connectivity, so at least in theory a Raspberry Pi wouldn't be needed any more. -
@RoGeorge: Thanks for giving me hope on SPI, more on that later
@samofab & RoGeorge:I really appretiate your recommendations towards fpgas, im aware that taht would be the most appropriate path to go down but sadly my software skill ends at asm, C and Python, im beyond arduino but not very far, learning to work with fpga is on my list but on this project there is so many other things to do than just software, i have to do the hardware as well, electronics but also vacuum hardware, usual repair work on the machine, developing other detectors (EDX for example), a cryo stage ..... there is just no time for it and im afraid if i dont hit the road running this scan controller will just end up as another begun but never finished project as it usually happens
I know there is a surprisingly large group of people right now building scan controllers for SEM (i know of at least 5 (now 6) people) so im sure someone will pick up on your advice after reading this
Its also to be mentioned, the controller in hard and software can just as well control other scanning hardware like AFM, STM, laserscanners or whatever so its a very useful tool!
Ive had some time to play today so i decided to just try doing something in an stm32f303, i still have a bunch laying around and they have 3 DAC channels so why not...
It took me some time fighting the cubeMX setup to get two channels to run simultaneously, the info on the internet grows kinda thin there. I did not get DAC2 to work but both Channels of DAC1 which is good enough for now. The result just scanning without doing anything else is 1000 lines per second at a width of 12 bits, adding SPI and an ADC conversion brought me down to 48 lines per second at 10 bit width. Its notable though that the largest change came from the ADC being slow and not the SPI transmitting two bytes for each pixel since the Transmit speed is 18MBit/s. Looks like a 1MPx Image can be easily done this way in 20s and a 16MPx scan will take 5-6 minutes. Thats roughly 16x the time the atmel took and will allow to take high resolution for the first time.
Im pretty happy with this so faar, not the goal performance but im getting close to a system that can be used in an every day situation!
Its still to be found out though if the raspi will eat the data as fast as i can send it but thats a question for another day. Maybe using an external ADC on SPI2 will improve things as well, looks promising... -
To give some more specific numbers of what i imagine:
DAC: 2x 14-16 bit
ADC: 1x 14-16 Bit
Slow scan: at least 1500x1500px in 2-5s
Fast scan: 500x500px in 1s
If you are scanning 1500x1500, then why is 14 to 16 bit DAC resolution required? 1500 counts is 10.5 bits. Is the extra resolution needed for offset and span of the image? Linearity correction?
Just to give some idea of scale, 1500x1500 in one second is about 2 megasamples per second or 0.5 microsecond settling time. 16 bit resolution is possible at that speed, but will require careful design on the analog side to achieve that level of performance. I would consider it a "best effort" type of design although your requirements are considerably relaxed by being able to scan in a serpentine pattern.
Vector CRTs typically had 10 bit resolution at that kind of speed, and used correspondingly low precision designs, but some were a little higher.
-
Hi!
You are right, its not nessecery just fr normal scanning. But there is some applications where it can be useful, the slower you scan (usually up to 1minute) the better the image quality. Reducing the electron beam current reduces the size of the spot scanning but also increases noise, so taking more readings allows some math to be done on the data. Also having more dac resultution allows the beam to be scanned more smoothly, hard stepping from pixel to pixel will introduce ringing or over/undershhot in the analog beam deflection, the closer to a linear moovement the better.
Another reason is to have the ability to scan a smaller portion of the screen with still high resolution. The beam can be used to for example harden photoresist usually tahts done only on a small portion of the screen but high resolution is still needed to get smooth shapes so i can use 12 bit on 1/4 off the screens width if 16 bits are available. The speeds in this case will be small though.
So basically its to hold open the possibilities for future applications and not have the diesign limit me then. -
Looks like the best choice would be to use an analog ramp generator instead of a DAC output.
Maybe an analog ramp where the slope is controlled by a fixed output of one DAC_1, and the offset controlled by the other DAC_2, also as a constant value. This would be for one axis (the lines sweep), similar for the other axis (frame sweep).
That way it would be possible to scan only a certain area at a given speed. Another advantage of going analogue with DC controlled XY ramp generators would be that you can use PWM or PDM pulses instead of a DAC to set the DC values, so you can have as many as you wish, and at any number of bits.
It is not clear what are the input and the output signals from your SEM. How many signals do you have, and what are their specs in terms of max voltage/speed of the ramps for a SEM like yours, beam current, detector, etc.?
Regarding the Raspberry Pi speed for SPI, AFAIK the max clock is 125 MHz (125Mbit/s), so your 18Mbit/s should be easy. There are RAM buffers on the RPi (default 4096 bytes, but can be set upon wish IIRC) and RPi can be set in slave mode and gulp whatever SPI data is coming to it.
However, writing at 18Mbit/s can be a challenge for many SD cards, so you'll need either a newer/faster (video) SD card, or maybe a USB hard disk for the RPi to store the datastream, or forward the datastream to the LAN network without saving it on the RPi. Beware some SD cards only specify the read speed, which is usually many times higher than the writing speed.
https://www.kingston.com/en/solutions/personal-storage/memory-card-speed-classes
-
Hi!
The analog ramp was something i considered some time ago but this will fix me to scanning only, no lithography or other useful stuff. I want an arbitrary way of controlling my microscope (and other devices) that is not taylored to one specific machine or application. Also doing it the analog way will require measuring the actual voltageof the ramp, prediction will not be linear enough so i will have to read three voltages at once, not in sequence to know exactly where the measurement was taken. Such a ramp generator is actually built into the microscope already, its basically generating a video out.
The microscope needs +-10V control signals for x and y, most other functions can be controlled by rs232. It will return a 0-10V signal directly from a detector, no matter wich ohne is used except for the planned edx, this one will also talk via 232 and give ma an entire spectrum for every point on the map. Since taking one of these sprectra will take at least a minute thats also where i need the softwar control. I will have to specify a grid of measurements taken that will be overlayed over the image previously taken by SEI. So for example one 1MPx scan generating an image and a 100 minute 10x10 grid scan on top generating a heatmap of a selected element in the sample.
The SD is something i completely missed out on Isnt there a way to just feed that data into the raspis ram? I think there is still 1-2GB of fast memory there.
Worst case i could leave fast scans to the STM and feed the date through SPI into some flash chip, then read it out later. That would suck though if id ever want something live view related. -
For fast a2d I tend to use an external a2d.
I designed a oscilloscope using PIC32mx and ad9201 a2d.
I can manage about 17 mega samples per second.
-
Yes, the adc will be external of cause, the internal one is not really good enough with 12b resolution.
Thinking about it, maybe i can directly feed the adc data into a flash chip with no controler inbetween? I know the sequence of coordinates so if i first flush the storage this should work. -
The secret of high performance is streaming, i.e. implementing DMA transfers. DAC timing by hardware, DMA transfers for DAC, ADC all in hardware. The same for communication to the Raspi. Please, no analog ramp..
Of course, for an experimental setup or a small series that development may not yet be justified and one would rather combine high performance components using simple software. Maybe a STM32H7 processor running at 550 MHz etc.
I was surprised how a 12 bit ADC should not be enough for digitizing gray scales. Maybe there could be a PGA with offset control for signal conditioning.
Regards, Dieter -
You are right, its not nessecery just fr normal scanning. But there is some applications where it can be useful, the slower you scan (usually up to 1minute) the better the image quality. Reducing the electron beam current reduces the size of the spot scanning but also increases noise, so taking more readings allows some math to be done on the data. Also having more dac resultution allows the beam to be scanned more smoothly, hard stepping from pixel to pixel will introduce ringing or over/undershhot in the analog beam deflection, the closer to a linear moovement the better.
Another reason is to have the ability to scan a smaller portion of the screen with still high resolution. The beam can be used to for example harden photoresist usually tahts done only on a small portion of the screen but high resolution is still needed to get smooth shapes so i can use 12 bit on 1/4 off the screens width if 16 bits are available. The speeds in this case will be small though.
So basically its to hold open the possibilities for future applications and not have the diesign limit me then.
The desire for higher resolution DACs makes sense then. I suspect performance will ultimately be limited by the beam control amplifiers unless they are improved. Like I said, 16-bit performance is possible at that sample rate, but it will require care in the analog design using fast settling low noise precision operational amplifiers like the LT1468 which is designed for exactly that.
Serpentine scanning will relax the requirements for settling time but not noise or precision, so use the part with enough noise and precision in your application, and then get the part with the fastest settling time. (1) Settling time depends on more than bandwidth and slew rate and faster amplifier often settle slower, of if they lack enough open loop gain or have too much noise, they may never settle. Fast settling amplifiers are a category all to their own.
(1) The common specification to look for in high resolution applications is settling time to 0.01%.
-
@dietert1: Yes, i guess DMA will be the way to go, no fpga crazieness but still using hardware. Do you think just feeding the ADC output into storage directly will work? I could use the controller to generate a pulse into the sample and hold, the clock and then rout the data directly.
12 Bits may be enough but my reasoning is, i will transmit 16 anyways and store them as uint16_t so why not keep the options open? Settling a 16b adc to 12b accuracy should not be much slower then just using a 12b, or am i wrong? Also SEM imaging is very comparable to analog photography where sometimes you cant see what you are scanning until the scan is made, predictions may be difficult so adjusting brightness and contrast later is a big help that will throw away a few bits.
@David Hess:
Yes, you are right, the microscopes amps will be a limiting factor at some point. My machine is a JSM-6300 (like sam zelooff), in ordinary operation it runs at 25Hz framerate generated from mains. There is also slow modes for high resolution scans. So the Microscopes limits are actually still faar away, the data that would be generated at 25Hz and >1kx1k lines is far beyound what i could dream of handling with my current abilities
I think noise is the most important factor as this will translate into deflection generate fuzzienes in pixels as seen on my posted scans. Overall precision or even linearity is not so important as long as it will only be over a larger range. a few percent distortion in the image is not a problem as long as there will be no grains appearing because of visible steps in the DACs -
I would think that Linux would get in the way if you use a Pi... For a strictly embedded controller, I don't think I would use a Pi or any other chip that must run Linux. Just writing the device drivers will be a challenge if you want them to go fast.
The Teensy 4.1 runs at 600 MHz and is a full ARM Cortex-M7
https://en.wikipedia.org/wiki/ARM_Cortex-M#Cortex-M7
https://www.pjrc.com/store/teensy41.html
https://www.pjrc.com/teensy/IMXRT1060RM_rev3.pdf
No OS to get in the way, just bare metal ready to run really fast!
I doubt that the 6 bit internal DAC will be of any use but there is a 12 bit ADC with 10/11 bits of accuracy. Maybe the internal devices just aren't sufficient. All detailed in the User Manual linked above. More documentation at the site.
-
12 Bits may be enough but my reasoning is, i will transmit 16 anyways and store them as uint16_t so why not keep the options open? Settling a 16b adc to 12b accuracy should not be much slower then just using a 12b, or am i wrong? Also SEM imaging is very comparable to analog photography where sometimes you cant see what you are scanning until the scan is made, predictions may be difficult so adjusting brightness and contrast later is a big help that will throw away a few bits.
I would do the same thing, and there are some ADCs and DACs which are fully interchangeable in the 16 to 12 bit range.QuoteYes, you are right, the microscopes amps will be a limiting factor at some point. My machine is a JSM-6300 (like sam zelooff), in ordinary operation it runs at 25Hz framerate generated from mains. There is also slow modes for high resolution scans. So the Microscopes limits are actually still faar away, the data that would be generated at 25Hz and >1kx1k lines is far beyound what i could dream of handling with my current abilities
I think noise is the most important factor as this will translate into deflection generate fuzzienes in pixels as seen on my posted scans. Overall precision or even linearity is not so important as long as it will only be over a larger range. a few percent distortion in the image is not a problem as long as there will be no grains appearing because of visible steps in the DACs
The reason I brought it up is that the electronics for the beam steering was probably not designed with lower noise, higher linearity, or faster settling time than necessary. In oscilloscopes, which except for some ancient rare exceptions use electrostatic deflection, the vertical amplifier is designed for speed and the horizontal amplifier is designed for linearity, resulting in very different designs. Vector scopes use high linearity feedback amplifiers very much like an oscilloscope horizontal amplifier, but simplified because there is no need for a fast sweep. A vector scope amplifier can be as simple as moderately fast operational amplifier like a relatively noisy 3MHz JFET TL071 which is good enough for 10-bit resolution in a real time vector application. Of course we have parts today which are better than a TL071 in all respects at reasonable prices.
-
Perhaps Cypress FX2/FX3 for data capture and a modified sound card for generating the scan signals?
-
Impressive! If you're achieving that already on a simple 8bit microcontroller, why not look at a faster and more capable 32bit micro? I didn't see a mention of what your hardware is exactly (other than the micro itself), but maybe something like an Arduino Due, or similar hardware at least?
You'll have more peripherals to use, and they will likely be faster as well. If they don't have the resolution required, controlling a few external peripherals via SPI should be achievable in very short order - microseconds, if that is acceptable. -
I wrote those things earlier
But thanks ^^ -
I would definitely recommend using a Teensy 4.1 for this, too. Specifically, Teensy 4.1 + two 8 MiB PSRAMs + Ethernet kit, for about $35 USD.
This gives you something like 17 MiB of RAM to store the scan locally (a single 8 MiB PSRAM has room enough for a 2048×2048 array at 16 bits per sample, and is continuous in the Teensy memory; you just set up a pointer to point at the beginning of the PSRAM, and access it via that, and the hardware handles the rest). Since you do need to solder the PSRAM chip yourself, I would definitely get at least one extra (don't ask me why, please); and you can use either one, or two if you don't need additional Flash. The Ethernet kit has a MagJack, which means you can either use the high-speed USB (480 Mbit/s; even basic USB Serial can do at least 200 Mbit/s or 25 MiB/s), or the Ethernet (Teensy 4.x has a native ethernet PHY) that due to the MagJacks, also gives you galvanic isolation and possibly even better transfer rates via e.g. UDP. Having all these options from the get go helps.
But the biggest reason is Teensyduino and the Teensy head dev, Paul Stoffregen. For an Arduino developer, his libraries just make the development much easier. (He does not do only Teensy stuff, he contributes quite a few modules to the Arduino environment.)
Teensies are not open hardware, and do contain a proprietary bootloader (on an NXP MKL02 chip), but PJRC does sell these pre-programmed chips so that you can do your own i.MX RT1062 board, and develop on it using Teensyduino and Teensy tools (just don't call it "Teensy" or anything Teensy-derived). There is a lively PJRC forum dedicated for developing Teensies and stuff on Teensies, too.
If you at some point out-grow the Teensy and Teensyduino environment, you only need to implement your own bootloader and i.MX RT106x boot/bringup code (that sets the various clocks, initializes peripherals, etc. that the MKL02 chip on the Teensies does with the help of the external Winbond Flas chips on the RT1062 –– that's why Teensy 4.x is currently not compatible with e.g. RT1064 chips), and go your merry way on your own designs. (I recently asked PJRCs preference on publishing ones own boards using the PJRC.com preprogrammed MKL02 chip, and the response was quite friendly.)
Whether the internal ADC on the Teensy 4.x suffices for the SEM, I'm not sure; it really only has 10 noise-free bits in the ADC samples. But, using something like a MCP33131 for the data acquisition using SPI, giving you 500 kSamples/sec (-05) to 1000 kSamples/sec (-10) at 16 bits (13 noise-free bits) per sample; using say 75 MHz SPI clock and a timer controlling the start of conversion line. (I do not know which ADC is best suited for your needs, since I don't know the voltages measured, nor the optimum rate at which to sample the data; consider this just an example on the idea level, and not as an actual suggestion! With MCP33131-10, 1500×1500 samples would take 2.25 seconds; 1024×1024 = 1.05 seconds; 2048×2048 = 4.2 seconds and fits exactly in a single PSRAM at 16 bits per sample. With two PSRAMs, you can use one PSRAM per image, and continuously scan new images while transferring the previous one to the host at anything above 2 MiB/s, without any delays/latencies/intervals between image scans. Again, even the basic USB Serial gives you 25 MiB/s or more. This no-delay-between-frames should help with the scanning process, too, being completely continuous. I'm pretty sure there are much better ADC chips for this out there, but MCP33131-10 was just the first one that fulfilled my requirements in a Mouser search, is in stock, not too expensive, and relatively simple to implement ones own board for.)