25 Years Old
Norwegian Male
Saskatoon, CA
So this post is quite a bit late... but im going to go ahead and pretend like it just happened.
So It was not a dark and stormy thursday afternoon when I decided to go onto Kijiji and check out whats free for the week. In case your wondering if you goto a catagorie then click on the "For Sale" subcatagorie you can then filter the entire site by a price of $0 to locate everything free. It just so happens that paid off for me as I saw an add for a Toshiba e-Studio 3511 color coppier that was NFG and free if you can pick it up. I seriously didn't believe this at first as I figured why would a company give away a busted copier? Don't they usually lease or have some sort of product upgrade plan? So I dropped them an email.
Enter Friday, I awoke to find an email from them saying they just want the copier gone as its in everybodies way and if I came that day they would even help me get it into my truck! So like any good citizen I came to the rescue and we managed to wrestle the 450lb beast into the box.
The only way I could get it to fit into the 1/4 tons box is jammed on an angle. Luckily it was NFG already as we dropped it a few times. I drove home and sat on the sidewalk for about an hour thinking about the best way to approach this beast as I had conviently left all of my tools as work and only had a $12 Home Depot discount screwdriver kit. Upon realizing that their was no good way to go start trearing apart a photocoper I grabbed a screwdriver and attacked the paper handler.
Before I realized it the sun started setting and my neck had a horrible sunburn but I was stoked on all the goddies I had pulled from just the paper handler! Im talking rack and pinion gears, solonoids, NEMA34 stepper motors WITH drivers! And that was just the begenning. I also found a crazy stapler that ran on a question mark shaped track so it would staple up the spine or on the edges of pages and it holds a 3000 staple cartridge that was half full. I took all of the rolly bits off and am going to put a simple ATTiny controller on it with a push button so I have a hardcore desk stapler. Then I discovered a power hole punch that does a fantastic job of making confetti. I decided it was less usefull than the stapler but as we do not have a 3-hole punch I tunred it into a manual one and put it in my stationary drawer. Their where also a few PCB's with a bunch of little gull wing SOIC H-Bridge chips that looked handy so I took everything including the connectors and put them in my parts bin.
At the end of the day all that was left was a box of parts and an interestingly shapped rack on wheels. A rack that just so happens to be 19.5in across which is what the standard data rack is. I am quite undecided what to do with this but I have an idea of putting my benchtop power supplies, osciliscope, function generator and an old laptop on it as a handy moveable test center.
* End Of Day One *
Saturday.. Day two of the tear down and I awoke with determination to score some goddies from the behemoth. The outside plasic bits provided no challange at all and the odd one that did got the pry bar and before I knew it I had found an interesting selection of printed circuit boards. Now their was quite a few of them and that looks alot like a DIMM memory module there... Turns out that this machine runs a version of winCE and runs on a VERY propritary thin client. It has 128mb RAM and 32mb of more RAM in a second slot?? Their appears to be two identical cpu's under a custom Toshiba unmarked package so I'm not sure whats going on there. On top of the motherboard is an ethernet card on what I assume is a PCI bus as the realtek controller is PCI interface. Above the mobo is a fun dual fax modem complete with neon light current limiter on the phone line lol. The east board is a collection of motor drivers and what I later found out to be the controller logic for the laser unit.
We took a break for some watermellons and my wife came out to help as I had been at it for several hours and had bearly scratched the surface of the thing. I had succesfully removed the majority of guts from the back of the unit and had scored a massive NEMA34 motor that turned the laser drum and a flywheel made out of 6 layers of laminated steel. I also scored some hinges that will be in a latter post if they work for what I have in mind. I decided to remove the scanner unit next, this tunred out to be interesting as it was obviously assembled piece by piece on top of the copier and not as a seperate unit as I had imagined. I had to bend a few bits to remove the jelly feet it was on but I managed to get the entire scanner out in one piece. It uses an old but probably better method of scanning as it has a "reverse projector" setup with a cold cathode tube to light the document. Most desktop scanners use an led and a long strip of photo diodes that the scanner pulls past the document to read it in. This guy uses optics to reflect the document to a stationary photo diode array. I may write a post in just the scanner as its quite interesting.
After the scanner was removed I took off the LCD panel as its quite large and would make a good interface for something im sure. I will do a writeup on it as I learn exactly what the heck is inside it. After all of this it was getting quite late again so I stopped taking pictures and focused on just getting the thing takken appart before the city bylaw officer drove by again and decided to ask question. Not much of interest came out of the main body of the copier. The entire paper drawers had nothing unefull in them beside a gear train to remove paper and it was all plastic so I tossed it away. The main guts of the machine was a metric ton of rods with things attached to them. I got thin rods, thick rods, a giant green rod, ones that are squishy, ones that are magnetic and ones that where sharp and made me bleed. The main laser unit was kind of a letdown actually. It took almost two hours to get to it and it consisted of a square mirror and three lenses to spread the laser beam onto the toner rolls and a 90deg laser collimator. While the lenses are useless the 90deg collimator may come in really handy down the road so I will look into that later.
About a week later and I had finished stripping down the multitude of components and sorted them into relevent bins. This was a fantastic score I must say, I got so much stuff I will not need to buy or make mechanical parts or gears for the forseable future! In total I got:
05 - Brushless DC motors with controllers
06 - NEMA12 Stepper Motors (I assume NEMA12, they are quite small)
10 - NEMA17 Stepper Motors
03 - NEMA23 Stepper Motors (Two with seperate controllers)
03 - NEMA34 Stepper Motors (Two with seperate controllers and one HUGE motor)
18 - Solinoids of random sizes
32 - Rods of random sizes, some with removable bits on them. (One is a huge green roller and ones even magnetic)
03 - Power supplies that provide a wacky range of voltages
13 - PCB that handle the IO and motor functions. Many gull wing H-Bridge packages
02 - HEAVY duty hinges
01 - Massive flywheel
01 - Power stapler
01 - Power hole punch
01 - Funky 90deg gear train
01 - Linear motion stage, quite thin but could be handy in a light project
01 - 90deg laser collimation assembly (To be written about at a later date)
And more that I have forgotten about...
So I was parusing kijiji looking for free printers to steal parts from when I happened upon an add for a Linksys Media Center Extender (WMCE54AG). This device was originally created to route audio and video from your XP Media Center to your TV so that you did not need a computer in your living room. I remember when these first came out I saw them at memoryexpress.com from a chunk of change. Well I scored this one in working condition minus the remote for $10 !!!
As with most project I was to into it and forgot pictures of the unit before it was stripped. Here are some I stole from the internets:
(The picture with the chips circled is a handy reference from here )
Main processor under the heatsink is a ATI Xilleon 225
ATI Xilleon 225
215H25AGA13
GC7312.1
0433SS
1- Ethernet Controler, PCI interface
RTL8101L
48298Q1
AT93C46 Serial EEPROM from MAC storage
2- Mini-PCI A/G WiFi card
Atheros
AR5213A-00
A20254C
2304 3- 128Mb SDRAM for the BlackFin DSP
SAMSUNG 440
K4S281632F-TC75 4- 600MHz BlackFin DSP ($28 for one of these babbies in TQFP)
ANALOG DEVICES
ADSP-BF533
SKBCE10
559595.1 0.3
0445 SINGAPORE
BLACK
5- 128Mb (8M x 16) GDDR SDRAM
HYNIX 430P
HY5DU281622ET-5
6- 16M x 8 bit NAND flash memory
SAMSUNG 446
K9F2808U0C
YCB0
UPH737DCC 7- 2ch 1% regulation LDO
LT 0433
LTC1628CG
N27185 8- 4Mb Flash
MXJ043504
29LV040QC-70
1F9588 9- 8-bit AVR, maybe IR controler?
ATMEL
AT90SC3232CS
0443
4S5691
Another fun chip is on the back of the front controls. Its a 16bit I2C port expander from NXP It runs the front controls and the tri color LED ring on the navigational pad. I had some fun with blinking lights before continuing.
So I set out looking at the board and discovered some things. Their is a MFG/WDT jumper on the board, no idea what the WDT jumper does but I presume its something to do with the watchdog timer. Maybe during chip flashing they need to halt the Xillions WDT so it wont interfear. In the one corner I found a "Debug Port" with an IC not in place. Their where only two wires so I immediatly thought serial port and was right. I soldered in a header after carefully drilling the via's out to accept a standard sized headder. The copper jumpers across the pins there is because I do not need to use the level shifting IC that they would have put on. My BusPirate runs at 3V3/5V0 so I just bridged the pins and hooked her up.
115200bps, 8N1 seemed like a good place to start and out poped the boot sequence! Initialy it loads the "bios" or "IPL" that inits the hardware and discovers boot devices which are the Flash and NAND Flash then asks for a command. Without interfearence it will boot the WindowsCE kernel and start up a bunch of tasks like re-mapping the address space to a virtual one then unloads the debug shell. I somewhat remember from my WinCE v5 licence days that the IDE had some shell debugging apps that would hook the kernel to keep the debug ports open but I will need to dig up my CD's before I can be sure. For now I will just poke around.
So far I have leared this; The MFG jumper puts the unit into infinate self check and typing "y" at the ++CMD prompt will dump you to a PROM console those who have ran SGI/SUN machines may remember. Below are some test files with the output of a few boots.
This little book with help familiarize anyone who cares to know how to use Keil's Realview compiler tools on linux.
At first though this may seem very pointless as CodeSourcery Lite is capable of everything Realview is, however if you have very large projects or a lot of time invested in an project then it only makes since to stick with what the project started with. I am currently reviewing all the available integrated development environments that linux has to offer (theirs a LOT) and will tack on a chapter five on how to use the Realview tools with a new IDE. So far CodeLite is showing quite a bit of promise however their are some linking issues I must deal with either via pushing a change to the projects svn or a makefile hack. I have not decided which method to use just yet.
For anyone that is interested I will be migrating my toolchain over to GNU for all my newer projects. Windows stabbed me in the back one to many times so I rolled it in a carpet and tossed it in the Neva river.
So around full circle if I wish to use CodeSourcery then why not take a look at Rowley CrossWorks again as they use CodeSorcery as the underlying toolchain.
Download the project files here:
sourceforge.net/projects/uminded/files/Linux_Projects/
What is Jack? Well its a pretty useful program if you have a lot of audio input devices (musicians) or several output devices (audiophiles). It also has a nice cross connect setup where you can map each speaker to a source on the system and you can merge them as well. This actually solved one of my *nix issues I had that Pulse was not detecting that I had 5.1 setup and I was only using my front speakers but now with Jack everything is working great!
I have written a very simple shell script that will stop your current pulse audio output module and use the jack module instead. The script also provides a way back to your original setup so you do not need to doanything on the command line when you want to use Jack for any application. This script has several "sleep 10s" commands as Pulse does take a few seconds to die and start up. If you want some extra few seconds you can modify these values or be more patient.
#! /bin/sh
USER_PULSEFILE=~/.pulse/pulse.pa
case "$1" in
start)
echo "Killing current Pulse Audio process..."
pkill pulseaudio
sleep 10s
echo "Restart Pulse Audio process as a daemon..."
pulseaudio -nDF $USER_PULSEFILE
echo "Wait for the daemon to start..."
sleep 10s
;;
modules)
echo "Killing current Pulse Audio process..."
pkill pulseaudio
sleep 10s
echo "Restart Pulse Audio process as a daemon..."
pulseaudio -D
echo "Wait for the daemon to start..."
sleep 10s
echo "Loading the Jack modules..."
pacmd load-module module-jack-sink channels=2
pacmd load-module module-jack-source channels=1
;;
stop)
echo "Killing current Pulse Audio process..."
pkill pulseaudio
sleep 10s
echo "Restart Pulse Audio process..."
pulseaudio -D
;;
*)
echo "Usage: pulsejack {start|modules|stop}" >&2
exit 1
;;
esac
exit 0save this script via your favorite text editor to your .pulse directory and call it pulsejack.
eg. Copy the above script and open a terminal and type:
cat > ~/.pulse/pulsejack << "EOF" *ENTER* *Right click > paste* EOF *ENTER*
Then you will need to make a copy of the default pulse.pa script and remove the udev module as it gets in the way with static modules.
cp /etc/pulse/default.pa ~/.pulse/pulse.pa
Open pulse.pa in your favorite editor and comment out the module-udev-detect and if statements like below. Also add the module-jack-sink and source.
While you are in ~/.pulse/ make a client.conf file and put autospan = no in it or type whats below. This will make sure Pulse does not automatically restart when we run our script.
echo "autospawn = no" > ~/.pulse/client.conf
Next you need to actually install Jack and its related parts. A simple apt-get will do what we want. qjackctl is the Jack control panel and does a fantastic job and allows you to do the source/output patching like I mentioned above.
sudo apt-get install jackd pulseaudio-module-jack qjackctl
This next step may be optional but I read that it helps out Jack if you have a lot of data moving around the audio system. YMMV but I recommended you do these commands just to be safe. The limits.conf file is used by a hardware management daemon that kills apps when they hog to many resources.
sudo addgroup <username> audio sudo su -c 'echo @audio - rtprio 99 >> /etc/security/limits.conf' sudo su -c 'echo @audio - nice -10 >> /etc/security/limits.conf' sudo su -c 'echo @audio - memlock unlimited >> /etc/security/limits.conf'
Thats it! You could not run everything by hand if you wanted or you can setup qjackctl to handle the shell stuff for you. To do that open qjackctl and goto "Setup > Options" and set the run and stop scripts up like I have below
Now push the start button and your audio manager will show Jack as the default output device!
Well I was poking around the linux repos looking for a program that I can use as a tone generator for some of my electronics projects when I stumbled upon this wonderful program: http://www.baudline.com/
This little program not only has a tone generator with noise and sweep capabilities but its a handy little tool to do fourier analysis and general spectral analysis. The program is currently only avalible for *nix based machines but the source is provided so I am sure a windows compile can be done (provided the sound API is standard...)
Check out this interesting screenshot:
Thats one crazy complex signal to create the matrix scrolling letters effect! Those HAM radio events can get crazy. To step it up a notch somebody put out a QR-Code (A 3D UPC) over the radio waves:
Anyways Baudline is a great program so far however their is a few issues to note. If you are using a standard distro such as Mint or Ubuntu then you will not be running the required Jack audio daemon that baudline requires to have access to the sound hardware. Their are how-to's on the web but they all require much more work than a simple little init script can provide and they do not require system changes! I will post my script in the next post. Once you get things up and running one thing to note is that you can not play back anything with stdout in the output devices window or you will crash. You also can not record from Jack unless you actually have an input source or baudline will crash. Their are still some bugs but their easy enough to work around.
Basic usage info:
To run Baudline you need to start it via the command line or else you will not have any input or output devices in the selection windows. To run with all options enabled like I do run this command
./baudline_jack -stdin -stdout
That simple command will let you pipe files in from the command line (such as from an audio recording) this is also mandatory if you wish to use the tone generator as by default it can not output directly to the Jack output device. You must first select stdout in the tone generator window and then record the signal then play it back via Jack. Its not actually a big deal as 99% of the time you want to make sure what signal you'r going to output is correct first.
Here is a screenshot of my setup:
Hello everybody! It's a good week of production so far and I am happy to announce the release of the fully working CMSIS & FWLib KEIL ARM-MDK project template.
Upon the rival of my STM32 Mini I have been struggling to get CMSIS to play nicely with ST's firmware libraries which provide a standardized function set to using their on board peripherals. Using the firmware library is important to me because this is not a simple AVR or PIC microcontroler here, their can be a dozen 32bit registers for a periphearal and when you start dealing with DMA and the NVIC working at the register level becomes very tedious and error prone. Those who have used Procyon AvrLibC know that having a standard function set for each peripheral can cut down development time substantialy. ST's firmware library is quire similar to Procyon's in the fact they are an assortment of source and header files that you can selectively include yourself or use their global configuration file. The major difference between ST's version and other micro libraries I have seen is it is MUCH simpler to compile in piece meal form; you can simply select the SPI library for example and you only need to include a few other files to provide lower level functions and your ready to go.
I have created a simple project standard that has all the include paths and folder structures arranged in a clear manner with the files you should not be modifying set with the appropriate read only file permissions. The KEIL uVision IDE provides the bulk of the setup through their project configuration menu as I assume if you are using KEIL your not going to be using just the command line compiler. If their is interest in using the KEIL command line tools I might add a makefile to the project at a later date.
The relevant files to you, the user who is starting a new project are these:
FWLib_INC\stm32f10x.h
These options may be set by modifying the header file or by adding the defines to the project via Project Options -> C/C++ -> Defines. I perfer to leave the header untouched and just use the defines as that way you can leave a clean firmware library that you never need to worry about their being an error in. After all the who point of portability is to never modify the middleware.
My template includes these defines:
As simple as that. I have never needed to modify the HSE settings as you will use an 8MHz crystal on any of the STM32 chips except the connectivity line and ST has taken care of modifying the HSE values automatically when you select STM32F10X_CL as your chip type.
To include specific library componets such as GPIO, SPI, RTC etc their is a handy file called FWLib_INC\stm32f10x_conf.h with this file you simply comment out the features you do not wish to use and the compiler will automatically include them in the project for you. Their is nothing else you need to do to get off the ground with CMSIS & FWLib.
One thing I should mention is their is a rule in the STM32 documentation that the first 15 interrupts in the negative range must have prototypes even if they are empty. I'm not sure why this is so but as its their standard we must do as we are told. In the FWLib_SRC folder their is a file called stm32f10x_it.c that handles all this for you and if you wish to add a delay function via SysTick this is where the SysTick_Handler() ISR resides. You will notice that all the other files in the FWLib_SRC folder have little gold keys next to them and the stm32f10x_it.c file is the only one without one; this is because it is the only source file in the firmware library you should ever have the need to modify.
I have compiled the documentation for both CMSIS and the Firmware Library from Doxygen in compressed HTML format, also known as Windows help files and I believe they turned out quite nicely. The stylesheet is quite ugly and I am working on my own version but they give a very clear presentation of the available functions and what the initializing structures contain. I plan on writing a post on how to navigate the documentation to find out what options are available to the initialization structures such as how to find out that GPIO_InitStruct.GPIO_Mode = GPIO_Mode_Out_PP; also has the GPIO_Mode_AF_PP mode available.
So what does the future of this project hold? Well my goal is to provide a much more useful firmware lib package than ST has with examples of real world devices such as LCD's, TFT's, touch panel controlers and SD cards. To compare the current SPI examples in the firmware library use code that sends on SPI1 and recieves on SPI2 of the same chip, this is great if you want to see if the peripheral even works but when you need to initialize it for the real world and handle NSS pins in software their is no examples to be found. My end goal is to use the STM32 Mini as a template and have each piece of hardware as a separate example and then combined together to make a complete project. In this way I hope to instruct not only myself but anyone else who finds the world of ARM quite daunting.
I do need some input from the community on this project, mostly regarding what compilers and IDE's I should be developing on. I started with KEIL because of their peripheral view during debugging but after this template was complete that feature is no longer necessary. Should I focus on GCC with a makefile, KEIL command line maybe, or focus on Rowley CrossWorks? I wish to support whichever is more popular.
For version 1.2.0 my goals include compiling the entire CMSIS & FWLib into a library file and only leave the files mentioned above available to the user so as to remove the temptation to modify and to clean up the project inclusions.
Download v1.1.0 now from: SourceForge
So I bought my first ARM development kit a few months ago and it has been my primary focus since is arrived. The kit contains ST's STM32F103RB Cortex-M3 processor that can operate up to 72Mhz and has many fun and interesting peripherals on board.
I got my board from an online shop in Taiwan called micro4you and it was a great deal on the surface but let me tell you if you value your time at anything then order from the eBay stores. I made my order for a whole whopping $62 taxes and shipping in so I was extremely happy about that but after week two went by and their online order page still said "Processing" I started to get antsy. I emailed their customer service and then waited another week just to get a horrible English response of something along the lines of its shipped, just wait. After some more waiting my package finally arrived and I was glad it managed to get here in one piece as it took 41 days to reach me.
With milestone one cleared it was onto the actual act of using this fancy new device to blink some lights! I was trying to save some money and so I did not purchase a JTAG programmer to go with the unit under the understanding that it came stock with ST's serial flash loader. I plugged the Mini in and the LCD flashed to life with the uCOS II & uC/GUI demo and was quite impressed at the speed that the Mini could draw on that screen. Their is one part of the demo in which their is a windows like window open with a slider and i was able to move everything around as fast as I could without any tearing effects. The micro4you website also provides a more standard LCD demo so I decided that would be a good second test to run. I loaded up ST's flash loader software and it found the Mini without issues but when I flashed the demo nothing but a white screen was showing and the flash loader no longer would connect. Lesson number two is these demos are not built for just the Mini, and as a result it programmed over the serial bootloader making it impossible to use unless I purchased a JTAG programmer.
With this new information I went on the interwebs looking for a comparison of JTAG programmers and discovered that really their is only 4 options available for under $1000. They are:
Each have their own strengths but here is my opinion of the selection. Olimex makes quite a range of boards and their adapters are garenteed to work with them so if I ran a lot of olimex kits I would go for this option, however I own nothing Olimex so I passed it over. Paul over at Rowley made me a deal thats hard to pass up, buy their personal licence for $150 and he will toss in their CrossLink Lite for free! while this is a fantastic deal I unfortunately had already settled on KEIL uVision ARM-MDK as my compiler. That left me with Seggers line of devices. The J-Link is a professional quality tool that lets you run flash breakpoints, flash downloads, and their GDB server. The J-Link EDU is the same as its professional counterpart but it removed the flash download support and you must not use it in any commercial project or setting. I am a hobbiest so that does not worry me and for $350 if I was to ever make something I would just buy a new one! The lack of flash download worried me but it turns out that just means you can not use their flasher suite and has nothing to do with programming any devices. Needless to say I am the proud owner of a J-Link EDU now.
KEIL is a simple install and so is the J-Link software but making them work together is not such a simple task. The dll that KEIL uses to communicate with the J-Link was an old version 4.20a and it did not support SWD mode, to get around this I copied the JLinkARM.dll and jlink.exe files from 'c:\program files\segger\4.20c' into 'c:\keil\arm\segger' and reloaded my project and viola I could see my cortex-m3 device via SWD but now their was this annoying popup. By annoying I don't mean once, I'm talking popup then select device three times then agree to terms twice every time annoying here so I went out and got some more drivers. I did the same as above with driver version 4.20n and now the popup is only the licence agreement from Segger as it should be but SWD mode does not work! It took me about two hours to find out that I needed the jlink.exe from the stock KEIL install and the 4.20n dll to get the best of both worlds. So if your reading this and are gonna use the same combo I say good luck to you!
Welcome to part two of this little series on how to use Proteus Labcenter VSM. In this part I will explain how to create a simple part and how to program a very basic model. From this little example you should have no problems creating your own much more complex parts. In part three I am thinking of writing a similar tutorial but on a complex part, something like a sequential counter with a reset bus and maybe a LCD showing the current count. That should be enough of an example to get everyone off to the races.
What we need:
In this example lets create a simple buffer with built in 1kHz 50% square wave clock source.
Step I - First we create the part in ISIS. To do this click on the L in the parts bin or open Library -> Library Manager. Click "Create Library" and make a library with whatever name you wish. You can accept the maximum entries provided or enter your own but you can always change it later.
Step II - Now we will start to draw the part outline. Click on the box icon on the left hand tool bar and draw a box 7x8 squares large. Add pins to the device by clicking on the "Device Pins Mode" button that looks like an op-amp in the tool bar. Make sure the little X at the end of the pin is facing outwards as this is where you make your wire connections. To flip the pins right click and mirror on the x-axis.
Step III - Identify and label the pins you just placed. Double click on the pins to bring up their properties. Label them IN, OUT and CLK and assign pin numbers 1 to 3. You should get in the habit of assigning the proper "Electrical Type" to your pins so the electrical rule checker will work properly when you make and check schematics and boards. I chose Input, Output and Output respectively.
Step IV - Click and drag a box around the entire part you have made, right click and select "Make Device". Name it something that reflects the part number or what the part is, for the preface I use U for pretty much everything as thats what Eagle labels IC's and thats what I am use to seeing. The third menu in the device creation wizard is the money screen, make sure you set things up correctly. Select "New" and then "MODDLL". Under default value you need to put in the name of the .DLL that we are going to create. You can call it whatever you want but I 100% recommend you keep it the name as your device name so you don't get confused. Next select "New" again and "Primitive" and under the default value enter "Digital" as this is a digital device. Save your new part wherever you want (In your library created in step I)
Step V - In this step we will setup Visual Studio and check compile to make the .DLL required to operate the device you just made in Proteus. Open Visual Studio and select "New -> Project", Under "c++ -> Win32" choose "Win32 Project". In the wizard select the DLL application type and create an empty project. Add a new source file to the project. I like to keep the project name and the main project source file the same name and that name would be the same as the device the code is for, once again to keep things neat and organized. Now add a new header file and call it VSM.HPP and copy the contents of the header from the edaboard post I linked above or HERE. You can do a quick compile with the windows and VSM.HPP includes like in image 38 below but really if the compile fails theirs something seriously wrong with your setup...
Step VI - Below is the body of the code required to get things up and running. At the end of the steps I will give a little breakdown of the code and what it does but for now just copy and paste it into your main source file and make sure the project compiles successfully. In the Debug folder either one directory above or below where your project is saved (depends on your studio version) their will be a shiny new DLL file created for your Proteus device to use. Copy that DLL to your Proteus installs "MODELS" directories usually at "C:\Program Files\Labcenter Electronics\Proteus 7 Professional\MODELS".
#include
#include "VSM.HPP"
class MYMODEL : public IDSIMMODEL
{
public:
INT isdigital (CHAR *pinname);
VOID setup (IINSTANCE * instance, IDSIMCKT *dsim);
VOID runctrl (RUNMODES mode);
VOID actuate (REALTIME time, ACTIVESTATE newstate);
BOOL indicate (REALTIME time, ACTIVEDATA * data);
VOID simulate (ABSTIME time, DSIMMODES mode);
VOID callback (ABSTIME time, EVENTID eventid);
private:
IINSTANCE *inst;
IDSIMCKT *ckt;
IDSIMPIN *Input, *Output, *Clock;
};
extern "C" __declspec(dllexport) IDSIMMODEL *createdsimmodel (CHAR *device, ILICENCESERVER *ils)
{ return new MYMODEL; }
extern "C" VOID __declspec(dllexport) deletedsimmodel (IDSIMMODEL *model)
{ delete (MYMODEL *) model; }
INT MYMODEL::isdigital (CHAR *pinname)
{ return 1; }
VOID MYMODEL::setup (IINSTANCE *instance, IDSIMCKT *dsimckt)
{
inst = instance;
ckt = dsimckt;
//get pin names
Input = inst-> getdsimpin("IN", true);
Output = inst-> getdsimpin("OUT", true);
Clock = inst-> getdsimpin("CLK", true);
//"Clock" pin initial state
Clock->setstate(SLO);
//call "1kHz" clock function
ckt->setcallback(500000000, this, 0x01); //"0x01" is an arbitrary "ID number"
}
VOID MYMODEL::runctrl (RUNMODES mode){}
VOID MYMODEL::actuate (REALTIME time, ACTIVESTATE newstate){}
BOOL MYMODEL::indicate (REALTIME time, ACTIVEDATA *data)
{ return FALSE; }
VOID MYMODEL::simulate (ABSTIME time,DSIMMODES mode)
{
//copy the logic state of "Input" pin
Output->setstate(time, 1, Input->istate());
}
VOID MYMODEL::callback (ABSTIME time, EVENTID eventid)
{
if (eventid == 0x01)
{ //toggle "Clock" pin logic state
if (ishigh(Clock->istate()))
Clock->setstate(time, 1, SLO);
else
Clock->setstate(time, 1, SHI);
//call this "callback" function again
ckt->setcallback(time + 500000000, this, 0x01); //time in ps (picoseconds)
}
}
Step VII - Lets test out our new device! Grab the virtual osciloscope from the tool bar and wire it as in picture 42 with the clock source feeding the input and the scope watching the clock and output pins. If all goes correctly when you start the simulation (Start button on the bottom left in the status bar) you will see the output showing the same waveform as the clock pin. If it throws you an error go back through your steps and follow the pictures EXACTLY and it WILL work I promise!
Now for a short breakdown on how the code works. Please bear with me on this as I am new to creating new devices as well so this may not be 100% accurate. I will try to update it if I learn anything later on though.
class MYMODEL : public IDSIMMODEL
{ ..... };
extern "C" __declspec(dllexport) IDSIMMODEL *createdsimmodel (CHAR *device, ILICENCESERVER *ils)
{ return new MYMODEL; }
extern "C" VOID __declspec(dllexport) deletedsimmodel (IDSIMMODEL *model)
{ delete (MYMODEL *) model; }INT MYMODEL::isdigital (CHAR *pinname)
{ return 1; }VOID MYMODEL::setup (IINSTANCE *instance, IDSIMCKT *dsimckt)
{
inst = instance;
ckt = dsimckt;
//get pin names
Input = inst-> getdsimpin("IN", true);
Output = inst-> getdsimpin("OUT", true);
Clock = inst-> getdsimpin("CLK", true);
//"Clock" pin initial state
Clock->setstate(SLO);
//call "1kHz" clock function
ckt->setcallback(500000000, this, 0x01); //"0x01" is an arbitrary "ID number"
//the clock rate is in pico seconds so this is 500 usVOID MYMODEL::simulate (ABSTIME time,DSIMMODES mode)
{
//copy the logic state of "Input" pin
Output->setstate(time, 1, Input->istate());
}VOID MYMODEL::callback (ABSTIME time, EVENTID eventid)
{
if (eventid == 0x01) //That arbitrary "ID Number" we used to run the callback function
{ //toggle "Clock" pin logic state
if (ishigh(Clock->istate()))
Clock->setstate(time, 1, SLO);
else
Clock->setstate(time, 1, SHI);
//call this "callback" function again
ckt->setcallback(time + 500000000, this, 0x01); //time in ps (picoseconds)
//as it requires 500us for SLO then 500us for SHI we get a 1ms cycle which is our 1kHz clock rate
}
}Credit for the pictures and howto goto Yus from the Philippians electronics forum HERE I re-worded things and turned the animated gif's into standard pics but he did all the leg work. Thanks!
Welcome to my new three part series on Proteus Labcenter. In this series I will attempt to introduce you to this unique bit of software and give you the head start on making your own custom devices for use within the simulator.
Now I know what everyone is thinking, the electronics software market is already flooded with to many mixed mode spice packages and schematic capture programs to bother checking another one out. Anyone who has used National Instruments suite of Multisim and Utiliboard will already recognize what Proteus Labcenter is all about. Proteus Has schematic capture and PCB layout and routing capabilities that are the same as all the other programs out there and the SPICE simulation is just as easy to use as Multisim but the one HUGE difference as to why you need to check this program out is its virtual processors. Proteus allows you to load your hex file from you latest project and run it all on virtual hardware before you even need to bother making a prototype.
Alot of people dislike SPICE and its variants because its a language all to its own but lets be honest, unless you went to university and know how to to transient analysis and fourier transforms and calculus as second nature you have no real idea what every part of your project is doing. Sure you may have a pretty good idea but how do you know for sure that your IC is not overloaded or that your audio amp is being fed a signal outside its specified range unless you have the high end tools to do so physically and then your probably a university grad and fall into the above category. I am self taught in everything I know and what I learned in college was not so very useful for real world applications.
If thats not a good enough to get you interested then you can take a look at my situation. I had to uproot 1600km for work and will be without even a soldering iron for the next year foresee-ably and all it takes is a year off to forget everything I have worked so hard to learn. This program will allow me to not only keep in practice programming micros but also Win32 programming and a decent amount of IC and analog work that even I would not have usually done. I would love to create a wiki device with a touch screen and WIFI that would last on batteries for weeks but prototyping that in the real world would be quite pricey as it never works 100% the first time and usually some chip looses its life in the process. Hopefully I will have luck with Proteus and will be able to showcase some of my project and when I'm back into physical hardware hopefully build the project in reality.
The pictures below should get you interested:
Pic 1 - A complete simulation on the AVR Butterfly, All menu's and annoying scrolling text works just as on the physical device.
Pic 2 - A game of chess running on a PIC18F452, the tough screen is an 8x8 matrix but their are models with internal I2C/SPI touch controllers. Game also dumps info on a serial console
Pic 3 - An H-Bridge running a DC motor in a CW/CCW sweep, want to learn how to control that bridge for better current decay rates? Well now I can!
Their is even a simulation of a full linux distribution running on an ARM7 chip. You need a pretty good computer to run it quickly but its quite a feat to run a full processor emulator and SPICE sim at the same time. I plan on using a setup like this to learn low level hardware control programming for linux so I can get an EasyARM and actually use its hardware properly
UPDATE - I just found out that you can tie Proteus and AVR Studio together and do in circuit debugging virtually!! In studio under debugger type just select "Proteus VSM for AVR" and load the hex in Proteus and you can step through your code and check out the hardware. This is awesome as now I can actually simulate analog circuits and the virtual ADC will report actual numbers. Usually I had to spoof the ADC results buy editing the avr's memory but if the results are what your checking thats not a very useful solution.
The downsides:
Every program has its downsides and Proteus is not the exception. I am use to Eagle for PCB creation as well as Pulsonix, everybody else's software seems clumsy to me and so does Proteus's. To give it some credit I have not seriously used it and probably wont for quite a few months but when I do I will post a proper review. Another issue I have is the visualization and graphing (Like you see in the bottom of Pic 3) its awesome to have but clumsy to set up and hard to see things like address/data exchanges on a serial bus as it will cram the entire session into your screen. The biggest issue is price, wow this is a pricey package... $6000 if you want all the bells and whistles, $600 if you want it for one specific processor and schematics only. IF you can convince them you need it for school they will give you a discount but its still going to hurt the pocket book. I bought Visual Studio 2008, Photoshop CS2, and Proteus and will be paying them off for at least the next 5 years... Ouch.
Well that sure didn't take long!
I just put the finishing touches on on my Windows -> Serial -> AVR -> YM2149 music player, I call it YMstream as I like to point out the obvious. The is a very easy project to wire up and I do not have a schematic and don't think anybody will need one either. Here is how to do it:
I use a Mega164P with 8MHz crystal in a DIP package to make breadboarding easier, in software the mega is ran at 4MHz.
Sounds much harder than it is, its only 5 resistor and 9 wires to get it working. Please note that the YM2149 cannot run faster than 4MHz so if you want to use a faster AVR then you need to supply the YM with its own oscillator. I chose not to because I have no crystals slower than 8MHz and I wanted to keep the project easy.
Here is an audio clip from the project to bring back some memories!
Captured via digicam between headphones (Very good quality sound!)
Earlier on in the project (yesterday) I had planned on just sending the data address then data and bouncing between the two but when I first tried to stream it was a world of noise. The first transmission error and the registers and data would be going to the wrong locations and the SSG would freak out. The solution to this is not very elegant, I just tossed in a character check for each transmission and then allowed the next byte to goto the proper register. So when you want to send an address preceded it with 0x00, and precede data with 0x31. (eg. Tone on chA: 0x30 0x00 0x31 0xFC)
Their is a lot of room for improvement such as decoding the *.psg file in the player, adding play/pause, allowing the +/- to adjust the delay, maybe an interface even? I move in 3 days so will not be able to play with any hardware but I might whip up an interface and try my hand at decoding the psg's as I know what format everything needs to be dumped out in. A handy tool for this is a virtual comm that allows you to re-direct say COM4 back to your on board COM1. That way you can check the output thats actually leaving the serial port without needing to dump a lot of printf's to the console.
Another thought is that I opened a file to allow access to the comm port and apparently you can do the same for LPT's. I am unsure how you would set status and control bits but I might take a peak at that before writing anything else as it would be nice to do away with the AVR and just have a simple LPT interface. Would make the project cost nearly nothing (IF you find a SSG that is...)
Source is available for download from my Sourceforge
25 Years Old
Norwegian Male
Saskatoon, CA
25 Years Old
Norwegian Male
Saskatoon, CA
Theme created for Posterous by Obox
