One Dollar One Minute ARM Development - Page 1
Forum section: electronics / general

author: paulie
author_rank: Frequent Contributor
timestamp: September 02, 2014, 12:13:01 pm
content: By one dollar I mean parts will total $1 and change and by one minute all tools necessary to start coding and flashing can be downloaded and tested in less than 60 seconds. OK, maybe TWO dollars if you're not a great shopper and TWO minutes if you have slow internet. A photo of my STM32 target board is shown below.Prompted by a request for simple low cost intro to the 32bit world in this thread:Quote from: SuzyC on August 26, 2014, 04:47:51 pmThreads that got me started with ARM a few months back:http://www.rcgroups.com/forums/showthread.php?t=2154329Similar to Dannyf's excellent "ghetto" project but with a specific and very common chip and even more basic development tools. I think users who are experienced and satisfied with the somewhat exotic F0 chips will find that thread very useful. However strangely I've found F0 chips and boards cost a little more than F1 in small qty yet without the advantages of 128k flash, 37 I/O, 20k RAM, 3 USARTS and other bonus features. Anyway the plan is to start things off with a description of minimum hardware including hints on best sources for parts then provide the most basic tools for writing code and flashing the chip. If there's interest another stage involving the $5 ICE dongle mentioned in the other thread and easiest approach to debugging/tracing.The chip is STM32f103c8t6 which seems to be the most popular ARM from a global perspective. This part is installed on 99% of the Discovery boards shipped by ST and a search on Ebay (buy now/lowest cost) for "arm cortex board" will hint to its popularity. Just about the only choice in first few hundred listings. For anyone not so much into DIY those $7 Ebay "minimum development boards" are a great start. A couple jumpers and you are ready to go. Myself and a few friends took a somewhat different, even more minimal, approach to reduce cost. As indicated in the snapshot below chips can be had on Aliexpress for a dollar and change and PCBs for around 30 cents each. To get the best deal it may be necessary to buy more than one at a time but if you are a good shopper the cost can really get down there. It's even possible with coupon to get the boards down to as low as 15 for a dollar (that's not a typo!):http://www.uxcell.com/15pcs-dual-sides-smd-smt-qfn48-qfn44-05mm-dip-4844-254mm-pcb-adapter-plate-convertor-board-p-601340.htmlConstruction is very simple, only two wires on the back of the board with 2 pins for power (3.3v) and 2 for download (RX/TX). The only connections needed are available from a generic USB/serial adapter. Two more pins (SWDIO/SWCLK) allow trace capability but those can be added later for anyone who wants to investigate that. Depending on flash tools it might be required to set the BOOT0 signal. My own download program and/or ICE don't require it but the ST flash "demo" utility does. Schematic is attached although the circuit is simply the spec sheet reference design and so basic it's probably not needed. Notice the board is not much bigger than a quarter.I've also uploaded two zip files containing minimum tools for creating a program. Download and unzip both into a folder on your PC then type 'a' from command line or click on "A.BAT" (can also be viewed with notepad to see what it does). You'll notice a few new files are present. "T.S" (source) is assembled into a hex file which can be flashed into the chip then it's unassembled back into a human readable LST file as an example of reverse engineering. Both files are finally printed out for verification. You don't need a board to try this. The program is very simple. It increments a register and loops. As an experiment you can try editing the source, for example replacing #1 with #2, and see the effect on output.VIOLA! (cello too) You've now managed to accomplish something and go where many expert programmers fear to tread. IMO assembly is one of the best introductions for those interested in how a chip really works. Of course there's nothing to stop you from using the full complement of C/IDE setups with this board as you progress up the learning curve.EDIT: Another ARM platform, LPC this time, is supported with similar approach in reply #3 slot. One for STM8 too in reply slot #5 with a fully functional C compiler attached. Maybe PSOC4 and/or Silabs EFM series coming soon. If anybody knows of other candidates for the $1 one minute club please speak up.

author: paulie
author_rank: Frequent Contributor
timestamp: September 02, 2014, 12:19:31 pm
content: STM32F103 project continued here due to attachment space limit in first post:First photo shows a somewhat more useful DIY version with all pins being brought out and 8mhz crystal. There's still only two wires needed on the back of the PCB so very easy to build. It's functionally pretty much the same as those Ebay "blue boards" but about 1/4 the cost and a lot smaller. Connections to a USB/serial dongle are shown and BOOT0 set high ready to flash. Note that it's necessary to reset prior to download again and that this jumper must be removed to run a program stand alone. This is a link to the demo ST flash loader utility that works over a serial port:http://www.st.com/web/en/catalog/tools/PF257525. A super simple LED demo program is attached below.Second photo shows one of the blue boards hooked up to a $5 STlink clone ready for debugging/tracing. BOOT0 must be set opposite (run) compared to serial download for this to work. Warning: BOOT0 and BOOT1 labels are reversed on most of the Ebay boards so watch out for that. One mod was to remove the 2 useless pins next to the reset button so it can be pushed easier. Another mod I couldn't resist was to re-purpose that pointless power LED to a short cable that can be plugged into any of the pins. For me TX/PA9 is most useful because it can demonstrate either UART output or I/O blinky routines. Also flashes during download. Triple duty! I found the LED wasn't needed on serial download setups because the USB/serial adapter I use already has an onboard LED connected to that pin.Another zip file (LEDA9_01) is attached that has source and pre-compiled hex for flashing a PA9/TX LED program. It's very simple, only half dozen instructions and can be re-assembled using the tools in first post. When reset in run mode or flashed in boot mode with "user run" box checked the RX LED on the USB/serial adapter will light. If your adapter don't have an LED there then add one to the board from VCC through series resistor to PA9/TX (pin 31).As requested a third photo is added showing the bottom of the board with more detail on where those 2 wires (power/ground) go. Another photo shows the top of my "no crystal" board with reset button and a RUN/BOOT select switch. Note that the bootloader does not restore defaults but instead leaves many things initialized which can cause the user program to run when bootloaded but fail when reset in run mode. So it's necessary to set that switch to run (BOOT0 pin low) and reset again to be sure your code works. The button and switch are pretty much essential if you do this a lot. Note that just resetting in boot mode will not run the user program but waits for a new one to be loaded instead.Westfw has put together an assembly program that not only wiggles IO but shows how to set up the PLL for various system clock speeds. There's a discussion later on here regarding influence of wait states, multipliers, etc.. Very educational for those interested in how these chips REALLY work. Most of the internet C "tutorials" are by those who don't have a clue. Some say you must sacrifice this knowledge for productivity but IMO learning assembler not only allows for both but results in far superior coding skills. Anyway I've attached a version of the westfw file that has been modified to run on the $1 board. Quite a good example for showing what's actually going on under the hood and introducing things like conditionals and other source directives (pseudo ops). Also his quite useful .asmh include file which would be essential for those interested in serious development since the ST one only works with C. All this compiles with the tools from post number one.Another gem by westfw is added in here (WESHEL01). This time, in addition to a few more directives, we learn how to do subroutines and pass data. It initializes the UART and sends "hello world" continuously at 115kbps. Very conveniently uses the same pins as the bootloader so all you need do is to fire up Hyperterminal or similar to see the messages. Even without a comm program you can see the LED flicker as characters are sent. Just like the others simply copy to T.S and hit 'a' or click on it.More helpful hints from westfw in HELLO_ISR.ZIP. We get some code for printing out decimal numbers (WESDEC01.S) and another to show interrupt driven UART (HELLO_ISR.S). Reply #282 has a discussion of some new features. The second purposely uses a lot more ram and as a result uncovered an error in my orignal linker script. A new version of STM32.LD is included here with RAM set to 20k instead of 8k. Also a new version of the .ASMH file has more symbols defined to support the ISR program. Unzip into the same directory as first post then copy one of the new .S files to T.S and hit 'a'. At this point we have a set of tools up to the task for serious ARM development yet not beyond typical hobbyist abilities. A great contribution.I've attached a new batch file (A.BAT) that not only compiles but can also flash the chip and then run the program with a single key. No need to touch the target board at all anymore. This has major productivity advantages compared to the popular GUI/IDE approach. One requirement is that the STM flash demo utility be installed in a root folder called "STMFLASH". Note that you now need to connect DTR from the USB/serial dongle to pin 7 (nrst) and also put your own port number in place of the "5" in that batch file. Now we can code, download, and run just as easily as with the STM8.

author: PA0PBZ
author_rank: Super Contributor
timestamp: September 02, 2014, 12:29:39 pm
content: Quote from: paulie on September 02, 2014, 12:19:31 pmJust click theattachments and other optionsline and it will tell you:Allowed file types: doc, gif, jpg, pdf, png, txt, zip, tar, c, h, hex, bas, xls, odt, asm, wav, aiff, wma, mp3, flacRestrictions: 25 per post, maximum total size 2000KB, maximum individual size 1000KB

author: paulie
author_rank: Frequent Contributor
timestamp: September 02, 2014, 12:55:48 pm
content: So I've decided to reserve this slot for the LPC version of my ARM minimum development project. To start things off here's a zip file containing similar files to STM32 in first post but modified for LPC812M101JD20FP which is the lowest cost member of the family. Surprisingly, at a buck and a quarter, it was even cheaper than smaller siblings. A new linker script and slightly modified T.S is provided. Just like before simply copy these files to the same GCC directory used for STM32 and type 'a'.Sca introduced me tohttp://www.flashmagictool.com/which is a very compact and no nonsense programming utility. Just select device, com port, and file and you are ready to go. The photo below shows wiring for my "$1" DIY proto board. All thats needed is TX/RX (P0_4/P0_0) and ground ISP (P0_12).

author: nctnico
author_rank: Super Contributor
timestamp: September 02, 2014, 01:30:11 pm
content: Why not provide a link to ARM's own GCC distribution?https://launchpad.net/gcc-arm-embedded

author: paulie
author_rank: Frequent Contributor
timestamp: September 02, 2014, 04:25:37 pm
content: This slot is reserved for quick and ez STM8 assembler and C programming. I thought of putting this in the "STM32 ghetto" thread then realized that's technically not STM8 either and might be a big mistake in view of rampant asm-phobia there. So attached are zip files containing complete C and assembler toolset for creating STM8 programs. To start notice STM8ASM2 is only 150k! Anyway just unzip into a new folder and hit 'a'.To flash install STVP in a root folder (http://www.st.com/web/en/catalog/tools/PF210568):1. Hook up STlink as in the photo. $1 (actually 37 cent) DIY board is shown but one of the $3 Chinese "red boards" works too.2. Run STVP. Configure hardware=STlink mode=swim device=stm8f003f3 ok3. File/open (path)t.s194. Program/current_tab led toggles 3usEasily managed in less than a minute including download time. As an after class exercise maybe try using another pin. For example pin 1 instead of pin 2 by changing the #5 to #4.Someone else (besides me that is!) has expressed interest in STM8 assembly programming so on request I've put together an include file with equates for all the registers. Personally I like to have actual addresses in source with maybe symbolic names as comments. Others are not used to this so a cut-and-paste from the programming reference and few minutes spent using my emacs editor command recorder came up with this listing (STM8.H).I've also attached a complete C compiler toolset (SDCC). Remove the TXT extensions and extract both into a folder with 7zip. Type 'a' to compile the hello world demo which transmits continuously at 57kbaud from pin 2 (TX). The batch file also programs the chip automatically using the above SDVP which is expected to be in a root folder by that name. For those who like clicking on pretty menus the GUI procedure above can also be used but IMO just hitting a key is a lot easier and more productive.

author: nctnico
author_rank: Super Contributor
timestamp: September 02, 2014, 07:45:58 pm
content: I got the package in 15 seconds so I guess your bacon is safe with that package.BTW I like you stance to go bare metal.

author: zapta
author_rank: Super Contributor
timestamp: September 02, 2014, 07:49:24 pm
content: Quote from: nctnico on September 02, 2014, 01:30:11 pmWhat an awful page ;-)The download section is hidden in the fine print and when you get there is no binary for Mac OSX.

author: nctnico
author_rank: Super Contributor
timestamp: September 02, 2014, 08:07:01 pm
content: How do you mean the downloads are hidden on that page? There is a list with downloads on the right for every OS including Macintosh. I'm using Firefox version 31.0

author: bingo600
author_rank: Super Contributor
timestamp: September 02, 2014, 08:15:52 pm
content: Quote from: zapta on September 02, 2014, 07:49:24 pmAhem ... Cough..Coughhttps://launchpad.net/gcc-arm-embedded/+downloadAnd the Mac versionhttps://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q2-update/+download/gcc-arm-none-eabi-4_8-2014q2-20140609-mac.tar.bz2/Bingo

author: zapta
author_rank: Super Contributor
timestamp: September 02, 2014, 08:54:19 pm
content: Quote from: nctnico on September 02, 2014, 08:07:01 pmIt's a list of recently uploaded download that show on my computer with names shorten by '...' such that you cannot tell which is what.

author: zapta
author_rank: Super Contributor
timestamp: September 02, 2014, 08:58:12 pm
content: Quote from: bingo600 on September 02, 2014, 08:15:52 pm1 What main page link did you use to get to that download page?2 tar? bz2? This is not the common way to deliver precompiled Mac binaries (see the exe for windows)

author: nctnico
author_rank: Super Contributor
timestamp: September 02, 2014, 10:10:15 pm
content: The downloads are on the main page. What kind of browser are you using?

author: mrflibble
author_rank: Super Contributor
timestamp: September 02, 2014, 11:37:06 pm
content: The link to that download page is indeed displayed on that main page. It's labeled "All downloads", on the right side under that big green area with specific download files. Easy enough to find under 10 seconds. That said, the page layout could definitely have been better. Bit messy.

author: westfw
author_rank: Super Contributor
timestamp: September 03, 2014, 12:10:48 am
content: QuoteAre you really seriously proposing that people introduce themselves to ARM using gnu assembler and no include files to symbolically define the peripherals? (or is there actually a source for individual chip include files?)

author: nctnico
author_rank: Super Contributor
timestamp: September 03, 2014, 01:16:34 am
content: Quote from: westfw on September 03, 2014, 12:10:48 amHold your horsesHe's trying to upload the software and just notes this particular file of the entire package is too big.

author: westfw
author_rank: Super Contributor
timestamp: September 03, 2014, 01:39:14 am
content: BTW, before you go buying anonymous STM32F103 boards from random Chinese vendors via eBay, you might want to notice that the official ST STM32L100C Discovery board, with a somewhat more capable chip (256k+16k, "ultra low power") and the complete ST-Link debugging interface, is available from REAL distributors at prices ranging from about $8 (Mouser) to $16 (Newark)http://www.mouser.com/ProductDetail/STMicroelectronics/STM32L100C-DISCO/?qs=z4bnopryTCJyctHpd%252b9Nrg==The "Nucleo" boards (Arduino HW-compatible) are also available in several varieties for about $11 (more of a universal price, I think.)(no "free shipping" from real distributors, though.)There's got to be SOME price below which it no longer makes sense to go purchasing parts from three places just to save a few bucks. Especially if you're in it for the learning experience, and don't want to go through that "am I doing it wrong, or is it broken" phase. IMO, there isn't much excuse not to just spend $20, skip your friday-night-out dinner in favor of a sandwich,and JUST DO IT.(And it's not just ST. Freescale, NXP, TI ... they've ALL got ~$20 development boards. You can get a TI "Connected" Launchpad with 1M code, 256kB RAM, and ethernet for $21...)(These comments apply to 'learning.' If you're going to do like paulie and build a dozen quadcopter controllers, then of course if makes sense to use a bare chip and cheap PCB that you can use...)

author: zapta
author_rank: Super Contributor
timestamp: September 03, 2014, 02:52:02 am
content: Quote from: nctnico on September 02, 2014, 10:10:15 pmThis is what I get on my browser.1) The Download title is not a link.2) The file names are truncated and it's not clear if these are all the downloads or just a recent upload list.3) The link to the downloads pages is in the footprint (and no binary for Mac OSX)In addition the page is full of arbitrary details. Not a welcoming page for first time visitors that want to install the tool chain in one minute.

author: nctnico
author_rank: Super Contributor
timestamp: September 03, 2014, 08:10:20 am
content: You really need new glasses. One of the downloads in the list at 2 says 'mac' in the nameI doubt that will run on the ancient 68k or PowerPC macs.

author: eliocor
author_rank: Unknown
timestamp: September 03, 2014, 10:31:28 am
content: Typical MAC user...

author: dannyf
author_rank: Super Contributor
timestamp: September 03, 2014, 10:43:53 am
content: QuoteWow!No wonder Apple is such a cash cow.

author: zapta
author_rank: Super Contributor
timestamp: September 03, 2014, 11:47:38 am
content: Quote from: nctnico on September 03, 2014, 08:10:20 amIf didn't say that I couldn't find the downloads, I said that the design of that page is awful.

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 11:58:07 am
content: Schematic and programming demo uploaded to first post.Quote from: nctnico on September 03, 2014, 01:16:34 amActually Wes is right. That people introduce themselves to ARM using gnu assembler and no include files is exactly what I'm really seriously proposing. Include files are not required to create a simple program.My goal here is to show people, even those with no experience whatsoever, how to make a program. Not create a race of uber-coders. My philosophy is that starting out with MINIMUM hardware and MINIMUM software is exactly the most painless way to get into a new platform. Not the fanciest most expensive hardware and most complicated bloated toolset. There's time for that later.I also think that "cheapest" or "Most popular in an ebay listing" is an excellent indicator of "easiest next step". Those discovery boards are a great bargain but IMO not the best deal for anyone just wanting to check out a new chip. You can't buy one from Mouser for $8. Shipping will double that. At a buck or so (shipped) one can have a dozen of my DIY version or, for plug-n-play kiddies, a couple of the $6 "blue" boards. No matter the source, considering wait time, having backup in case of mis-step... PRICELESS.ps. Note that it's not possible to actually attach the Discovery files in a forum like this (we now know how tragically difficult navigating links can be) and nobody will manage to create code in less than a minute. It takes 10x that just to read the "Quick Start Guide".pps. Personally I find that GCC download page extremely well done. If you want to see real creativity in action check out some of the code repositories like google and github. Bizzare might be an understatement.

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 12:36:37 pm
content: I am not considering your a $1 to get into ARM ... but think your approach , walk before you run is right.... however starting with asm in my experience requires code examples and templates ... truck loads ! code that will not just flash a led , but serial and other comms , interrupt, AD and timer use.... all the building blocks for projects My electronic logic experience stretches back 40 years although you never stop learning .PS we don't all live in the US...

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 12:59:38 pm
content: Quote from: paulie on September 03, 2014, 11:58:07 amQuote from: 22swg on September 03, 2014, 12:36:37 pm? ? ? ? ? ? ? ?

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 02:26:21 pm
content: I had started to cost an $1 ARM here in UK considering european VAT and exchange rates , shipping it looked a bit more... ARM chip is $7 in UK.

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 03:17:40 pm
content: My 10 chips come in letter envelope and PCBs in small chinese "e-pak" envelope. Do they really hit you guys up for import tax on such small items?I shudder to think what happens with one of those "blue" boards or a Discovery.

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 03:37:10 pm
content: The 20% vat + post man adds something , sometimes the Chinese sender will put 'gift' on the packet and it slips through $14 would be probably end up as 20 GBP .

author: nctnico
author_rank: Super Contributor
timestamp: September 03, 2014, 03:45:37 pm
content: Quote from: paulie on September 03, 2014, 11:58:07 amI would recommend to start in C at least. But you are right: you don't need a heap load of other stuff. A C file (maybe with some macro's to access registers) and a linker description file is all you need to get a project compiled for ARM. IMHO a lot of IDEs obfustigate or hide what the compiler is actually doing.@22swg: usually there is an minimum amount before they start charging tax. Over here it is €35. But many Chinese just stamp 'gift' on a package.

author: mrflibble
author_rank: Super Contributor
timestamp: September 03, 2014, 04:02:56 pm
content: Quote from: nctnico on September 03, 2014, 03:45:37 pmYou sure about that €35? I thought it was tax free up to €22, as per this page:http://bit.ly/1jaJfNZ

author: janekm
author_rank: Unknown
timestamp: September 03, 2014, 04:13:00 pm
content: Quote from: 22swg on September 03, 2014, 03:37:10 pmNo VAT or Duty when importing into the UK and the value is < £15:http://www.hmrc.gov.uk/customs/post/buying.htm(note that technically postage has to be included in that).So long as final delivery is by Royal Mail and the declared value is < £15 (or thereabouts), it's extremely unlikely to get any charges added (our Hackerspace gets literally dozens of envelopes from China a week and never been charged to my knowledge).

author: westfw
author_rank: Super Contributor
timestamp: September 03, 2014, 04:35:26 pm
content: QuoteI assumed that arm-...-as would be smaller than arm-...-gcc (which it turns out is not true, apparently. Which is weird.)The .h files are typically no tiny marvels of modularity, either. Typical vendor strategy is to dump out a single .h file defining everything on a chip, for each separate chip part number. The TI tm4c123gh6pm.h file for the Tiva Launchpad is about 700k. (It should compress a lot, though.) (Hmm. stm32f10x.h is "only" 620kb.)

author: westfw
author_rank: Super Contributor
timestamp: September 03, 2014, 05:00:29 pm
content: Hmm. That's interesting. CMSIS apparently defines a standard format for include files that define a chip's peripherals, even though the internals of such peripherals are outside the scope of CMSIS. "Though shalt have structure definitions cast to constant addresses", more or less. Like:Code:typedef struct{__IO uint16_t SR;uint16_t RESERVED0;__IO uint16_t DR;: // etc} USART_TypeDef;// :#define USART2_BASE (APB1PERIPH_BASE + 0x4400)#define USART3_BASE (APB1PERIPH_BASE + 0x4800)// :#define USART2 ((USART_TypeDef *) USART2_BASE)#define USART3 ((USART_TypeDef *) USART3_BASE)That's fine, I guess. For C and C++. But the whole structure is useless to assembler programs!Are there typically NOT any symbol definition files for programming ARMs in assembler? Really?

author: zapta
author_rank: Super Contributor
timestamp: September 03, 2014, 05:01:05 pm
content: Quote from: paulie on September 02, 2014, 12:19:31 pmYou can have the in a new github project. Easier browse the file and to track modifications, and it's open to all and you can have the documentation with markdown, images, etc.

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 05:06:45 pm
content: Quote from: paulie on September 03, 2014, 11:58:07 am

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 06:32:37 pm
content: Seems to be a currency discrimination going on ? 3 ARMs for ~13GBP ... Thanks janekm no VAT if <15GBP , if it is Royal Mail will charge 8GBP fee..

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 06:57:07 pm
content: No, that's perfectly normal for Aliexpress. It's not unusual for prices to vary by a factor of 10. Even 100. Sometimes from the same seller. For example here's the first one that just came up for me without any special search terms:http://www.aliexpress.com/item/STM32F103C8T6-STM32F103-STM32F-LQFP48-NEW-ORIGINAL-IN-STOCK/529600954.htmlThese guys are tricky and often depend on careless shopping. Buyer beware!BTW anybody else notice Ebay is down?

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 08:18:53 pm
content: I'm thinking theres a risk of fakes or manufactures failures... where did the 48 pin boards come from please...

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 08:42:08 pm
content: Chinese "fakes" is an urban myth. Due to scale of mfg they would cost 1000 times more than the real thing. Parametric failures also rare. There are "refurbs" though which are highly sought after due to extremely low price and already "burned in". One lot of these f103 I was lucky to pick up for less than half dollar each. Unfortunately very seasonal. Wish I had got more then.See first post for link to PCB. As low as 15 for a dollar (7 cents ea) with coupon. Also available on Ebay but cost a bit more.Search is your friend with all these chinese sellers.

author: mikerj
author_rank: Super Contributor
timestamp: September 03, 2014, 08:58:46 pm
content: Quote from: paulie on September 03, 2014, 08:42:08 pmIn what context, just STM32's or semiconductors in general? If the latter then you should know that counterfeit semiconductors is a massive problem.

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 09:24:55 pm
content: Integrated circuits in general but mainly stories about MCUs. Based on personal experience and many other sources of info from sites like Microchip forum, Circuit Cellar, DIY Drones, Avrfreaks etc. Usually just typical internet bull but also morons blaming the seller for their own incompetence. Counterfeit chips is a romantic notion but considering the sources and their credibility very unlikely. Cloned board level products on the other hand is a different story.You are of course entitled to believe whatever you choose.

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 09:48:31 pm
content: http://blog.securecomponents.com/according-to-usa-today-the-nine-most-counterfeit-productsA different story ?

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 10:04:39 pm
content: I'm sure exhaustive search on the net can dig up convincing tales and statistics for virtually any argument.Although tabloids are not my favorite source of reliable information I'm willing to consider that "Consumer Electronics/Parts" are commonly counterfeited. Specially, as I said, PCB products. There are some cases of semiconductors but mainly jellybean parts like caps, resistors, and diodes. For example chinese 1n4007 that are curiously cheaper than the lower voltage 1n4001. Turns out leads use very low gauge copper hence fail the 1 amp spec. As part of the day job I purchase several hundred thousand dollars in parts every year. In last 15 years out of a handful of claims from clients, some few traced to parametric failure but vast majority due to customer abuse.ps. We all deserve to harbor favorite conspiracy theories and fantasies. This just don't happen to be one of mine. YMMV

author: 22swg
author_rank: Frequent Contributor
timestamp: September 03, 2014, 10:19:00 pm
content: I recognize your obvious experience , do you not ask yourself how come $1.30 water is dearer !

author: paulie
author_rank: Frequent Contributor
timestamp: September 03, 2014, 10:23:24 pm
content: LOL. I'm not sure what that means but if you are referring to bottled water I never touch the stuff. In several consumer protection assays orders of magnitude higher bacterial count than what comes from the tap.

author: westfw
author_rank: Super Contributor
timestamp: September 04, 2014, 10:06:36 am
content: Hmm. I think your sample program needs some work before it will work on a CM3 cpu.Code:.thumb.syntax unifiedDoes anyone know where I can find a definitive explanation of the gnu assembler syntax for ARM, specifically WRT "op2" operands and thumb2 instructions? I found some manuals with "fill in with an explanation later", but...

author: paulie
author_rank: Frequent Contributor
timestamp: September 04, 2014, 04:15:15 pm
content: Thanks for that. I'm sure you are a lot more experienced than me in these things and I appreciate the help. There's another bug. Without "pause" clicking on the batch file ran too fast to see so that is fixed too. "MC.BAT" has been added which removes output files similar to "make clean". New GCC zip files have been uploaded with all these corrections. I've also put up a photo of a more useful version of the DIY board in the second post (first is full). It shows the setup for flashing with the ST demo utility which I will document when I get a chance.The ST programming manual has details on instructions and architecture features:http://code.google.com/p/cortex-ap/source/browse/trunk/Firmware/Doc/CD00228163.pdfCD00161566.pdf is specific to f103 hardware. CD00171190 register details.Or just search CD00171190, CD00228163, or CD00161566. I hate those Google/Github type repositories but the no nonsense links are apparently too long for this forum. I'm sure you know but for those that don't right click on "raw" to download.Op2 is a flexible second operand that can be either a register or a constant. Compared to the 8bit world it's amazing how powerful ARM instructions are with tricks like that and the conditional feature built into most instructions. We all know assembly is not the tool for writing practical programs but I find it fascinating as a learning experience. Huge fun too IMO.

author: westfw
author_rank: Super Contributor
timestamp: September 04, 2014, 05:39:27 pm
content: QuoteWell, no. But it's an interesting exercise.QuoteExcept that this documents the official ARM instruction syntax, and has examples using the ARM assembler syntax, and that's NOT quite what the gnu assembler actually implements. gas happily ignores manufacturer syntax in favor of something that is maximally "common" across the architectures that it supports, or is convenient to the C compiler, or something. As a minor ridiculous example, the comment character in gnu as for ARM is "@" instead of ";"I was going batty trying to figure out how to get it to accept my blink program (from the ghetto thread) which compiled fine in Keil (official) assembler. Most of that seems to have been solved by the ".syntax unified" addition (which I'm still not sure is the correct thing for cm3/etc.) But I still have the gnu assembler generating different code than Keil for "sub r1, r1, #1" instruction, and I don't know why :-(Here's my contribution; I edited the CMSIS stm32f10x.h file provided by ST to make it usable by the gnu assembler. This provide the base address of the various peripherals, and the various bit constants for registers, but it doesn't include the offsets of registers within a peripheral (which are implemented via structure definitions in the original. Mostly, this version replaces #define with .equiv)Edit 6-sep: new version of .asmh file; now includes GPIO peripheral offsets and better bitvalues.2nd edit 6-sep: defines for the RCC individual registers.3rd edit 9-sep: create some macros to allow easier conversion from C structures for ASM offset definitions, and include most of the peripheral data structures from the .h include file.4th edit 10-sep: new version (including a sample that assembles) attached here:https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg511012/#msg511012

author: paulie
author_rank: Frequent Contributor
timestamp: September 05, 2014, 01:19:59 pm
content: Wow! I really appreciate the work you put into that and certainly anybody else who wants to experiment with ARM assembler will too. An update on any progress you make porting your blink to AS would also be of great interest.I'm having problems with hex file generation. It's not obvious to me if it's as, objdump, or the linker causing trouble. Apparently the ST flash utility expects an Extended Linear Address record and zero offset for the code which my script AS is not doing. For example the utility generates "incorrect address" errors trying to flash this version of my demo:Code::08800000010080E2FEFFFFEA2F:040000030000800079:00000001FFBut no problem loading this version from a homebrew assembler:Code::020000040800F2:08000000010080E2FEFFFFEAAF:040000030000800079:00000001FFAny hints how to get AS to assemble at zero offset instead of 8000? I tried .org and that don't help.

author: nctnico
author_rank: Super Contributor
timestamp: September 05, 2014, 01:55:20 pm
content: You need to use a linker descriptor file otherwise LD will use some defaults. It helps to tell LD to also create a map file so you can see which code went where in the memory.

author: paulie
author_rank: Frequent Contributor
timestamp: September 05, 2014, 02:22:38 pm
content: Success! Those scripts were used a lot in my C projects but never paid much attention to. Anyway just copied the ld file from one of my C directories over then added -T to the cmd line and it worked like a charm. Thanks, Between you and Westf I may have a chance at getting this right after all.

author: dannyf
author_rank: Super Contributor
timestamp: September 05, 2014, 04:52:18 pm
content: It is very difficult to imagine that a beginner starts on those chips in assembly.To work on a reasonable project on those chips in assembly, you have to be an expert or you have tons of resources (time+money).

author: westfw
author_rank: Super Contributor
timestamp: September 06, 2014, 01:47:02 am
content: $1 is a bit misleading. You're talking about spending ~$10 for enough stuff to make 10 boards. Plus at least a USB/Serial cable to connect it to something. Which is only subtly different, I guess, but still... (this is not dissimilar from my very first arduino-related purchase. 10 bare board, 5 chips, and an FTDI cable from MDC. And the fact that I COULD do that was pretty instrumental in my ever becoming involved with Arduino.)I've ordered some STM32f103c8t6 hardware. $10 for a pre-built single board shipped from closer than China. It feels a bit funny, since I already have several ARM-based development boards lying around, but in view of arguments I've already made about the prices, I can hardly complain that it's too much money to spend on an interesting experiment.QuoteI agree entirely. Assembly is "not used" in the ARM world. The chip documentation does not include assembly examples, and community software is not written in assembler (and there's no symbol files for asm, aside from what that nut posted here...) What assembly you CAN find uses the official ARM syntax, which I've mentioned is not the same as the Gnu assembler syntax.That said, I think the concept of providing a "reduced" toolset has a lot of validity to it. A "1-minute download" is unnecessary, but it would be nice not to have to go searching all over the internet for the various pieces needed to get started, an not wind up with a "choose processor" menu containing hundreds of chips.I wonder if something based on the Arduino download would be a good starting point. It's already got win/linux/mac versions of a complete compiler toolchain, and its about a 200MB download (even with the complete AVR toolset as well.)

author: westfw
author_rank: Super Contributor
timestamp: September 06, 2014, 06:14:41 am
content: Well, this is crap:Code:#define GPIO_CRL_MODE3 ((uint32_t)0x00003000) /*!< MODE3[1:0] bits (Port x mode bits, pin 3) */#define GPIO_CRL_MODE3_0 ((uint32_t)0x00001000) /*!< Bit 0 */#define GPIO_CRL_MODE3_1 ((uint32_t)0x00002000) /*!< Bit 1 */:#define GPIO_CRL_CNF3 ((uint32_t)0x0000C000) /*!< CNF3[1:0] bits (Port x configuration bits, pin 3) */#define GPIO_CRL_CNF3_0 ((uint32_t)0x00004000) /*!< Bit 0 */#define GPIO_CRL_CNF3_1 ((uint32_t)0x00008000) /*!< Bit 1 */Thank you SO much for giving me a bunch of long and meaningless names to refer to the bits used to configure the GPIO ports. They must REALLY want people to use their peripheral library instead of "bare metal." Unfortunately, it looks like the peripheral library is pretty questionable as well:Code:#define IS_GPIO_PIN(PIN) ((((PIN) & (uint16_t)0x00) == 0x00) && ((PIN) != (uint16_t)0x00))(I guess it's a good thing that no one actually turns ON those "assert" checks?)grr...Edit: I guess it's not quite as bad as I thought, but it doesn't inspire confidence, either...

author: paulie
author_rank: Frequent Contributor
timestamp: September 06, 2014, 03:41:01 pm
content: Quote from: dannyf on September 05, 2014, 04:52:18 pmOr crazy. Pretty much everyone agrees C is the way to go there but for a quick start to test hardware and getting an understanding of how a chip really works I think ASM can't be beat. IMO your comment about resources seems way off base. If I'm not mistaken this thread is the first and only time 100% functional tools for creating a program have actually been attached and not just linked. Many will not even have the courtesy to do that.And one or two bucks for working hardware is "tons of money"? Hmmmm... Also note that last night I won a bet with a buddy by downloading then creating and verifying a program in less than 40 seconds. True I'm very familiar with the steps involved (hit 'a') but this was phone line internet!This don't look like "tons of resources (time + money)" from my viewpoint.BTW The GCC file in first post has been updated with STM32.ld. That demo program seems to behave just as expected stepping through with GDB/OOCD now.

author: leppie
author_rank: Frequent Contributor
timestamp: September 06, 2014, 04:06:14 pm
content: The STM32 Nucloe range is pretty impressive at just over $10 a pop.http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1847Compared to an Arduino you get a lot more.

author: zapta
author_rank: Super Contributor
timestamp: September 06, 2014, 04:45:25 pm
content: Quote from: leppie on September 06, 2014, 04:06:14 pmDoes it come with a single package install IDE that runs on all three major OS's. ?It's the overall package that counts.

author: westfw
author_rank: Super Contributor
timestamp: September 06, 2014, 09:35:42 pm
content: QuoteOh, I think you'll get a pretty good understanding of things trying to code in C without libc to back you up :-)I think what makes this project interesting is that we're learning DIFFERENT things than you learn by throwing up the vendor or hobbyist toolset and coding away with the provided libraries and IDE. It's an excercise in what tools actually do what, and which ones are needed, and in how crappy (or not) the define files are, and in what's actually happening under the hood of an IDE when you click the "build" button. (for example, I was SHOCKED that xxx-gcc.exe is about the same size as as xxx-as.exe. Even supposing that there is a separate xxx-cpp to handle C preprocesing (also "about the same size"), I had still assumed that the C compiler itself would be bigger... And ah hah! cc1.exe is out there in the lib directory; apparently not considered a user executable and thus not in the bin directory. (and yes, it's pretty huge.)

author: nctnico
author_rank: Super Contributor
timestamp: September 06, 2014, 09:45:57 pm
content: IMHO it would serve many people well if they spend some time on how the build process actually works. Unfortunately they don't even teach that in schools/universities.

author: leppie
author_rank: Frequent Contributor
timestamp: September 06, 2014, 09:52:16 pm
content: Quote from: zapta on September 06, 2014, 04:45:25 pmIt support MBED, and normal embedded IDE's. So I would say yes.

author: mrflibble
author_rank: Super Contributor
timestamp: September 06, 2014, 10:25:30 pm
content: Quote from: zapta on September 06, 2014, 04:45:25 pmIt comes with a free "How to put together your own toolchain" lesson that will serve you well for the rest of your life.That said, sometimes an easy starting point is nice to have as well. Just so you have aknown to worksituation, and then you branch out to from that to put together the dev environment you really need. Or you pay $$$ to buy something that is just that. Or is almost that, but not quite. Nothing is ever free. Either you flush time, or you flush money.

author: westfw
author_rank: Super Contributor
timestamp: September 06, 2014, 11:14:20 pm
content: New .asmh file added inhttps://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg507400/#msg507400My source code now looks like:Code:.include "stm32f103c8.asmh".syntax unified@ BLINK in ARM Assembler@ For ST32F103c8t6, perhaps@ Aug 2014, by Bill Westfield - released to Public Domain.@.equ STACKSIZE, 1024.equ HEAPSIZE, 8192.globl __VectorsVectors: .word SRAM_BASE+HEAPSIZE+STACKSIZE@ Top of Stack.word __start + 1 @ Reset Handler@ The program itself..equ myport, GPIOA_BASE@ must be portA....equ mybit, 6@ arbitrary bit choice, for now._start:.globl _start__start:ldr r0, =RCC_APB2ENRldr r1, @ old valorr r1, r1, #RCC_APB2ENR_IOPAEN @@ enable PORTA clkstr r1, nop@ Wait for PORTF to get clocked.initf:mov r1, #((GPIO_MODE_OUT+GPIO_CNF_PP) << (mybit*4)) @@ output bitsldr r0, =GPIOA_BASE@ GPIO_PORTFstr r1, [r0, #GPIO_CRL_O] @ set bit to outputmov r2, #(1<<mybit)@loop:ldr r1, [r0, #GPIO_ODR_O] @ read DATA regeor r1, r2@ complement bitstr r1, [r0, #GPIO_ODR_O] @ writemov r1, #(4*1024*1024)@ Delay countdelay:subs r1, r1, #1@ decrementbnedelaybloop.end

author: paulie
author_rank: Frequent Contributor
timestamp: September 06, 2014, 11:47:29 pm
content: Quote from: westfw on September 06, 2014, 09:35:42 pmDefinitely. I've been building controllers with this chip for almost a year but in the last 48 hours of this thread have picked up more information (and inspiration) than all that time. Several failed attempts involving IAR demo and some other Eclipse based packages did little to arouse my interest. I felt like part of the Human Centipede with first guy connected to the last, recycling the same waste endlessly. It wasnt until starting to play with the inner workings of GCC things got really exciting.BTW I just tried your program with the new include and got something about RCC-APB2ENR in delay undefined. Have you tried this on real hardware? Did your F103 board arrive yet?I cant' wait to see how this turns out.

author: westfw
author_rank: Super Contributor
timestamp: September 07, 2014, 05:07:06 am
content: QuoteAhh. It turns out I wasn't running my output through the linker. The as command produced an a.out file, and I assumed that it was done (sort of like the way the c compiler works.) But apparently not... I'll upload a new file.I'm expecting the hardware next week; I only paid extra to get it shipped from the US instead of China, not for "expedited shipping."

author: westfw
author_rank: Super Contributor
timestamp: September 07, 2014, 06:09:57 am
content: (new asmh uploaded.)The thing is... I spent the first six years or so of my career programming almost exclusively in assembly language. The OS and all the system utilities were written in assembly language, because that was How Things Were Done, on that particular system at that particular time. And there was a WONDERFUL macro assembler, and a huge set of standardized macros for defining and using higher-level language concepts (structures, local variables, stack frames, looping and conditional code structures..) And there was a relatively large set of programmers working on similar stuff who would discuss such things. And the machine language was elegant and cool... It was great!If you're coming from an 8-bit microchip PIC environment, you've seen some of this sort of thing (minus the elegant machine language :-))But ARM doesn't have any of that, as far as I can tell. It has an assembler designed to assemble code output by a C compiler, and a machine language designed to be used by compilers and efficient to implement in hardware. And everyone programs it in C. Writing in assembly language for such a chip is ... ill fated (like the song: "kinda like construction work, with a toothpick for a tool.)

author: paulie
author_rank: Frequent Contributor
timestamp: September 07, 2014, 09:54:10 am
content: Quote from: westfw on September 07, 2014, 06:09:57 amNot true. There's you and me, so at least two now. Maybe three if you count that fellow in Nyurba. LOL

author: westfw
author_rank: Super Contributor
timestamp: September 07, 2014, 10:07:41 am
content: Sorry; I program ARMs in C. I think it's interesting to contemplate some basic programming in asm, and I'm certainly willing to LOOK at the asm produced by the compiler (which seems to be a rare thing; people think they need to be an expert at the asm to learn something by looking at the compiler output. they're wrong...) But I have no real interest in actually writing any full programs in ARM asm. Just the occasional optimization, subroutine, or "educational exercise."

author: paulie
author_rank: Frequent Contributor
timestamp: September 07, 2014, 10:29:04 am
content: Ok, so there's just me and maybe that guy in Russia. I'm determined to write something in ASM that works if it kills me. Even if it's just to flash a LED or send a character. Almost everything I've picked up so far comes from reading the list file. After poking a CRLF and fudging the RCC to quell the errors here's what AS thinks you want to do:Code:08000008 <_start>:8000008:e59f0038ldrr0, [pc, #56]; 8000048 <delay+0xc>800000c:e5901000ldrr1, 8000010:e3811004orrr1, r1, #48000014:e5801000strr1, 8000018:e1a00000nop; (mov r0, r0)0800001c <initf>:800001c:e3a01401movr1, #16777216; 0x10000008000020:e59f0024ldrr0, [pc, #36]; 800004c <delay+0x10>8000024:e5801000strr1, 8000028:e3a02040movr2, #64; 0x400800002c <loop>:800002c:e590100cldrr1, [r0, #12]8000030:e0211002eorr1, r1, r28000034:e580100cstrr1, [r0, #12]8000038:e3a01501movr1, #4194304; 0x4000000800003c <delay>:800003c:e2511001subsr1, r1, #18000040:1afffffdbne800003c <delay>8000044:eafffff8b800002c <loop>8000048:00001234andeqr1, r0, r4, lsr r2800004c:40010800andmir0, r1, r0, lsl #16I'll admit it don't make a lot of sense to me ATM. Particularly those load stores. My own version to flash an LED isn't quite there yet either. I'm beginning to think it may actually take me more than 3 instructions to do it but we shall see.ps. What does the "=" mean in your operands? I see it appends data to the binary but why?It's also surprising you abandoned the ".thumb" directive. Was that intentional?

author: paulie
author_rank: Frequent Contributor
timestamp: September 07, 2014, 12:13:16 pm
content: Good news. I've finally got that damn LED to flash. It didn't take 3 instructions as predicted. Only 2! This is great. Now to see if a character can be sent out via UART. I'm not going to worry about baud rate for now. Just get anything to squirt out then maybe adjust clock to get it right as a next step.

author: westfw
author_rank: Super Contributor
timestamp: September 07, 2014, 08:41:44 pm
content: QuoteThat's interesting. You're getting 32bit instructions. Oh, I think I see. I had removed the .thumb directive, because it seemed to be doing the same thing as the -mcpu=cortex-m3 option in my compile line, but you probably aren't using that option...QuoteThe ARM doesn't have a "load from 32bit address" instruction, nor an instruction to load an arbitrary 32bit constant intro a register. (presumably because those would make instructions 64bits long, screw up the pipeline, and stuff like that.)Every load instruction has an index register, and a relatively small offset (<4096) from that index register.So the usual way to access a peripheral register is to load its address into an index register, and then access it via the index register.And the usual way to load a 32bit address into an index register is to stick that constant in memory "near" the code that needs it, and access it by indexing off of the PC register. The "=constant" assembler structure sets that up for you; plunks the constant in nearby code space and sets up a pc-indexed instruction to access it.Interestingly (?) MIPS code on PIC32 has similar limitations on constants, but the compiler produces sequences like "move the high 16bits of the constant into the high 16bits of the register, OR the register with the low 16bits of of the constant."

author: paulie
author_rank: Frequent Contributor
timestamp: September 08, 2014, 01:28:22 pm
content: Thanks for that explanation. I was aware of the difficulty loading 32bit immediates but wasn't up to speed on '=' symbol so was using a rather crude method. Now my own LED program is much cleaner.Regarding the .thumb issue the source directive does behave slightly different than command line option. NOP actually comes out NOP (bf00) with the latter but mov r8,r8 (46c0) with the former. Don't really matter I guess but interesting.BTW to compensate for the missing .equiv in your .asmh file, in order to stop the undefined error message I added the following line to your version:.equ RCC_APB2ENR,0x40021000ps. It compiles ok now. I had some trouble failing to reset at first but it blinks fine. Congratulations, I was proud of myself for managing to turn on the LED but looks like you are the first person to ever actually continuous blink in assembly.

author: westfw
author_rank: Super Contributor
timestamp: September 08, 2014, 03:33:23 pm
content: Well, days ago, for a different ARM, different assembler:https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg503594/#msg503594I've decided that I REALLY dislike "@" as a comment character.Here's the code with "homework" style comments:Code:/** BLINK in ARM Assembler* For ST32F103c8t6, perhaps* Aug 2014, by Bill Westfield - released to Public Domain.*/.include "stm32f103c8.asmh".syntax unified.thumb/** Options settable by the user.*/.equ STACKSIZE, 1024.equ HEAPSIZE, 8192.equ myport, GPIOA_BASE/* must be portA... */.equ mybit, 6/* arbitrary bit choice, for now. *//** The ARM needs at least two words at the start of the flash that* specify the initial stack pointer and the reset start address.*/.globl _Vectors_Vectors: .word SRAM_BASE+HEAPSIZE+STACKSIZE/* Top of Stack */.word _start + 1 /* Reset Handler (thumb!) */.globl _start_start:/** In order to use the GPIO ports, you first have to enable* a clock to that port. This is done through the "Reset and* Clock Control (RCC) structure, but there are random different* registers/bits depending on which bus has the peripheral.** C equivalient: myClkCtrlReg |= myClkEnaBit;*/ldr r0, =RCC_APB2ENRldr r1, /* old val */orr r1, r1, #RCC_APB2ENR_IOPAEN /* enable PORTA clk */str r1, /** Now set up the GPIO pin for output. Each pin is controlled* by 4 bits in the CRL or CRH register (depending on bit)** C equivalient: mygpio.CRx = MYGPIOMODE<<(myBitPos);*/initf:mov r1, #((GPIO_MODE_OUT+GPIO_CNF_PP) << (mybit*4)) /* output bits */ldr r0, =GPIOA_BASE/* GPIO_PORTF */str r1, [r0, #GPIO_CRL_O] /* set bit to output *//** Now loop around and toggle the GPIO pin.* While the port has atomic set/reset ports, I'm going to just* do a non-atom read and xor.** C equivalient: while (1) { mygpio.ODR ^= 1<<mybit ; }*/mov r2, #(1<<mybit)/* put the bit mask in a register */loop:ldr r1, [r0, #GPIO_ODR_O] /* read DATA reg */eor r1, r2/* complement bit */str r1, [r0, #GPIO_ODR_O] /* write *//** Delay loop. I pick a constant that's a power of two so that* a single instruction with a shifted 8bit constant will be used.** C equivalient: for (uint32_t i=4096*1024; i != 0; i--) {}*/mov r1, #(4*1024*1024)/* Delay count */delay:subs r1, #1/* decrement */bne delayb loop.end

author: timb
author_rank: Super Contributor
timestamp: September 08, 2014, 04:08:37 pm
content: Quote from: zapta on September 02, 2014, 08:58:12 pmUh, Tarball files are a very, very common way of delivering development tools on the Mac. Since OS X is running a delicious chewy *NIX core, the built-in Archive utility will de-compress them just fine straight through Finder.This is not some GUI based development tool. You have to use it through the command line anyway, so why would you expect them to package it in a DMG?Sent from my Smartphone

author: paulie
author_rank: Frequent Contributor
timestamp: September 08, 2014, 11:32:31 pm
content: Quote from: westfw on September 08, 2014, 03:33:23 pmI also dislike that queer '@' but the C convention '/*...*/' strikes me as a big pain in the ass too so it's C++ '//' for me. What's even stranger is the disassembler uses ';'. There are other issues that cause LST code to not compile. Not a good thing for GCC or any other assembler IMO.Anyway we have a problem Houston. These routines blink fine when run from the bootloader but fail miserably on reset or power up. I've attached a file for your program called noblink.hex and one for one that doesn't misbehave in this way, blink.hex (PB3). WTF. It looks like it should work but we are missing something. Maybe hw faults so full blown vector table is required. That is one difference compared to the working one. Maybe the bootloader is failing to enter with reset defaults (BAD bootloader!). It's not register dependency lost on power down because simple reset acts the same. One of the Ebay blue boards is being used for these latest tests to minimize chance of hardware incompatibilities but same thing with the DIY. IDK.

author: westfw
author_rank: Super Contributor
timestamp: September 08, 2014, 11:52:32 pm
content: QuoteProbably some sort of necessary clock initialization. The TI tiva i've been playing with has some reasonable defaults and just runs things slowly if you haven't done anything, but it wouldn't be unusual for there to be more...

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 12:18:07 am
content: Quote from: westfw on September 08, 2014, 11:52:32 pmIt's not obvious how that could happen. At reset PLLON is clr but HSION is set so should be running, maybe not maximum speed. I don't see how any application could run without a crystal if that's the case yet the example I posted does. What a mystery.If somebody could post a small hex file for one of the ST C demos or some other popular blinky I could get to the bottom of this quickly. Unfortunately I'm not set up for that ATM.

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 01:27:39 am
content: QuoteThis is why no body can afford to code in assembly if her/his time means something, anything.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 01:52:48 am
content: It's amazing how many don't get this. Just jump to the end of a thread and start making noise. I will repeat that the intent here is not to create a race of human centipede uber-coders. I can program in C and spend a lot of time doing that. The goal here is to develop a set of absolute MINIMUM tools for a common ARM device pretty much for the sake of doing just that. Understanding more about the machine and tools is an incidental but IMO beneficial side effect.As insane as it sounds a buddy of mine actually builds quite fancy ships inside a wine bottle using tweezers and teriyaki sticks. No matter how often I try to explain that it would make much more sense to simply assemble one on the tabletop and put it inside a peanut butter jar he just won't listen. Some people!If you want to contribute something constructive how about attaching one of those really small blinky images you brag about all the time. You know, for this chip. We know you have the tools.

author: miguelvp
author_rank: Super Contributor
timestamp: September 09, 2014, 02:06:40 am
content: I do love assembler, but on mips, arm or any other RISC processor I rather use C or C++.They usually have enough memory and speed that really doesn't matter, but I do get the power of assembly and once you have a bunch of cool modules done you can link them to your C code

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 02:08:00 am
content: lol.

author: miguelvp
author_rank: Super Contributor
timestamp: September 09, 2014, 02:27:45 am
content: Quote from: paulie on September 09, 2014, 02:08:00 amI'm not really kidding, but for example for Arm processors that don't have native floating point or even integer division like the M0 assembly is the way to implement it.So anything related to inner loops, assembly will give you an edge, the upper control stuff doesn't matter much since everything can run at 100 Hz now a days and a couple of microseconds is not going to make a difference at that level.

author: mrflibble
author_rank: Super Contributor
timestamp: September 09, 2014, 03:09:57 am
content: Saturating arithmetic also is a legit use of asm om arm as far as I'm concerned. Mostly as inline assembly used from C. But indeed, sometimes constructing a fast loop in asm can be fun too. Only to find out later that in some (but not all) cases the optimizer does a better job than you.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 03:30:15 am
content: Yes, it's hard for a human to compete with some of these compilers and GCC is pretty damn good for the money. I'd say that 99% of the assembler I've learned came from examining list files of C routines. The big problem is compiler overhead. For example my LED routine comes out a little over 100 times bigger when compiled instead of assembled. Of course the difference is much less with programs of significant complexity.

author: andyturk
author_rank: Frequent Contributor
timestamp: September 09, 2014, 03:31:42 am
content: Quote from: paulie on September 09, 2014, 01:52:48 amWell, "absolute MINIMUM" and "common ARM" are conflicting requirements. The minimum requirement puts you in the lair of the RCC/clock dragon, which blasts different fire for each OEM. If you were willing to leave the teriyaki sticks in the kitchen, you could do a nice minimum build over CMSIS, slaying the RCC beastie with a single call to SystemInit(). That would be in C, of course, but you have to choose: macho assembler warrior or stealthy C assassin?To regain some nerd cred, you might consider re-writing the post-initialization blinky bits in GCC's inline assembler. That would be sufficiently awful to keep the pragmatists off your doorstep and entertain the eastern European whiz-kids.I'd post a .hex, but all of mine have an RTOS in the middle.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 03:40:48 am
content: Quote from: andyturk on September 09, 2014, 03:31:42 amI disagree. The device I've chosen is more popular than it's next competitor by a huge margin if listing statistics on places like Ebay, Aliexpress, and many other websites are an indication. And when you have attached a fully functional toolset to a forum like this instead of just links that argument would be more convincing.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 03:43:54 am
content: RTOS. lol.

author: mrflibble
author_rank: Super Contributor
timestamp: September 09, 2014, 04:22:02 am
content: RTOS lol yes. I suffer from the same affliction. RTOS, C, C++, asm all rolled up in one project. Because ... why not?You use whatever tool gets the job done.Programming in asm every now and then is fun, but I'm definitely not going to write entire applications in it.

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2014, 04:44:39 am
content: QuoteI was thinking something like "well, the CPU clock defaults to the 8MHz internal HSI, and you enabled the clock from the APB2 bus to the GPIO port, but you forgot to turn on the clock for the APB2 bus itself." (though it doesn't look like that should be necessary.) Or perhaps I can't use GPIO_Speed_10MHz if the clock is only 8MHz.Then there is the (horribly documented) APB2RSTR register...

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2014, 09:00:06 am
content: I put up a new version of the .asmh file.It includes some macros STRUCTDEF/STRUCTEND and support infrastructure, to allow simple C structures to be relatively easily converted to assembler symbols. So code that looks like:Code:/*** @brief CRC calculation unit*/STRUCTDEF CRC__IO uint32_t DR;__IO uint8_t IDR;uint8_t RESERVED0;uint16_t RESERVED1;__IO uint32_t CR;ENDSTRUCT(which is easy to get from the C-style .h file using some editor keyboard macros) ends up producing assembler that defines CRC_DR=0, CRC_IDR=4, CRC_RESERVED0=5, CRC_RESERVED1=6, CRC_CR=8...And then I added all the stm32f103 peripheral internal structure definitions.(The CAN peripheral is incomplete. A CAN peripheral apparently includes arrays of CAN_TxMailBox structures, and my macros aren't up to doing nested structures.)This requires a bit of editing of the blink.S sketch I posted (remove the _O from the offset names of the manually-defined GPIO peripheral registers.)(Needless to say, this has not been extensively debugged.)I suggest adding "-mcpu=cortex-m3" to the assembler command line, and you might want to consider "-asl=blink.lis" to generate a "significantly aware" listing file (which has advantages and disadvantages. The concise output produced by objdump is ... concise. The assembler listing ... isn't. (91 pages for blink.lis Mostly the (largely useless) bitmask symbols, which could be omitted by using -al=blink.lis instead.)

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 10:31:47 am
content: QuoteI didn't want to deprive you of the hardly earned bragging rights of developing an almost-working blinky after a few days. That must be the longest one minute in history,Yes, I have the tool.But, I don't have the time to waste.

author: Kjelt
author_rank: Super Contributor
timestamp: September 09, 2014, 10:33:48 am
content: Assembler only when C is not sufficient, for instance with large multiplications you can not transfer the carry with CThe assembly routine is much faster. But there you can use inline assembly.People who write everything in assembler are probably from the 80's where you had 256 byte ROM sizes, now with modern ARM controllers going >2MB ROM good luck, would love to see someones IP stack written in assembly

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 10:38:27 am
content: Quoteor a fft routine fully in assembly.Writting assemblies has its place: when you are pushing the envelope of performance or resources (tons of money for example).Most of us just cannot afford to write in assembly, in terms of skill, resources (time included), or necessity. C is much cheaper.

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2014, 10:58:37 am
content: Heh. Implement the core arduino functions, in asm, designed to be called from asm...

author: nctnico
author_rank: Super Contributor
timestamp: September 09, 2014, 11:35:58 am
content: Quote from: dannyf on September 09, 2014, 10:38:27 amThere are very few places where an assembly programmer can create faster code than a C compiler nowadays. A C compiler can take caching, branche prediction, pipelining, etc into account. Besides that it is often much more efficient to choose a better algorithm (or come up with one) than trying to speed up a less efficient algorithm.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 12:54:03 pm
content: I agree. These GCC routines were developed over many years by some of the top assembly language coders in the world. I know the examples I've extracted from list files were impossible for me to improve in terms of speed or size. IIRC more than once on forums like AVRfreaks (where asm is also feared by many) challenges were proposed but few succeeded. I think the only fellow who did was that Russian guy who got banned by shamed and frustrated mods. Another example might be the Multiwii project where expert coders spent huge effort to speed up cycle time, including hundreds of posts dealing with assembly tweaks, with little or no actual benefit.

author: zapta
author_rank: Super Contributor
timestamp: September 09, 2014, 01:43:04 pm
content: Quote from: paulie on September 02, 2014, 12:13:01 pmThis thread went completely off from being 'simple' or 'intro'.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 02:29:37 pm
content: How did I know you were going to say that? Evidently "simple" is in the eye of the beholder. Last week I didn't just link but actually attached a 100% functional set of tools for creating ARM programs. This was the first time anything even close was done here or any other forum AFAIK. I also set up a script that involves hitting a key on your PC keyboard or clicking with a mouse. I don't think anything like that has ever been done before either. Also note that these scripts are so small and simple can fit into text files of a couple dozen bytes.The "zapta challenge":Quote from: paulie on September 02, 2014, 12:03:36 amSo I'm quite pleased and really do not require recognition or complements because it's obviously hard to say anything with those human centipede stitches in ones mouth.BTW With some help from an offline hex (actually elf) contribution and oocd the mystery of why westfw code don't run on reset is solved. Unbelievable.

author: zapta
author_rank: Super Contributor
timestamp: September 09, 2014, 02:54:56 pm
content: Quote from: zapta on September 09, 2014, 02:54:08 pmBecause it's true.In the other thread you said that you will recover a simple ARM introduction that you presented in some ham club but this thread doesn't deliver.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 02:57:17 pm
content: Quote from: zapta on September 09, 2014, 02:50:08 pmHow did I know you were going to say that? LOL

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 03:33:52 pm
content: Girls, play nice and don't fight with each other.QuoteIf that's the case, why waste time on creating a half-functioning assembly code? Give people .axf and you are done.If you want to see how others have done this, check out some of the stm8 software usb examples on the web.Blinking an led on this board (or pretty much any other board, arm or not) is fairly easy, especially for a C expert like yourself. Why compete where your skills are none by writing in assembly?If you cannot write a blinky in C, I posted a short piece in the ghetto thread that blinks an led on any STM32F10x chips. It would be a ride in the park for a seasoned C programmer like yourself to get it going on your hardware.From where I sit, you haven't demonstrated the need, skills or resources to code in assembly.

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2014, 03:42:47 pm
content: Quotehttp://pdp-10.trailing-edge.com/SRI_NIC_PERM_SRC_1_19910112/01/6-1-monitor/tcptcp.mac.html(and several related files.)(If you do read through this code, keep in mind that it is/was one of the very first TCP implementations!)

author: Kjelt
author_rank: Super Contributor
timestamp: September 09, 2014, 05:55:52 pm
content: Quote from: westfw on September 09, 2014, 03:42:47 pmThanks, and you have proven my point, this kind of code is totally unmaintainable or expandable (someone wants to add the TLS1.2 spec to it?)But indeed in the 80s a lot of code was written in assembly, most of the consumerelectronics were written in assembly. My first steps into microcontrollers (8048) were in assembly, but that does not justify to keep on using it in the 21st century (unless it is for hobby like puzzles).

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 05:59:17 pm
content: Quote from: dannyf on September 09, 2014, 03:33:52 pmI'm surprised so many keep missing the point but I don't mind repeating.Because the intent was to provide a set of ARM tools that are basic enough to attach to a forum not just link and set up so even a beginner can download and test in less than a minute. That's what I claimed and that's what I did. This has never been done before, here or anywhere else.Quote from: dannyf on September 09, 2014, 03:33:52 pmCopying off the net is your game. For my current purpose trailblazing has proven more productive. At least for this project. BTW I do have an STM8 Discovery and ran all the demos. However I lost interest quickly when it became apparent there were few advantages over other 8 bit devices like PIC or AVR and many drawbacks. Cost, performance, features. So I'll leave that scientific curiosity up to you too.Quote from: dannyf on September 09, 2014, 03:33:52 pmI'm certainly not an expert in C like you claim to be. As far as asm it don't look like you've ever seen let alone worked with a line of code. When you accomplish anything even close to what I've done come back and we'll talk.Apparently you are an expert on hardware tools too. Any more info on this?Quote from: dannyf on August 13, 2014, 10:42:34 pmAny links or other details? No?Quote from: dannyf on September 09, 2014, 03:33:52 pmYes, I see you have just caught on to what is not only most common arm chip but really the best deal in that category too. But I requested a hex file not half baked C demos off the web. Anyway it's no longer needed. A hex (actually elf, even better) was provided by a generous offline contributor. It provided the missing link I needed to solve that mystery.Anyway I don't think you ever had the courtesy to post a working hex file. Maybe with all the GUI layers you don't know how. Like with the arduino gang. ATM there is little inclination for me to get sucked into that toolchain whirlpool you call a development environment.Quote from: dannyf on September 09, 2014, 03:33:52 pmWell it looks like I am possibly the first and only person to post a working version of ARM assembly blink program in this forum. OK, the program wasn't written by me but I got it working. Possibly westfw was able fix the include bugs and hasn't posted them yet. The latest version gets T32_OFFFSET_IMM something error with the basic CLI commands. It might be we are out of sync with command options again IDK. So attached is his previous asmh with a minor fix to suppress errors and working hex from his unmodified original source:

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 07:33:01 pm
content: QuoteQuoteWow!you redefine sha@#$. OK, you redefined "traiblazing", ;0It takes more than "audacity" to claim what you did.As to your being the "only" one. Have you thought about why you are the "only" one? Running down the autobahn butt-naked will make you the only one too but most people would understand why the "only" one there isn't so desirable.Do you?

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 07:35:04 pm
content: QuoteBingo!You hit it right on the head.As hardware costs continue to decline and software costs continue to rise, the trade-off continues to shift towards more stylized software.

author: paulie
author_rank: Frequent Contributor
timestamp: September 09, 2014, 07:44:55 pm
content: Quote from: dannyf on September 09, 2014, 07:33:01 pmI'm sure you can provide evidence to the contrary. SOMEBODY must have attached a functional set of ARM tools before. SOMEBODY must have provided a way for noobs to check them out without spending days or weeks or months. SOMEBODY must have posted a working binary assembled for ARM blinky before. No?Quote from: dannyf on September 09, 2014, 07:33:01 pmIt takes ARROGANCE!"I am great, yet I am humble."-Shark

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 09:31:00 pm
content: QuoteThat's good. That means humanity has honor, knows right from wrong, smart from not-so-smart.That means there is hope for all of humanity, minus the obvious one of course.

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 09:33:16 pm
content: Quotewhy?Just use the header files from CMSIS / libraries.

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2014, 10:21:42 pm
content: QuoteThey don't support assembler. (for two reasons. The first and most significant is that (in theory) while you could use the C preprocessor even when programming in asm, the CMSIS headers are full of constructs likeCode:#define CRC ((CRC_TypeDef *) CRC_BASE)which the assembler is not going to recognize after substitution (nor do I see a way to add additional CPP or asm macros to simplify it enough to make a difference)The second reason is that the preprocessor isn't included in the "reduced tool set" that we're trying to use (for better or worse.)Part of the reason for the experiment are the frequent complaints I see of the form "I hear that Atmel Studio for ARM, scatters 3GB+ of crap all over my disk." ("Yeah, TI's CCS does that too." "MPLABX isn't much better." etc.) So here we a "usable" toolset in less than 6MB, that goes exactly where you put it. That's 500x less space...Sure, I'd prefer "Borland C for ARM", but efforts in that direction (pcc ?) don't seem to be getting anywhere.Arguably, for minimum trouble you should spend the $100 to get something like Imagecraft's "Non commercial" ARM compiler/IDE. (~500MB) The real truth is that there isn't anyone doing this "for real" to whom $100 and a hour or two of download/install time is a real barrier. It *is* a sort of academic exercise...

author: dannyf
author_rank: Super Contributor
timestamp: September 09, 2014, 10:28:16 pm
content: QuoteUse the base address.Code:ldr R0, =RCC_BASE + RCC_AHBNER_OFFSET @load ahbner address into R0would work.You have to define RCC_AHBNER_OFFSET (which the header file specifies), obviously.

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2014, 11:35:06 pm
content: QuoteAssuming that it would get that far, this would expand toCode:ldr r0,=((((uint32_t)0x40000000)+0x20000)+0x1000)which generates errorsCode:foo1.S: Assembler messages:foo1.S:6: Error: missing ')'foo1.S:6: Error: missing ')'foo1.S:6: Error: missing ')'foo1.S:6: Error: garbage following instruction -- `ldr r0,=((((uint32_t)0x40000000)+0x20000)+0x1000)'You get similar errors for "=(((()0x40000000)+0x20000)+0x1000)"...But of course it doesn't get anywhere near that far, since the .h file also has plenty of "typedef" statements that the assembler doesn't understand at all either:Code:stm32f10x.h:1266: Error: bad instruction `typedef struct'stm32f10x.h:1267: Error: junk at end of line, first unrecognized character is `{'stm32f10x.h:1268: Error: bad instruction `__io uint32_t CR'stm32f10x.h:1269: Error: bad instruction `__io uint32_t CFR'stm32f10x.h:1270: Error: bad instruction `__io uint32_t SR'stm32f10x.h:1271: Error: junk at end of line, first unrecognized character is `}'If I understand things correctly, this is the format/methodology that CMSIS requests/requires of the include files.And the explicit casts on all constants are recommended/required by other standards, right? (MISRA?)So the CMSIS header files are pretty much defined to be an assembler-unfriendly format...I think the only architectures I've seen .f files set up to be used by both assembler and C is the Atmel AVR.(Microchip 8bit PIC has separate .h and .inc files, IIRC.)QuoteI did find some sites that have instructions for generating gnu assembler xxx_OFFSET macros from C structure definitions. (http://docs.blackfin.uclinux.org/doku.php?id=toolchain:gas:structs) Just create a special C file that references all the structure offsets that you're interested in, run it through the compiler till you get generated asm, process that with awk, and bob's your uncle. I think I prefer my technique (though the blackfin technique would have handled those structs containing arrays of other structs that mine didn't.)

author: paulie
author_rank: Frequent Contributor
timestamp: September 10, 2014, 08:27:07 am
content: My methodology involves pulling out datasheets and snipping register tables. Then, using macro/replace ability of my editor (emacs variant), convert entries to .equ or #define depending on language. Rarely do I bother with bit definitions. Those and other less common details may end up as immediates with comments or equ/define in the source file if used more than once or twice. Rarely do i bother to download the official include packages.This has worked out well in the 8 bit world. Lately not so much for ARM due to somewhat nasty docs. Most of my efforts are not that complex. Certainly not on a par with things like mw or ardupilot, but a few did make it to market. The "sometimes less is more" philosophy has served me well. I spend more time actually writing programs and less struggling with tools.

author: dannyf
author_rank: Super Contributor
timestamp: September 10, 2014, 10:59:51 am
content: QuoteYou are right.I ended up with the following arrangements:Code:@set gpio2ldr R0, =GPIOC_BASE@read gpioc base into r0ldr R1, [R0, #GPIO_ODR_OFF]@read gpioc odrldr R2, =GPIO_ODR_2@read odr2orrs R2, R2, R1@r1|r2->r2str R2, [R0, #GPIO_ODR_OFF]@send it back to odrGPIOC_BASE is separately defined as:Code:.equ PERIPH_BASE,0x40000000@peripheral's base address.equ APBPERIPH_BASE,PERIPH_BASE.equ AHBPERIPH_BASE,(PERIPH_BASE + 0x00020000).equ GPIOC_BASE,(AHB2PERIPH_BASE + 0x00000800)Retained the names from the .h file.QuoteThey compiled flawlessly for me:Code:#include <stm32f0xx.h>#include "stm32f0xx_rcc.h"#include "stm32f0xx_gpio.h".syntax unified@system defines@RCC offsets.equ PERIPH_BASE,0x40000000@peripheral's base address.equ APBPERIPH_BASE,PERIPH_BASE.equ AHBPERIPH_BASE,(PERIPH_BASE + 0x00020000).equ AHB2PERIPH_BASE,(PERIPH_BASE + 0x08000000).equ RCC_BASE,(AHBPERIPH_BASE + 0x00001000)@rcc's base address...Except that they do nothing yet, until I figure out how to use the defines.

author: paulie
author_rank: Frequent Contributor
timestamp: September 10, 2014, 07:31:28 pm
content: Quote from: dannyf on September 10, 2014, 10:59:51 amIf that's the case, why waste time on creating a half-functioning assembly code? Give people .axf and you are done.From where I sit, you haven't demonstrated the need, skills or resources to code in assembly

author: SirNick
author_rank: Frequent Contributor
timestamp: September 10, 2014, 09:52:51 pm
content: Kinda had that one coming.Just popping in to say, this is a neat exercise. Not practical, just entertaining and educational. Carry on.

author: paulie
author_rank: Frequent Contributor
timestamp: September 10, 2014, 10:29:59 pm
content: LOL I hope Danny gets it.Thanks. "Not practical, just entertaining and educational" was the plan from day one. Maybe people are beginning to get that now. I know I've come a long way last few days thanks to guys like westfw, nctnico, and, I hate to admit, Danny too (don't tell him I said that).

author: SirNick
author_rank: Frequent Contributor
timestamp: September 10, 2014, 11:21:28 pm
content: Your secret's safe with me.BTW... I, for one, do and did get it. I've often been surprised how strongly people oppose doing things the hard way (or whatever) at least once, to better understand how it works. You'd think, in groups of engineers and hobbyists, taking the scenic route wouldn't be in the least bit controversial. But often it is. *shrug* I have never understood that.

author: westfw
author_rank: Super Contributor
timestamp: September 10, 2014, 11:28:24 pm
content: Quotewhy? I mean, OF COURSE you can create your own .equivs for whatever constants you want, but that's tedious and error-prone compared to have an algorithmic translations of the .h file (which is what I've done to create the .asmh)I don't think we're specifically restricting ourselves to the "most primitive environment possible" (though it may feel that way.) We're trying to provide the best possible environment within a constraint of size/time. Adding a 60k (compressed) file of assembler-style definitions is within the constraint.QuoteI don't see how that's possible. You're not even defining the specific chip, which should bump you immediately into:Code:#if !defined (STM32F030) && !defined (STM32F031) && !defined (STM32F051) && !defined (STM32F072) && !defined (STM32F042)#error "Please select first the target STM32F0xx device used in your application (in stm32f0xx.h file)"#endif(Hmm. Are using using "arm-none-eabi-as" as the assembler? That doesn't invoke theC preprocessor, and includes a quirk of commenting such that lines beginning with # are essentially ignored, so #include doesn't actually include anything... To "assemble" a file that uses C macros, you usually use the xxx-gcc command (the gcc .exe being essentially a front end that invokes xxx-cpp, cc1, xxx-as, and xxx-ld and perhaps others depending on command line switches and file extensions.)

author: dannyf
author_rank: Super Contributor
timestamp: September 11, 2014, 12:30:32 am
content: We followed a different process. I followed a typical C project process to the end. Then delete main.c, and instead include main.S.I will also choose CMSIS as part of the set-up.I eventually wrote a small piece of code (h2inc) that generated stm32f0xx.inc from stm32f0xx.h to retain the base addresses. That header file is then included in the main.S to provide base addresses for the code.Using CMSIS has the advantage of having access to SystemInit() and SystemCoreClockUpdate(), as having your stack / heap set up by the start-up file automatically.My code looks like this:Code:.include "stm32f0xx.inc".syntax unified.thumb@system defines@RCC offsets.equ RCC_AHBENR_OFF,0x14@ahbner offset@gpio offsets.equ GPIO_MODER_OFF,0x00@gpio moder offset.equ GPIO_OTYPER_OFF,0x04@output type.equ GPIO_ODR_OFF,0x14@output data register.equ GPIO_BSRR_OFF,0x18@output bit set / reset register.equ GPIO_BRR_OFF,0x28@output bit reset register@global defines.equ LED_PORT,GPIOC_BASE@led on gpioc.equ LED_A,(1<<1)@led anode on pin1.equ LED_C,(1<<2)@led cathode on pin2@global variables.global main@so it gets called from CMSIS.type main, %function@.text@declare it in the code sectionmain:@user main starts hereinit:@initialize the chip@enable clock to gpiocldr R0, =RCC_BASE@read rcc base address into r0ldr R1, [R0, #RCC_AHBENR_OFF]@read ahbner register into R1ldr R2, =RCC_AHBENR_GPIOCENorrs R2, R2, R1@set GPIOCEN bit, R2 | R1 -> R2str R2, [R0, #RCC_AHBENR_OFF]@update ahbner registerThe bulk of the code compiled is actually in the .inc file - almost 400k and 5000+ lines - many of it is actually masked off.Unfortunately, there is no way to calculate the offsets so you have to manually set them up.

author: westfw
author_rank: Super Contributor
timestamp: September 11, 2014, 02:44:04 am
content: So are we now at "why use a .asmh file generated from ST .h files using your procedure when you could have used a .inc file generated from ST .h files using MY procedure"? I'll accept that as a "victory." The resulting files seem be be about the same size, and everything (also about the same size as st's original .h files. I wish they didn't spend so much time/space defining PERIPHNAME_REGNAME_0 (through PERIPHNAME_REGNAME_31) and similar for each bit of every register where the bits don't have a particularly nameable function...

author: paulie
author_rank: Frequent Contributor
timestamp: September 11, 2014, 03:22:21 am
content: It would be interesting to see if using a file generated for the device in this thread actually compiles unlike the asmh files which do not.ps. And if the program using it actually runs.

author: westfw
author_rank: Super Contributor
timestamp: September 11, 2014, 04:47:52 am
content: I should start including by example program in with the .asmh file. I did mention that the _O symbols were replaced...It turns out that error messages likeCode:blink.S:61: Error: cannot represent T32_OFFSET_IMM relocation in this object file formatis "I am a lousy assembler"-speak for "the symbolic name you used in this instruction is undefined." (actually, it seems to have automatically made it "external", and then discovered that the linker doesn't support the required sort of math on the value. Or something like that.)Here's the most recent .asmh file. Now includes NVIC and SysTick peripherals (from ST's core_cm3.h), and deleted some of the pointless bit value definitions.

author: paulie
author_rank: Frequent Contributor
timestamp: September 11, 2014, 06:54:03 am
content: It compiles OK but unfortunately don't blink. I haven't deciphered your code yet. Did you change the bit or something? On same hardware the original one blinks when used with the older asmh that I hacked.

author: westfw
author_rank: Super Contributor
timestamp: September 11, 2014, 07:46:24 am
content: I didn't think I had changed anything. :-(My board is supposed to arrive tomorrow. What did you say you were using for upload? (JTAG, Serial, USB?)Hmm. It looks like when I added the offsets to the .asmh file, I forgot that my older version had created absolute values for some things with the same name. So the code currently hasCode:ldr r0, =RCC_APB2ENRand that (now) needs to beCode:ldr r0, =RCC_BASE+RCC_APB2ENRI see a disadvantage to having dropped the _O syntax for offsets :-((although the peripheral register names are now ALL offsets, and always need to add some _BASE value via indexing or addition.)

author: paulie
author_rank: Frequent Contributor
timestamp: September 11, 2014, 08:33:37 am
content: Just like the version of yours that works it was assembled with first page utilities and downloaded using that ST serial flash program attached there. I peeked and see the bit has not changed so maybe something to do with the new include file. I really can't make heads or tails of actual addresses anymore what with all the offsets, bases, shifts etc.. Same tools as with my own super simple LED program from last week with just plain ol' hex numbers. No includes or even defines. Maybe a comment or two if you're lucky.I'm sure things will move quickly when your board shows up. No hardware is a huge handicap IMO.

author: westfw
author_rank: Super Contributor
timestamp: September 12, 2014, 11:07:01 pm
content: Spreadsheet of board/chip pinout, for the $7 board variants we've been talking about:https://docs.google.com/spreadsheet/ccc?key=0AqdMB5dovDUZdGR6cVprUnkwTV9CMUNybV9VMjF5a0E&usp=sharing(No hardware yet :-( )

author: paulie
author_rank: Frequent Contributor
timestamp: September 13, 2014, 12:49:03 pm
content: Somebody offline requested more wiring information so I've added a photo of the bottom of the board in the second post. Also one showing a run/boot switch and reset button. Something like this is essential if you are interested in testing or modifying the simple LEDA9 program that I attached there last week or the hacked version of westfw files from a couple pages back.Speaking of which, westfw, did your board come in? Everything working as expected? If so maybe put up a known good include/blinky pair for those who might be interested in more serious asm development than my crude demo.

author: neslekkim
author_rank: Super Contributor
timestamp: September 13, 2014, 06:10:46 pm
content: Quote from: westfw on September 12, 2014, 11:07:01 pmis pin 47-48 marked wrong on the board?

author: paulie
author_rank: Frequent Contributor
timestamp: September 13, 2014, 08:55:10 pm
content: Yes, good call. That certainly looks like a typo because, glancing at my breakout board, pin 47 must be ground not 3v or there would have been sparks on the dozens built so far. I'm sure westfw will be along to fix that. I'm also hoping what may be bugs in the latest blinky or include file can be updated. That would be very useful for anybody venturing beyond my dumb demo.ps. Pin 48 with VCC looks correct. On my breakout board GND pins are on the outside and VCC pins on the inside which makes it very easy to build and check. The power pins are shorted inside the chip so double checking with a meter will show instantly if theres a miswire. Interestingly even though bypass caps seem to be optional these duplicate pins must all be wired together or the chip don't work.

author: westfw
author_rank: Super Contributor
timestamp: September 13, 2014, 09:39:09 pm
content: QuoteThe "board" pin numbers do not match up with the chip pin numbers, and are just arbitrary. Probably not "right", because I'm not aware of a standard for quad in-line "packages." (that's one reason I added the annotated photo.)I see I have two "28" and no "29"; oops.Is there a schematic or more detailed description of the board-level circuit somewhere? Most of it is self-explanatory, but paulie said "boot1 and boot0 markings are swapped on many of them", for example...PS: My board that was supposed to arrive on thursday actually arrive today (Sat); I have fixed the stm32flash utility from google code to compile on my Mac (have I mentioned that so far I've been using a Mac for all of this?), so I'll soon see if it works...

author: westfw
author_rank: Super Contributor
timestamp: September 14, 2014, 11:32:59 am
content: QuoteI'm not having too much luck...The bootloader should ALWAYS run when boot01 is 1/0, and it should run forever waiting for the proper serial comm, right? My mac doesn't seem to be talking to the board at all, either via the stm32flash utility I found, or through a serial terminal emulator :-( My PC seems to be able to talk to the board via the ST flash load demo "sometimes", and perhaps "most of the time" via putty. (note: same serial HW on both PC and Mac, and it seems to work fine in loopback or talking to another serial adapter.) Sigh.

author: neslekkim
author_rank: Super Contributor
timestamp: September 14, 2014, 12:34:29 pm
content: Quote from: westfw on September 13, 2014, 09:39:09 pmThe reason I asked, is that the board number in the spreadsheet, and the picture below, differs, on the picture it clearly states GND, and the spreadsheet says 3v3, so I wondered if the board are wrong, or the spreadsheet (there are known to be some boards comming from china that have errors.. )

author: paulie
author_rank: Frequent Contributor
timestamp: September 14, 2014, 01:10:57 pm
content: Quote from: westfw on September 14, 2014, 11:32:59 amRight. As of yesterday I've built nearly 100 of the DIY boards for myself and friends and although there's only one Ebay blue board in my collection I've poked at half dozen others. No flakyness so far. These things either worked or they didn't. When they didn't it always turned out to be something wrong with my wiring or procedures.The only intermittent boot failures were long time ago with PIC and AVR and traced to bogus USB/serial. There are "issues" regarding hardware and drivers. I'm quite an expert on those (among other things. LOL) so suggest putting up a photo of yours, either from the original ad or snap one. Where did it come from? The $1 Ebay dealies with DTR are very reliable.ps. All PC for me, Win and Linux but no Mac.

author: paulie
author_rank: Frequent Contributor
timestamp: September 14, 2014, 03:02:18 pm
content: Somebody else on this end just had some problems so here's a couple more hints. As mentioned in the first post you MUST reset the chip before each download and make sure the "run user" box is checked. Some hints on the ST flash demo: set timeout for 1s. If it's not recognized by then somethings wrong. Also use 256kbaud which for some reason is more than 3x faster than 115k (6s vs 20s).

author: westfw
author_rank: Super Contributor
timestamp: September 14, 2014, 10:17:23 pm
content: QuoteBingo! Things work much better using my trusty FTDI cable. I was trying to use on of those CA-42 phone cables (with a (probably counterfeit) Prolific chip) that were the state-of-the-art cheap usb-serial solution a couple of years ago. I suspect that the chip/driver combination doesn't like the somewhat unusual 8bits plus Even parity configuration.Update: Woo hoo! I have blinking!(huh. One tends to look down on those arduino female connectors where everyone just plugs in wires and components. But it's a PITA to stick female connectors on the end of LEDs (for example) so that they're easy to attach to these boards with male pins...)

author: westfw
author_rank: Super Contributor
timestamp: September 15, 2014, 05:43:49 am
content: Code:08000036 <delay>:8000036: 3901 subs r1, #18000038: f47f affd bne.w 8000036 <delay>800003c: f7ff bff5 b.w 800002a <loop>I can't figure out why it's generating "long" branches. My Keil assembler example puts each of those branches into a single 16bit instruction. I can't find any relevant switches, directives, or instruction variants that look like they'd change the behavior :-(

author: Kjelt
author_rank: Super Contributor
timestamp: September 15, 2014, 08:14:23 am
content: Quote from: westfw on September 15, 2014, 05:43:49 amDid you set the target device correctly?

author: westfw
author_rank: Super Contributor
timestamp: September 15, 2014, 09:08:46 am
content: I have -mcpu=cortex-m3; shouldn't that be enough?

author: dannyf
author_rank: Super Contributor
timestamp: September 15, 2014, 09:50:07 am
content: QuoteTwo weeks later, one of two "experienced programmers" eventually succeeded in blinking an led. The other one is still trying.Phew!Talk about steep learning curves,

author: mrflibble
author_rank: Super Contributor
timestamp: September 15, 2014, 10:38:39 am
content: Quote from: dannyf on September 15, 2014, 09:50:07 amWell, since the stated mission objective basicallyisthe learning curve I'd say mission accomplished. The learning curve has been measured succesfully!Not entirely sure about that "one minute" part though. At least it isn't "one man" anymore, thanks to westfw joining the fray. The "one dollar" probably still holds, not counting time obviously.And as added benefit, it results in a confirmation of my personal bias. That being:"asm only on ARM? Nope not worth the hassle".Another thing that came out of it IMO, is that even to get a meaningful asm only development environment, you cannot escape using other tools to get there. That being you have to parse C include files to get useable asm defines and such. And you can do the parsing either by generating some C files, compile it, and process the output. Or do some perl/python/sed/awk/whatever scripting to get the job done. Not that I personally have any problem with having to parse C stuff in order to get to the asm only step, but it does take away the "purist asm" award.Anyways, it will be interesting to see what the minimalist setup binary size is compared to the C equivalent.And after that it will be interesting to see what the development time is for a moderate size application compared to C. Because spending a lot of time ONCE to get a known to work setup with really small binary size, I totally dig that. You spend your time once, and then you reuse your awesomely small setup in all your following projects. It's the time spent on the average application after that which is the thing...Or maybe make an optimized minimal setup, and then you hand off control to the rest of the app written in C.Anyways, keep it up! It makes for interesting reading.

author: Kjelt
author_rank: Super Contributor
timestamp: September 15, 2014, 11:00:40 am
content: Quote from: westfw on September 15, 2014, 09:08:46 amyeah should be enough I thought you might have selected generic ARM.

author: westfw
author_rank: Super Contributor
timestamp: September 15, 2014, 02:36:28 pm
content: To be fair, most of the two weeks in my case was spent waiting for HW to arrive.I could've gone to radioshack and picked up an arduino and spent the time (more than one minute) it takes to download the Arduino SW. Or for that matter, it would have been a very slow internet connection not to have been able to download "more than just the assembler" in the time I spent soldering (even though I got a pre-assembled board, and only soldered up several adapter cables. (one of which didn't work.))

author: paulie
author_rank: Frequent Contributor
timestamp: September 15, 2014, 03:07:45 pm
content: Quote from: westfw on September 15, 2014, 05:43:49 amAdding ".n" pseudo-op will force short addressing as shown in the first two examples below.Also note that, as mentioned early in this thread, using "=cortex-m3" CL option does not result in the same binary as ".thumb" directive. I discovered this right after you introduced me to the latter. Various combinations of CL options and source directives can produce quite varied output. Functionally similar but... Compare binary generated for NOP and address length of branch.Code:arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.swith:.thumb.syntax unifiednopstart:b.n startbegat:08000000 <start-0x2>:8000000:bf00nop08000002 <start>:8000002:e7feb.n8000002 <start>Code:arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.swith:.thumb.syntax unifiednopstart:b startbegat:08000000 <start-0x2>:8000000:bf00nop08000002 <start>:8000002:f7ff bffeb.w8000002 <start>Code:arm-none-eabi-as -o t.o t.swith:.thumb.syntax unifiednopstart:b startbegat:08000000 <start-0x2>:8000000:46c0nop; (mov r8, r8)08000002 <start>:8000002:f7ff bffeb.w8000002 <start>Code:arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.swith:.thumb.syntax unifiednopstart:b .begat:08000000 <start-0x2>:8000000:bf00nop08000002 <start>:8000002:e7feb.n8000002 <start>Code:arm-none-eabi-as -o t.o t.swith:.thumb.syntax unifiednopstart:b .begat:08000000 <start-0x2>:8000000:46c0nop; (mov r8, r8)08000002 <start>:8000002:e7feb.n8000002 <start>One (one with open mind anyway) can learn a lot from little experiments like this. Another thing I can't understand, or forgive in this case, is the objdump LST output being incompatible with the assembler. For example our beloved ';' comment characters which are sprinkled throughout. Kinda like the ST bootloader failing to restore reset defaults before running user.Software engineers, can't live with 'em, can't shoot 'em. Well you could but then what would internet hotshots argue about?

author: westfw
author_rank: Super Contributor
timestamp: September 16, 2014, 01:02:35 am
content: Initializing the clock for 72MHz, controlled by the external crystal:Code:/** Initialize the clock to our max speed (72MHz), assuming an external 8MHz crystal.* This also involves configuring the flash for wait states, and dividing the APB1* (low speed peripheral bus) clock.*/ClockInit:/** Set the flash for 2 wait states - the max needed at 72MHz.* (do this FIRST!)*/ldr r0, =FLASH_R_BASE/* Flash control register */ldr r1, [r0, #FLASH_ACR]orr r1, #FLASH_ACR_LATENCY_2/* Set for two wait states */str r1, [r0, #FLASH_ACR]/** Enable the oscillator for the external crystal, and wait* for it to finish starting up.*/ldr r0, =RCC_BASE/* Clock control registers*/ldr r1, [r0, #RCC_CR]/* get control reg contents */orr r1, #RCC_CR_HSEON/* Turn on crystal oscillator */str r1, [r0, #RCC_CR]clklp:ldr r1, [r0, #RCC_CR]tst r1, #RCC_CR_HSERDY/* wait for clock ready */beq.n clklp/** Configure and enable the PLL,then start it and wait for lock.*/ldr r1, [r0, #RCC_CFGR]/* Get clock config register */orr r1, #RCC_CFGR_PLLMULL9 + RCC_CFGR_PLLSRC_HSE /* Multiply osc by 9 */orr r1, #RCC_CFGR_PPRE1_DIV2/* But make sure APB1 is < 36MHz */str r1, [r0, #RCC_CFGR]ldr r1, [r0, #RCC_CR]/* get control reg contents */orr r1, #RCC_CR_PLLON/* Turn on PLL */str r1, [r0, #RCC_CR]/* store */plllp:ldr r1, [r0, #RCC_CR]tst r1, #RCC_CR_PLLRDY/* wait for clock ready */beq.n plllp/** Select the PLL output as our system clock*/ldr r1, [r0, #RCC_CFGR]orr r1, #RCC_CFGR_SW_PLL/* Select PLL */str r1, [r0, #RCC_CFGR]bx lr /* Return */What a pain in the neck - a perfect example of the sort of low-level grunt-work on uninteresting peripherals that an embedded programmer would rather not waste time figuring out. (The standard peripheral library code that does this looks like it would expand to "really big." It's got abstractions piled on top of abstractions, properly sets/clears the state of nearly every bit (even if you "know" the startup state) (and pretty much one bit/field at a time.))(I keep or-ing bits into my registers, and forgetting to store them back to the peripheral. HLL habits.)(Is it working? I dunno. It blinks faster than it used to. It doesn't look 9x faster, though. I'm not sure how those wait states end up affecting the timing of the simple blink loop. Next step; SysTick.)

author: westfw
author_rank: Super Contributor
timestamp: September 16, 2014, 01:43:51 am
content: observation: The .asmh isn't as much use as it might be, because most of the C examples use the peripheral library calls instead of the stm32f10x.h level structures and register values. So you can't simply translate most of the existing C examples into asm; you have to either dig through the peripheral library source, or go all the way back to the datasheet.Got out the scope, increased the frequency, and did some measuring. With the clock configuration code in, the pin is only toggling at about 4x the rate with the internal 8MHz clock...

author: paulie
author_rank: Frequent Contributor
timestamp: September 16, 2014, 10:39:08 am
content: Your program compiled and ran just as expected on my blue board. At least once the LED was moved to the right pin. That new MYBIT did throw me for a loop (haha... you got me!). Commenting the 2 calls also caused it to run slower pretty much the same as you described. I tried to make it compatible with the hardware on page one by changing MYBIT to 9 and CRL to CRH but no go. Looks like I'll have to do a little disassembly to see what I missed.I gotta say that code is just about the best tutorial on ARM assembly published on the net so far. I would love to put that up at the beginning of the thread to help the unwashed masses. First I need to get that bit moved and it would be nice to figure out why the clock is not running exactly as expected. In any case thanks for that and hopefully you won't give up.I wish my UART experiments were going as well. Looks like divisor issues. I was hoping to avoid it but maybe it will be necessary to get involved with that clock stuff after all.

author: dannyf
author_rank: Super Contributor
timestamp: September 16, 2014, 11:00:15 am
content: QuoteFollow the datasheet; If that's too difficult, follow the library; If that is even too difficult, follow the SetSysClock() in the system_xxx.c -> that's the closest example.QuoteWith your demonstrated skills and experience, it is probably unjustified to call people that way. Be humble.QuoteProbably more than that.Quotemost of them rely on the base address and register struct established in stm32f10x.h. The register values are generally replaced by enums in the peripheral library and the bit values are generally not used.

author: westfw
author_rank: Super Contributor
timestamp: September 16, 2014, 05:46:00 pm
content: QuoteOh, my code does something. What I mean is that I am having trouble figuring out how fast my delay loop should run if I increase the clock rate from 32 Mhz to 72Mhz, when that also means adding two wait-states to the flash controller, AND the "prefetch buffer" is turned on, AND I have the ARM pipeline to contend with as well. (technically, you're not supposed to run 32MHz, 0-wait states. But that did seem to work. Unlike 72MHz @ 0 WS, which I also ended up trying accidentally.) So I don't know for sure whether the processor is actually running at 72MHz and is slowed down by WS and code structure, or whether I have some mistake that is causing it to run a a different clock rate than I expect. (Different PLL multipliers are just changes of a constant, and I'm definitely multiplying by SOMETHING, so it's difficult to imagine what would cause a different clock rate than expected...I should probably import the max-rate pin toggle code from that other thread and do some real measurements...QuoteOh, I am. More or less. The library code is "deep." Pretty much for every assembly language statement I have in my clock init function, the library function (setSysClockTo72()) has one or more function calls, frequently with parameters that don't match exactly with the stm32f10x.h symbols. I hope a lot of that gets inlined and optimized away because things are constants. (Could you post disassembled setSysClockTo72() code, since you have a C/plib environment handy?) They also explicitly set a lot of bits/fields to the default poweron values, while my code is assuming that it's starting with poweron values. (it looks like the plib would allow you do do things like:Code:setSysClockTo72(); // run fast.toggletest();setSysClockToHSE(); // basic crystal ratetoggletest();setSysClockTo48(); // intermediate speedtoggletest();I have to say that what the peripheral library documentation may lack in clarity, it makes up for with excellent cross-reference links to the actual source code. Browsing through the library with a CHM browser is ... pretty nice.

author: dannyf
author_rank: Super Contributor
timestamp: September 16, 2014, 07:10:48 pm
content: If I were you, I would increase the speed to 24Mhz, WS0. Measure the blinking frequency; and then 24Mhz, WS1, measure the blinking frequency again. I can tell from my own experience, flash ws has a bigger impact on the execution speed.If you look at the SystemInit() or the library, you will see lots of looping around for the oscillators / PLL to be ready. That's one area where a mistake could have been made.You can check if you look at the RCC registers, particularly the pre/after multipliers to be sure that you are running at 72Mhz.SetSystenClock() is in the system_xxxx.c file.

author: dannyf
author_rank: Super Contributor
timestamp: September 16, 2014, 07:12:10 pm
content: QuoteThe use of doxygen helps. But more important than that is the availability of "go to definition" of your IDE. It is a life saver.

author: westfw
author_rank: Super Contributor
timestamp: September 16, 2014, 08:41:51 pm
content: QuoteIn this case, I'm particularly appreciating having that function available OUTSIDE any IDE. (That probably means having a separate html (.chm ?) file for each C source module. which tweaks my frugality sense. But it's still nice...)

author: westfw
author_rank: Super Contributor
timestamp: September 17, 2014, 09:55:43 am
content: Here's the timing table. I shortened the loop toCode:loop:ldr r1, [r0, #GPIO_ODR] /* read DATA reg */eor r1, r2/* complement bit */str r1, [r0, #GPIO_ODR] /* write */b.n loop(NOT the shortest possible loop, BTW.) And I implemented some symbolic indirection to make it easier to change the values (code attached.) The no-wait-state code looks like it's taking about 9 clocks for the 4-instruction loop, which is not as good as I thought it would be (although I wouldn't find 6 surprising - 1 extra for the 32bit instruction and one extra for the branch.) Maybe I've left something out?Impressive Overclocking success!Code:------------(MHz)--------PLLMULT F(cpu) F(0WS) F(1WS) F(2WS)- 8 0.444 0.400 0.3643 24 1.330 1.200 1.0914 32 1.7795 40 2.225* 1.8186 48 2.669*7 56 3.115*8 64 fail 3.200* 2.919 72 3.600* 3.2710 80** 4.000*11 88** 4.400*12 96** 4.800*13 104** 5.200* 4.7314 112** 5.600*15 120** 6.000*16 128** 6.400* 5.8* exceeds documented memory speed** exceeds documented cpu max freqUpdate: using a sequence of stores, I can get "about" 2MHz pin toggle running at 8MHz/0WS, or 18MHz at 72MHz/2WS (that's still slower than I expected (~2cycles per store), but the flash prefetch unit seems to be helping. The 72MHz version is running 9x the 8MHz version, despite increasing the waitstates to be "legal."):Code:ldr r1, [r0, #GPIO_ODR] /* read DATA reg */eor r1, r2, #(1<<mybit)loop:str r1, [r0, #GPIO_ODR] /* 1 write */str r2, [r0, #GPIO_ODR] /* write */str r1, [r0, #GPIO_ODR] /* 2 write */str r2, [r0, #GPIO_ODR] /* write */str r1, [r0, #GPIO_ODR] /* 3 write */str r2, [r0, #GPIO_ODR] /* write */

author: paulie
author_rank: Frequent Contributor
timestamp: September 17, 2014, 01:00:13 pm
content: Good news that the expected 9x is now demonstrated. I've verified the scope timing on this end too. There are too many differences from the previous version for me to easily follow so I wonder if you can explain what changed. Did you alter the clk/pll code or was it due to the new fast loop? What actually caused the 4x speedup to become 9x?

author: paulie
author_rank: Frequent Contributor
timestamp: September 17, 2014, 02:27:01 pm
content: Quote from: dannyf on September 15, 2014, 09:50:07 amAll I can suggest Danny is don't give up. More than a few rank beginners managed to get the LED demo posted on first page couple weeks back working and it only took them a minute or two so there is hope. I posted not only source but binary ready to flash in case it's tools that are causing you trouble.BTW did I forget to mention that the entire development set is attached not just linked so should be quite easy to manage.

author: westfw
author_rank: Super Contributor
timestamp: September 18, 2014, 03:10:10 am
content: QuoteThe big change was these additions at the top to options:Code:.equ DODELAY, 0/* if 0, just toggle at max loop speed. *//* if 1, blink at human-like speeds */.equ WAITSTATES, FLASH_ACR_LATENCY_1.equ PLLMULT, RCC_CFGR_PLLMULL9@.equ PLLMULT, 0/* If 0, don't use the PLL *//* Note that xxx PLLMULL2 is 0, so this structure *//* doesn't support x2 clock configurations */then the ClockInit code uses the new symbols (PLLMULT, WAITSTATES) instead of the symbols direct from the .asmh files.And there is some conditional assembly to leave out the PLL code if the multiplier is zero, and leave out the delay loop when DODELAY is 0.

author: westfw
author_rank: Super Contributor
timestamp: September 18, 2014, 03:29:29 am
content: Oh yeah:QuoteThe actual speedup going from 8MHz 0WS code to 72MHz 2WS code is 3.3/.444, or about 7x...

author: miguelvp
author_rank: Super Contributor
timestamp: September 18, 2014, 06:30:06 am
content: PSoC version, although I payed too much for the board (breakable schmartboard that I still have the other half).So $3 for the board, $1 for the chip and after I put it together I did the blinky in less than 1 minute without counting wiring it up to my pioneer.Programming was as simple as getting the blink demo, changing the led pin and that's it.The code it generatedCode:#include <device.h>int main(){/* Start the Clock and PWM components. Clock can be started automaticallyafter reset by enabling “Start on Reset” in the Clocks tab ofBlinking LED.cydwr. We are doing this manually for instructive purpose. */Clock_Start();PWM_Start();for(;;){}}Schematic:Board:Operating voltage 1.8V to 5.5V unregulated (using internal regulator, therefore the bypass caps). You can short VDDD and VCCD if you supply a regulated (1.8 ±5%)V without the need of the bypass caps).Edit: but if you use the bypass caps, you get the regulated output out off VCCD as shown in the image is pretty close to 1.8 and well within the operating parameters.To program it, I'm using my Pioneer dev kit ($25) with a modified KitProg that allows me to program external chips instead of the one within the Pioneer.Edit: plus this has programmable Analog and Digital logic.

author: westfw
author_rank: Super Contributor
timestamp: September 18, 2014, 07:06:33 am
content: Code:/* [PSOC Blink main loop] */for(;;){}Um. I see no blinking. Is it setting up the PWM with a 50% duty cycle and human-scale period?How big is the binary? For PSoC, you have to include the bits that define the hardware in your executable, don't you? It's not something you can program on the chip separately and have all of the (rather limited) code space left for software?

author: miguelvp
author_rank: Super Contributor
timestamp: September 18, 2014, 07:31:57 am
content: The purpose of the OP is One Dollar One Minute ARM DevelopmentSure I can forsake the PWM but that might take me a couple of weeks to program instead of under one minuteNah, takes less than a minute as well:Code:#include <project.h>int main(){/* Place your initialization/startup code here (e.g. MyInst_Start()) *//* CyGlobalIntEnable; */ /* Uncomment this line to enable global interrupts. */for(;;){/* Place your application code here. */Pin_Blue_Write(~Pin_Blue_Read());CyDelay(500);}}As for resources, yeah it does uses 1K of flash but that's not the thread subject.Steps to do this where:Create New ProjectEmpty PSoC4 templateAdd digital output pin and name it Pin_BlueSelect GPIO p0Add two lines of code in the for loopCompile and program.

author: miguelvp
author_rank: Super Contributor
timestamp: September 18, 2014, 08:29:28 am
content: BTW I can do my own component with my own support code (even in assembly if so inclined) instead of using the very accommodating built in modules.Also I can define my own Schematic/Verilog to use the Digital/Analog hardware abstraction on top of the support software.Oh, and you can just write to the address 0x40040000u and set or clear the bit for the port you want (in my case bit 3) for P0.

author: westfw
author_rank: Super Contributor
timestamp: September 18, 2014, 09:40:44 am
content: Thanks for the update. The original "one minute" referred to tool download/install time, not "time to write your first program." (obviously, the painful asm programs are getting written rather slowly.) As a 365+MB download, I don't think PSoC designer meets that specification. In fact, the download manager they want you to install first is already bigger than the complete toolset we're using here...I guess PSoC tools have more than the usual lock-in, since you need it to configure the hardware blocks as well compile the C code. I guess that in theory you can create the hardware configuration with the Cypress tools, and import them into some other compiler?

author: paulie
author_rank: Frequent Contributor
timestamp: September 18, 2014, 11:49:29 am
content: Quote from: miguelvp on September 18, 2014, 08:29:28 amI'd be impressed if you actually managed that. Even if we did relax the download requirement. Assembly blinky for Cypress chip that can be demonstrated in less than a minute? Quite a challenge.I ordered one of the $4 boards and a few $1 (soon to be $3) chips but even with help from The Creator I doubt this will ever be as easy as the GNU procedure published here. I'm not sure a couple op amps are worth the extra expense and development complexity. But like I said, it would be very impressive if you managed to strip down the tools to the point a noob can get going in anything close a short time frame.

author: miguelvp
author_rank: Super Contributor
timestamp: September 18, 2014, 02:38:46 pm
content: How about 32MB? and 3rd party support (at least uVision) plus lattice and xilinx toolchain for the fpga part of things I believe but I haven't read the full paper. (you need to be registered to download it)http://www.cypress.com/?rID=38050As for building your own component they have some tutorials somewhere and they are simple to make with their toolchain.Edit:the lattice and xilinx support is to program the chip as well.After all is just another Cortex M0 chip (M3 for the PSoC 5LP)

author: dannyf
author_rank: Super Contributor
timestamp: September 18, 2014, 03:42:22 pm
content: QuoteFrom a library perspective, it is non-existent - RTE doesn't currently cover those chips and unlikely ever. Cypress doesn't provide a library to cover those chips either.You have to read the datasheet and two trms to get it going.

author: miguelvp
author_rank: Super Contributor
timestamp: September 18, 2014, 04:55:06 pm
content: Or maybe it's simpler than that:QuoteEdit:BTW the default file location will be here (part of the 32MB download):C:\Program Files (x86)\Cypress\Programmer\3rd_Party_Configuration_Files\CY8C42xx\Prog_AlgorithmAnd the template project here:C:\Program Files (x86)\Cypress\Programmer\3rd_Party_Configuration_Files\CY8C42xx\Template_ProjectThese are the devices included in the 3rd party configuration folder, the Documentation has the same 3rd party pdf you can download individually in that programmer link earlier on.

author: paulie
author_rank: Frequent Contributor
timestamp: September 18, 2014, 08:05:31 pm
content: I might suggest a challenge that is more about being able to simply create a program and flash it than trying to make asm look like C. Recall the program on page one here has no includes or even equates yet does compile and flash the LED.Anyway I just pulled out my recently arrived 049-4xxx board and couple chips to take the new improved PSOC out for a spin. It's been a few years since my disappointing attempt with the $50 "hockey puck" programmer and $8 chips so the hope was things have improved. $4 is better than $50 and $1 ($3+ by month end) better than $8 but still some disappointments:NO BOOTLOADER. This is a huge drawback IMO. Serial upload is what made STM32 chips so cheap and easy. "Free" as dannyf calls it. I'm guessing you have to blow another $30-$50 for Pioneer or Miniprog3. Not great at 10x the cost of STM. You can probably buy a few STM ICE setups for that too.I find out now the chip on the 049-42xx card is not one of the $1 (soon to be $3) dealies. In fact it's very hard to determine just what chip is actually on there. Lots of mentions for their USB/serial device but not for the target in ads and docs. They seem to have actually erased the numbers off the top. WTF. It took a while but finally figured it out. Not too hard to locate the menu entry in Creator but far from minimum having to depend on that and generally annoying.To download Creator you must register with their exclusive club which involves providing email and personal info. I do not need spam to double like last time so back on the "museum of interesting chips" shelf for now.If there's anyway around these issues it might be somewhat more attractive and competitive with other options in the ARM world. However because of flashing hardware difficulties don't look like it's possible for guys like me who just want to poke a stick at new chips without spending more than couple bucks. You know, like we can with 8051, AVR, STM etc..

author: SirNick
author_rank: Frequent Contributor
timestamp: September 18, 2014, 08:54:12 pm
content: The ROM bootloader is pretty cool. NXP has that, too. I'm building a practical device - slash dev board right now with eight LPC812s, and one master LPC4078 on it. I can take them all directly out of the tube and solder onto the board, upload the 4078 code via the serial interface that I needed anyway, and have it flash the 812s via its dedicated link to each of them. Makes future firmware updates pretty easy too. The 4078 will always have the latest image for the 812s, and can itself be loaded via IAP or, if totally bricked, from the UART again. Only time I ever really need JTAG is for debugging.

author: miguelvp
author_rank: Super Contributor
timestamp: September 18, 2014, 09:41:19 pm
content: Quote from: paulie on September 18, 2014, 08:05:31 pmThe 049-41xx and 049-42xx both have bootloaders, they are programmed using the USB-Serial that only can be done in a presence of a bootloader. If you succeed in programming it without including the bootloader then it's pretty much bricked and you'll need a Pioneer or Miniprog to unbrick it and load a bootloader on it.Quote from: paulie on September 18, 2014, 08:05:31 pmIt's exactly the same chip, the PSoC 4 on the protoboard and the pioneer is the same CY8C4245AXI-483 of course you have the datasheets, schematics and BOMs available to double check but it's better to assume things. Also it's an angle thing but it's not erased but very faint on the protoboard.Quote from: paulie on September 18, 2014, 08:05:31 pmThat sounds just silly in many ways, I haven't receive a single spam from cypressQuote from: paulie on September 18, 2014, 08:05:31 pmNah, just stick with what you have thenBTW I did download Keil V 4.74 and was going to set it up as in that paper, but the cypress chips were already installed.Edit: link of Cypress supported ARM deviceshttp://www.keil.com/dd/chips/cypress/arm.htmOh and Creator can export full projects to Eclipse, uVision and IAR Embedded Workbench for ARM. But I think you are better off by leaving it in your "museum of interesting chips" shelf forever. Obviously is not for you.Edit: Also need to add that the programmer that allows the 3rd party toolchains if you don't download the "download manager" it still have a direct link to get the 42MB installation file, so it's not required.And lastly (well for now) C666 has mentioned many times that Cypress will price match even at low quantities with competitor chips, so even when they go up to $2.50 you might be able to get a better deal with some back and forth from their sales dept, but I have no experience with that so it's just word of mouth.

author: SirNick
author_rank: Frequent Contributor
timestamp: September 19, 2014, 12:16:17 am
content: 32MB? That's for the IDE? Pretty good actually. IAR EW noticed I had 2GB free on my laptop's SSD and decided to take it all. There was a white-knuckle countdown as I waited to see which would get to 100% first: The installation progress bar, or the disk utilization bargraph.

author: miguelvp
author_rank: Super Contributor
timestamp: September 19, 2014, 12:35:13 am
content: No, that's for the programmer with 3rd party toolchain support, you can't develop with just that.Still, it's just a plain Cortex M0 and can be programmed with 5 wires (VDD, GND, SWDCLK, SWDIO & RESET_n)The programmer I use is just a PSoC5LP and that's because the 5LP has USB support so it's easier to connect to the PC.Also they support Boundary-Scan Description Language (BSDL) programming and Serial Vector Format (SVF).I think just using gcc and converting it to the right format will do the trick, but I'm not about to do all that since I rather use the toolchain supplied.I'm going to give Kiel a try to see how small an executable I can make (in C), actually I'll just use the default template that they provide:Code:int WriteIO (unsigned int addr, unsigned int data){unsigned int *address = (unsigned int*)addr;*address = (unsigned int)data;return (0);}int ReadIO (unsigned int addr, unsigned int *data){unsigned int *address = (unsigned int*)addr;*data = *address;return (0);}//----------------------------------------------------------------------------------// Custom functions//----------------------------------------------------------------------------------void Delay(int ms){int i , j;for(i = 0; i < ms; i++) {for(j = 0; j < 3333; j++); //Delay = 1ms, mesured by scope for CY8C41xx (CPU = 48MHz)}}void LED_Write(char value){WriteIO(0x40040000, value); //GPIO2.GPIO2_PRT.DR}//----------------------------------------------------------------------------------// main() function//----------------------------------------------------------------------------------int main (void){char leds = 0x01;//Initial state of LEDs: P0 - OnWriteIO(0x40040008, 0x06); //Set Strong Drive Mode for P0 in GPIO2.GPIO2_PRT.PC registerfor (;;){LED_Write(leds);//Invert LED state on P in GPIO2.GPIO2_PRT.DR registerDelay(500);leds ^= 0x01;}}

author: miguelvp
author_rank: Super Contributor
timestamp: September 19, 2014, 01:53:41 am
content: So I used that code with uVision and this is the build log:Code:µVision Build LogProject:D:\Keil\ARM\Examples\Template_Project\Template_Project.uvprojProject File Date: 12/14/2013Output:Build target 'Template_Project'creating preprocessor file for main.c...compiling main.c...assembling startup_CM0.s...linking...Program Size: Code=212 RO-data=208 RW-data=0 ZI-data=512FromELF: creating hex file...After Build - User command #1: .\Hex_Converter\HexConverter.exe .\\Hex_Converter\\Configuration.ini".\Hex\Template_Project_uVision.axf" - 0 Error(s), 0 Warning(s).Then since I don't have one of these programmers:I took the generated cypress.hex file and use the PSoC programmer. My modified KitProg showed up and I was able to program the board blinking on p0But if I had one of those devices listed above I could just program and debug it using Keil uVision.Maybe I would need to investigate on the external command line programmer but then I wouldn't be able to debug.The thing is that the configurable modules are really code, there is no magic behind it at all, so the module designer just helps automate the process but just code can access all the features as far as I can tell.Note I didn't use the Cypress toolchain at all, just the programmer because I didn't have one compatible with KeilEdit: I forgot I had to change the device ID from 04_C6_11_93 to 04_A6_11_93 to match the SSOP

author: westfw
author_rank: Super Contributor
timestamp: September 19, 2014, 05:13:57 am
content: QuoteHow do you do that last part (selecting the external pin to go with the logic?)? I can't find it :-(

author: miguelvp
author_rank: Super Contributor
timestamp: September 19, 2014, 05:24:23 am
content: The schematic is file TopDesign.cysch that's where you put the pin and rename it.The pins are on file projectname.cydwr under the pins tabAs in pictured here, i named my project blink1.

author: miguelvp
author_rank: Super Contributor
timestamp: September 19, 2014, 06:02:48 am
content: So I left a minor thing off, and of course it does remember my last chip so you can change the device you want to target. So here are the steps with pictures:Edit: This requires a MiniProg3 (or a Pioneer Kit with a custom KitProg installed).A Pioneer kit will work as well but only programming the built in PSoC 4 (CY8C4245AXI-483)1) Create New ProjectFile->New->Project2) Select Empty PSoC4 Design and name project Blink (Click Ok)3) Add digital output pin(optional: if you need to change the chip right click on the project and do "Device Selector" and select your device)4) Right click on pin, select Configure and name it Pin_Blue (Also Turn Hardware Connection off, and click OK)5) Select GPIO p06) Add two lines of code in the for loopCode:Pin_Blue_Write(~Pin_Blue_Read());CyDelay(500);7) Compile and program.

author: westfw
author_rank: Super Contributor
timestamp: September 19, 2014, 06:29:50 am
content: Remember the pinout spreadsheet?QuoteYep; that was wrong. Fixed now, and somewhat updated/reformatted.Most importantly, now shows which pins are 5V tolerant.https://docs.google.com/spreadsheet/ccc?key=0AqdMB5dovDUZdGR6cVprUnkwTV9CMUNybV9VMjF5a0E&usp=sharing

author: paulie
author_rank: Frequent Contributor
timestamp: September 19, 2014, 06:16:37 pm
content: AFAIK there are at least 3 slightly different versions of that from Ebay so those board pin numbers may not apply to all of them. In at least one case the power and ground were moved so there could be trouble. IMO better to refer to either signal names or chip pin numbers when pinout matters.Another advantage of the DIY board besides cost and size is the label numbers match chip numbers. Too bad there's no room for signal names but then it would be almost as big as the blue board. A lot of us cut off the JTAG socket because it really serves no purpose.

author: westfw
author_rank: Super Contributor
timestamp: September 20, 2014, 01:55:28 am
content: do ANY of them have documentation? I mean, what is the P2 jumper SUPPOSED to be for?As a board, I find it pretty sucky; it makes me even more curious where it came from.(Doesn't plug into a protoboard, can't be mounted on a "motherboard", has jumpers where it should have switches, mislabeled here and there... Grr.)

author: paulie
author_rank: Frequent Contributor
timestamp: September 20, 2014, 04:44:17 pm
content: LOL. All these Chinese clone-of-a-clone-of-a-clone boards have a back story just like USBasp, promini, serial dongles, etc.. In this case it started out as the ST reference design soon copied and produced by high end maker LCsoft. They were not $7 a pop back then. When second tier copycats like Seeedstudio, Betemcu, and the rest saw how quickly this rose to the top of the ARM dev board stack they jumped on the band wagon. Over the next couple years noname makers started cranking them out like cookies and the price plummeted. No more 50 bucks to play with ARM.As far as docs there's quite a lot but unfortunately, unlike latest craze WiFi/serial modules, yet to be translated from Chinese. To complicate things variations from those from countries like India, who like to add "personal touch", resulted in many different schematic variations. Not all of them correctly labeled or documented. So here we are. Considering S&H quite a bargain unless you are not afraid to pick up a soldering iron which is an even better deal.

author: paulie
author_rank: Frequent Contributor
timestamp: September 20, 2014, 09:28:29 pm
content: To answer your question about the jumper, it connects USB pu r13 to USBP to enable enumeration. Notice that without this installed the PC pretty much ignores this interface. Since none of the open source STlink clone projects like Versaloon ever panned out USB serves no purpose on this board. Just annoying error messages with J2 installed.Recall that on page one I suggested removing this jumper completely otherwise it's almost impossible to press the reset button.

author: westfw
author_rank: Super Contributor
timestamp: September 21, 2014, 07:51:18 am
content: I had removed the jumper to make the reset button easier to press (as you suggested), but I had installed a wire (as someone somewhere else suggested...)Are there any communities that talk about programming the STM32 chips without the ST Peripheral Library? I've been trying to get the USART working (in asm), without much luck. The thread through the plib is hopelessly obscured compared to what I have in mind, so it's not very useful. I've got:Code:UARTInit:/** Uart1 is on Port A9/A10* First Turn on clock for port A, including Alternate Functions, and UART* rcc->apb2enr = iopaen|afioen|usart1en ;*/bx lrldr r0, =RCC_BASEldr r1, [r0, #RCC_APB2ENR]/* old val */orr r1, #RCC_APB2ENR_IOPAEN|RCC_APB2ENR_AFIOEN /* enable PORTA, AltFunc clk */str r1, [r0, #RCC_APB2ENR]orr r1, #RCC_APB2ENR_USART1ENstr r1, [r0, #RCC_APB2ENR]ldr r1, [r0, #RCC_APB2RSTR]orr r1,r2, #RCC_APB2RSTR_USART1RSTbic r1, #RCC_APB2RSTR_USART1RSTstr r2, [r0, #RCC_APB2RSTR] /* Reset the UART */nopnopstr r1, [r0, #RCC_APB2RSTR] /* Un-reset */nopnop/** Set the pins appropriately (A9 as alt function output, A10 default to input)*/ldr r0, =GPIOA_BASE/* GPIO_PORTA */ldr r1, [r0, #GPIO_CRH]bic r1, ( (0xF << ((9-8)*4)) | (0xF << ((10-8)*4)) )orr r1, #((GPIO_MODE_OUT50MHz+GPIO_CNF_AFPP) << ((9-8)*4)) /* output bit */orr r1, #((GPIO_MODE_IN+GPIO_CNF_FLOAT) << ((10-8)*4)) /* input bit */str r1, [r0, #GPIO_CRH] /* set io bit modes *//** Set up the USART itself*/ldr r0, =USART1_BASEldr r1, =F_CPU/115200str.w r1, [r0, #USART_BRR]mov r1, #USART_CR1_TE+USART_CR1_RE /* Enable TX and RX */str.w r1, [r0, #USART_CR1]orr r1, #USART_CR1_UE/* Enable USART as a whole */str.w r1, [r0, #USART_CR1]/* CR2 and CR2 are OK at their default values */mov r1, #'I'/* Initial test character */str.w r1, [r0, #USART_DR]bx lrAnd let me take this opportunity to flame some more at the ST people. Their explanation of the fractional baud rate divisor is ... awful - like it was written by someone who doesn't understand math. And the library follows suit, doing weird math like:Code:integerdivider = ((25 * apbclock) / (4 * (USART_InitStruct->USART_BaudRate)));tmpreg = (integerdivider / 100) << 4;/* Determine the fractional part */fractionaldivider = integerdivider - (100 * (tmpreg >> 4));/* Implement the fractional part in the register */tmpreg |= ((((fractionaldivider * 16) + 50) / 100)) & ((uint8_t)0x0F);/* Write to USART BRR */USARTx->BRR = (uint16_t)tmpreg;Whereas I claim (and have tested, on a desktop) that you can just do:Code:USARTx->BRR = apbclock/baudrate;Because they say that divisor = CLK/(16*Baud), and then convert the integer and fraction parts to nybbles in the BRR separately, but since the fraction needs to be in 16ths anyway, CLK/Baud already puts the same bits in the correct place. Grr.Maybe I should take the opportunity to complain about deriving the current clock rate from the internal state of the chip (but ultimately based on properly defining the crystal clock rate) instead of just #defining it, but I guess that makes SOME sense, what with the possibility of changing clock rates/etc for possible power saving reasons...(In general, the pieces of the peripheral library that I've looked at SEEM like they were carefully written to be inline functions off in a .h file somewhere, which would cause a lot of the ickier looking code to optimize away and end up pretty reasonable. And then maybe some higher-level manager came along and said "We can't have C code in .h files! It's against the xyz standard policy! Move it all into separately compilable library modules immediately!" Sigh.)

author: paulie
author_rank: Frequent Contributor
timestamp: September 21, 2014, 01:02:40 pm
content: Actually I have to agree that .h files are no place for C code. IMO that's asking for trouble and I don't mean just portability difficulties. But keep in mind that this is from someone who is an asm but not C expert. At least not on the level of you or Super Contributor (and ubiquitous, LOL) dannyf.I finally did get the UART working and agree ST docs and libraries were not great help here. My divisor problems were solved with scope and dropping the baud rate down, WAY down. At some point I'll improve things by incorporating your PLL init code. Speaking of which I modified a couple lines in your PLL blinky to work on the DIY board and put it up on page one. Thanks for that. IMO the best learning tool for STM32 asm posted on the net so far.Next step... three words: Aye... Dee... See!

author: Marco
author_rank: Super Contributor
timestamp: September 21, 2014, 03:03:01 pm
content: Quote from: paulie on September 21, 2014, 01:02:40 pmThe only alternative is to make up some new extension for shared inline functions ... and that's just going to piss off 99% of C coders who have to work with your code. Shared inline functions go into .h, it's standard practice.Maybe with LTO we will able to finally stop using inlining, depends on how they handle inline assembly.

author: paulie
author_rank: Frequent Contributor
timestamp: September 21, 2014, 06:47:29 pm
content: Yes, it was not smart for me to include all include files in that comment. More proper would be to say generally the initialization files and a lot depends on the compiler/assembler. The ideal situation would be ability use the same .h for C and asm but most families use different directives to define symbols so separate files are needed anyway. In that case it don't matter if there's code in there or not. Otherwise if you must put code in there make it assembler so it will be accepted by both the assembler and compiler. One of the nice things about GCC is open source and the ability to recognize directives by asm and C.

author: westfw
author_rank: Super Contributor
timestamp: September 21, 2014, 09:25:51 pm
content: QuoteCould you post that code? I've about run out of ideas to try...The details of the "management decision" aren't entirely relevant (and in retrospect, it might have been more like "The 'inline' keyword isn't standard C; we can't use that or the library won't be compilable with every conceivable C compiler that might exist." (I keep seeing "inline" touted as a feature that was added by C++ (and as "one advantage C++ has over plain C is the "inline" capability"), even though I've been using it in standard C for decades...)It's just ... there's a style of writing C code where you really COUNT on having the compiler optimize away a lot of your code, as an alternative to macros:Code:static const debugbits = 0;if (debugbits & DEBUG_PRINTCHARS) {// blah blah}will normally compile to nothing just as well asCode:#if DEBUG_PRINTCHARS// blah blah#endifbut not if put debugbits in a separate file and access it as "external" or a function parameter. The Peripheral Lib code that I've looked through sort-of looks like it is written in that style, and then crippled. I'll see if I can extract an example...

author: westfw
author_rank: Super Contributor
timestamp: September 22, 2014, 05:47:31 am
content: Arrrgghhh! I'm an idiot...Code:UARTInit:/** Uart1 is on Port A9/A10* First Turn on clock for port A, including Alternate Functions, and UART* rcc->apb2enr = iopaen|afioen|usart1en ;*/bx lrldr r0, =RCC_BASEldr r1, [r0, #RCC_APB2ENR]/* old val */orr r1, #RCC_APB2ENR_IOPAEN|RCC_APB2ENR_AFIOEN /* enable PORTA, AltFunc clk */You see that "bx lr" instruction right at the beginning of UARTInit? (Neither did I.) That's a "return" instruction; I added it early in my development as a way to test the syntactic correctness of the code (would it assemble) without actually running the code. And I forgot to take it out, as I tweaked and fiddled with the rest of the init code (none of which ever executed, of course.The UART works much better when you actually execute the initialization code! (It showed up pretty quick when I went to the trouble to figure out how to import the .hex file into the debugger/simulator of one of the other development environments...)Sigh.

author: westfw
author_rank: Super Contributor
timestamp: September 22, 2014, 07:34:27 am
content: Here's working "Hello world" code.In addition to the UART, it includes use of push/pop, .asciz, .align, and gcc local labels.It was SUPPOSED to demonstrate a clever way of passing arguments to subroutines, on systems that conveniently leave the return address in a register. But because of the way Thumb return address work (lsb is 1 to indicate "thumb mode", even though there is no other possibility, and the code has needs to be aligned on even boundries, it turns out to be sorta gross :-(

author: paulie
author_rank: Frequent Contributor
timestamp: September 22, 2014, 01:38:30 pm
content: Whew... That was close. For a minute there it looked like I would have to actually post my version. It would have been a huge embarrassment. Lots of 0xsumpinsumpin and not much RCC_whatever. No calls ATM either. So very nice contribution Bill.It's not obvious but there are half dozen non-forum members hanging on every word here. Maybe suckers for punishment, maybe individuals with too much time on their hands, maybe just curious minds. In any case this is definitely fun and as an incidental side effect getting a hint what makes these things tick,

author: paulie
author_rank: Frequent Contributor
timestamp: September 23, 2014, 02:22:02 am
content: Hmmmm... Two times more clicks on the bottles than the assembly file. I wonder if the universe is trying to tell me something.Well, I put up a version on page one for posterity. It was only necessary to comment out the macro include line to get it to compile without errors. Thanks again for one of the best ARM assembly tutorials on the internet.

author: westfw
author_rank: Super Contributor
timestamp: September 23, 2014, 08:38:33 am
content: Sorry about leaving the extra include in there; I had deleted the code that uses it.FWIW, I've added a first attempt at ARM support to my "Structured Assembly" macros for the gnu assembler, which are here:https://github.com/WestfW/structured_gasIn case you want to do things likeCode:NESTIFTEST:cmp r0, 12_if emov r0, #5cmp r1, #13_if cseor r2, r2_elseadd r2, r2_endifmov r4, #123_endifadds r0, r4_if eqadd r2,#1_elseadd r2,#2_endifIt hasn't been heavily tested yet, the new comment character and asm-only environment caused some problems, and I found some bugs in the older code in the process of getting it working, so use with care if you use it at all (there doesn't seem to have been much interest in it, in general. :-( Only crazy people use assembler any more, and they don't use the gnu assembler.)

author: westfw
author_rank: Super Contributor
timestamp: September 23, 2014, 09:57:26 am
content: QuoteHere we go. I wrote a tiny little program to initialize the USART using the ST peripheral library:Code:static USART_InitTypeDef myuartconfig = {115200, // BaudrateUSART_WordLength_8b, // WordlengthUSART_StopBits_2, // StopBitsUSART_Parity_No, // ParityUSART_Mode_Rx + USART_Mode_Tx, // ModeUSART_HardwareFlowControl_None // HW Flow};int main(){USART_DeInit(USART1);USART_Init(USART1, &myuartconfig);while (1);}Doing NOTHING other than arranging for USART_DeInit and USART_Init to be included in source form and declared to be inline, code size was reduced by about 300 bytes!Code:/usr/local/armgcc/bin/arm-none-eabi-gcc -I . -DSTM32F10X_MD=1 -include assert.h -ffunction-sections -fdata-sections -O3 -g -Wl,--gc-sections main.c stm32f10x_rcc.c stm32f10x_usart.c/usr/local/armgcc/bin/arm-none-eabi-size a.outtext data bss dec hex filename2816 1120 28 3964 f7c a.out/usr/local/armgcc/bin/arm-none-eabi-gcc -I . -DINCC=1 -DSTM32F10X_MD=1 -include assert.h -finline-functions-called-once -ffunction-sections -fdata-sections -O3 -g -Wl,--gc-sections main.c/usr/local/armgcc/bin/arm-none-eabi-size a.outtext data bss dec hex filename2512 1120 28 3660 e4c a.out(You can ignore that -finline-functions-called-once option. It didn't work, and I had to use other means to make sure the functions were inlined. There may be some combination of gcc options that would have done it without modifying the ST source, which would have been nice, but I got tired of searching for the magic combo.)(an empty program compiles to 1680 bytes, so 300 bytes smaller of the ~1140 of "user code" is pretty significant.")

author: SirNick
author_rank: Frequent Contributor
timestamp: September 23, 2014, 08:19:21 pm
content: Forum member hanging on every word here. Nice going, guys. Keep it up. Just finished building a monster dev board of my own, so I'm about to dive into ARM head-first. Stuff like this helps me acclimate to the hardware and terminology, if nothing else.Not sure how much ASM I'll end up using, but there seems to be the possibility of sending impromptu instructions directly to RAM from the bootloader ROM on the LPC, and then immediately executing that code. Seems like it could be a fun way to test out small snippets of code with nothing more than an FTDI cable and serial console. If it works, it could be a cheap and easy alternative to using a full IDE and JTAG debugger. (Not necessarily abetterway, but whatever.)

author: westfw
author_rank: Super Contributor
timestamp: September 23, 2014, 10:28:23 pm
content: Oops. Here's an update on the peripheral lib size thing. I had left out some switches and was compiling for 32bit ARM instead of Cortex, and it turns out that it's pretty easy to supres the startup file inclusion so you can look at just the user code. With those changes, the absolute size difference decreases, but the percentage decrease increases.Code:;;; Libraries...BillW-MacOSX-2<10078> /usr/local/armgcc/bin/arm-none-eabi-gcc -I . -DSTM32F10X_MD=1 -include assert.h -ffunction-sections -fdata-sections -nostartfiles -O3 -g -Wl,--gc-sections -mcpu=cortex-m3 -mthumb main.c stm32f10x_rcc.c stm32f10x_usart.cBillW-MacOSX-2<10079> /usr/local/armgcc/bin/arm-none-eabi-size a.outtext data bss dec hex filename596 36 0 632 278 a.outBillW-MacOSX-2<10088> /usr/local/armgcc/bin/arm-none-eabi-nm -S a.out |grep " T "000080d0 00000018 T RCC_APB1PeriphResetCmd000080b8 00000018 T RCC_APB2PeriphResetCmd00008024 00000094 T RCC_GetClocksFreq000080e8 000000b0 T USART_DeInit00008198 000000bc T USART_Init0000801c 00000006 T _start00008000 0000001c T main;;; inline functionsBillW-MacOSX-2<10080> /usr/local/armgcc/bin/arm-none-eabi-gcc -I . -DINCC=1 -DSTM32F10X_MD=1 -include assert.h -mcpu=cortex-m3 -mthumb -finline-functions-called-once -ffunction-sections -fdata-sections -O3 -g -nostartfiles -Wl,--gc-sections main.cBillW-MacOSX-2<10081> /usr/local/armgcc/bin/arm-none-eabi-size a.outtext data bss dec hex filename356 36 0 392 188 a.outBillW-MacOSX-2<10090> /usr/local/armgcc/bin/arm-none-eabi-nm -S a.out |grep " T "000080c8 00000094 T RCC_GetClocksFreq0000815c 00000006 T _start00008000 000000c8 T mainNote that USART_DeInit calls the RCC_APBxPeriphResetCmd functions, and the inline version successfully eliminates this second level of call as well. USART_Init calls the GetClocksFreq function...

author: paulie
author_rank: Frequent Contributor
timestamp: September 24, 2014, 07:21:41 am
content: I'm trying to reproduce your original snippet but get millions of errors. The same configuration was compiling fine for me via CLI last time I tried couple weeks ago and I'm not sure what changed. Could you provide a bit more detail on the setup? 300 bytes means almost nothing on a 128k chip but when you get down to 4k devices it could become very important. I'm just getting into stm8 (100pcs $21 shipped) and lament the lack of GCC support.

author: paulie
author_rank: Frequent Contributor
timestamp: September 24, 2014, 07:48:52 am
content: Quote from: SirNick on September 23, 2014, 08:19:21 pmThanks for the inspiration. I got dragged into this by the old RC controller project and now the "Zapta Challenge" definitely has me hooked. 8 bit world has been my tramping ground but lately 90% of my time in 32 bit. I got a ton of different breakout boards here and looking around at other potential ARM candidates that are cheap and have serial bootload. Can you flash all the LPC via serial like ST? What chip are you using? Package? Source?

author: westfw
author_rank: Super Contributor
timestamp: September 24, 2014, 09:22:34 am
content: Oh, I agree completely that the size difference is irrelevant on most of the intended target CPUs. But the style seems to be pretty common in the ST library, and it's exactly the sort of thing that causes one to lose confidence in the provider. It's nice that they provide an extensive library, and it's wonderful that it includes source code, but ... I like other peoples' code to be as good as what I'd write (even better: as good as I think my code is :-)) When I can look at the source and immediately find things that make me cringe, that's ... not good.QuoteSure. It violates your 1-minute download rule, though... (actually, I guess I can zip up the directory I ended up with and attach it.)I downloaded the ARM Gnu C compiler from the ARM link that someone posted early in the thread.And I downloaded the ST Nucleo Firmware (STM32_Nucleo_FW_V1.2.1) from ST; this includes the peripheral library and its source code. (it is actually called stsw-stm32143 and is downloadable from here:http://www.st.com/web/en/catalog/tools/PF260215#IIRC, it was a little hard to find...)Since I didn't want to actually search the full ST libraries, or rely on anything pre-compiled, and I was suspecting I might need to modify the sourcecode, I copied all the relevant files into my working directory. That was derived more-or-less by trial and error and ended up something like:Code:cp /Downloads/STM32_Nucleo_FW_V1.2.1/Libraries/STM32F10x_StdPeriph_Driver/src/stm32f10x_usart.c .cp /Downloads/STM32_Nucleo_FW_V1.2.1/Libraries//STM32F10x_StdPeriph_Driver/inc/stm32f10x_usart.h .cp /Downloads/STM32_Nucleo_FW_V1.2.1/Libraries/CMSIS/Include/core_cm3.h .cp /Downloads/STM32_Nucleo_FW_V1.2.1/Libraries/CMSIS/Include/core_cmInstr.h .cp /Downloads/STM32_Nucleo_FW_V1.2.1/Libraries/CMSIS/Include/core_cmFunc.h .cp /Downloads/STM32_Nucleo_FW_V1.2.1/Libraries/CMSIS/Device/ST/STM32F10x/Include/system_stm32f10x.h .So then the compile command decomposes as:Code:/usr/local/armgcc/bin/arm-none-eabi-gcc-I .# Use . as search path, even for system include files-DSTM32F10X_MD=1 # Tell the ST lib files what kind of chip I'm using.-include assert.h # I couldn't (quickly) figure out where the st files# sucked in their definition of "assert", which they# use extensively (and well, I guess.) So I wrote my# own "null" version, and this #includes that at the# start of the preprocessing.-O3 -ffunction-sections -fdata-sections -Wl,--gc-sections # optimization-g# extra symbols, so dissassemly works better.-nostartfiles# Supress the normal startup files-mcpu=cortex-m3 -mthumb # What kind of chip I'm using-DINCC=1# if part of the compile command, tells main.c to# #include the ST .c files, giving the compiler a# fair chance of inlining some of the functions# if omitted, I compile the ST files separately and# link them in (sort of) like libraries.# (I'm pleased that this worked as well as it did!)main.c stm32f10x_rcc.c stm32f10x_usart.c# list of c files (only put main.c here if INCC is set.

author: paulie
author_rank: Frequent Contributor
timestamp: September 24, 2014, 02:51:02 pm
content: Thanks. Among other things that HAL package was one of the missing pieces of the puzzle.BTW I think I have a handle on the ADC stuff now. Although it wasn't part of the original plan, along with the serial routines might even attempt a useful application. Maybe primitive scope or logic analyzer or something. Not even close to those $50 ARM pocket deals but just to see what can be done without FPGA or other external hardware. If nothing else then just to poo-poo naysayers who insist this is not possible.

author: SirNick
author_rank: Frequent Contributor
timestamp: September 24, 2014, 08:00:14 pm
content: Quote from: paulie on September 24, 2014, 07:48:52 amI have completely different motives than you -- for one, I'm not putting up any barriers to cost or ease of reproduction. But, my goal is similar. I'm currently not an expert at.. anything really.. but I'm enthusiastic and want to contribute to the micro community from which I've gained so much. This project, for me, is half skill builder, half practical product.As for being able to flash "all" the LPCs via UART? Not sure. I have on-hand some LPC4078 (LQFP-100), LPC812 (TSSOP-20), and an Xpresso board with an 1115 IIRC (haven't used it yet.) The 40xx and 8xx series, at least, have ROM bootloaders with UART support, and I get the impression that's the norm. So, if not all of them, at least the modern ones should.Ideally, I want to do something similar to what you guys are doing (focused on C though), and start publishing info on how to get started with a blank IC, a code editor of your choice, a minimal GNU toolchain, and an FTDI cable. Low barrier-to-entry stuff, with a solid understanding of what does what.To that end, I'm working on code to do PC-to-IC and IC-to-IC ISP via UART. (Yes, I'm reinventing some wheels here, but that's part of my process. If you can write functional code from scratch, you probably have a fairly solid understanding of the concept in question.) Then, I want to sort out the basic dependencies, and where to get them. (Haven't completely sorted out where to get libraries that are essentially freely redistributable. Extract from vendor tools? Reference code from ARM? Do I have to write those from scratch and release into public domain?) Then, I want to bring in the typical building blocks -- FreeRTOS, lwIP, USB stack, etc.This is all iterative, and once I an OS with IP stack running, my dev board turns into a useful device, and I'll have enough experience to help others figure out how to turn parts into products of their own. (Assuming some electronics background. I'm still far from qualified to teach those skills, though I might publish what I know and let the Internet correct me any time I'm wrong. I just want to avoid leading people astray.)

author: paulie
author_rank: Frequent Contributor
timestamp: September 26, 2014, 09:44:01 am
content: Quote from: SirNick on September 24, 2014, 08:00:14 pmI would love to see that happen particularly in view of key words "GNU" and "FTDI". I haven't had much time to investigate in detail but after browsing specs I ordered a few LPC812M101JD20FP from Mouser. Not much more than a dollar each so fits right into my area of interest for this thread. There's a big stack of blank breakout boards sitting here waiting. Have you compiled or flashed any chips yet? Is there a small programming utility similar to ST flash demo or STVP?

author: SirNick
author_rank: Frequent Contributor
timestamp: September 26, 2014, 10:16:56 pm
content: You know what, I think I'll start a new thread on my project. Don't want to disrupt the momentum you guys have going.https://www.eevblog.com/forum/microcontrollers/lpc-from-scratch/

author: paulie
author_rank: Frequent Contributor
timestamp: September 27, 2014, 05:35:49 pm
content: Quote from: mrflibble on September 27, 2014, 05:11:19 pmYou are right, it's probably not a good idea to compare ST chips in the LPC thread so here we are.I might be wrong and open to education. Admit not pouring over F030 specs but just listening to ghetto talk. Can you be more specific about the advantages of F030? Also my shopping for that has only been Ebay type sites where they are quite expensive so could use a link to 70 cents.

author: mrflibble
author_rank: Super Contributor
timestamp: September 27, 2014, 06:00:30 pm
content: Quote from: paulie on September 27, 2014, 05:35:49 pmWhat now? You say F103 is cheaper than F030. That is easy enough for me to check (and exploit by pressing BUY NOW). Explaining what I like about chip #1 vs chip #2 for a few projects takes far longer.You have PM with link to $0.70 goodies.

author: mrflibble
author_rank: Super Contributor
timestamp: September 27, 2014, 06:25:45 pm
content: Short version of why F030 instead of F103:For a given cost of the chippies:number of timers + usable PWM pins + usable ADC channels while still having an USART + debug interface. Basically cost per PWM output + ADC input pair, while still maintaining a decent adc converter per adc channels ratio. PWM has to be center aligned, so that limits the timer to advanced or some of the general timers.And then all things considered, including but not limited to price, the F030 turns out to be "better" than F103. So in this case better happens to be how many of resource type XYZ can you actually use, while not getting IO pin collisions with that other resource. And I've seen enough MCU's where that turns out to be a depressingly low ratio.But overall, the F103 datasheet has larger numbers in it. No denying that. It's just that useful pins + used peripherals / $$$ turns out better for F030 in more than zero cases.Anyways, I like the F103 as well and intend to plonk it in some other projects. As far as I'm concerned it is not so much this is better than that PERIOD. It's just that for one use case one chip turns out better, and for another use case the advantage goes to some other chip. At the moment I mainly muck about on ST chips, and TI to a lesser extent. Only so much time in the day to familiarize yourself with a new vendor's goodies.On the list of possibly fun to try are those NXP's (have been there for a long time now) and those damn cute PSOC's. Although to be fair the PSOCs stand a better chance of being ordered since they actually bring some new solutions to the toolbox. LPC would just be more of the same (for me). But that doesn't stop me from reading other people's exploits on those, because who knows what cool stuff they find.

author: paulie
author_rank: Frequent Contributor
timestamp: September 28, 2014, 09:13:35 am
content: Quote from: mrflibble on September 27, 2014, 06:00:30 pmThanks for that. However maybe you overlooked the shipping charges there which bring actual cost to $.90. Still a good deal but I'm spoiled by being lucky to snag 103 for a dime cheaper ($.80). I realize this is not a fair comparison because of quantity and not just a click on "buy now". F0 not being a commodity item is not available through that channel. But maybe you can see why I don't consider those a bargain.Speaking of comparisons, I want to thank you for motivating me to finally cruise that spec sheet too. Here's a little summary table I spent a couple minutes throwing together:Code:STM32F103C8T6 STM32F030F4P6M3 M072mhz 48MHz128KB flash 16KB3 UART 1 UART36 io 1520K ram 4KThere's more but probably enough to allow most readers to decide which is the "better" chip. Considering cost is similar and 103 is orders of magnitude more available I've made up my mind.BTW as far as pin/function mapping I find it hard to imagine the 20 pin crippled chip has advantages over the 48 pin in that area. I spent some time but couldn't find a single example. But we do agree totally on the exception for "more than zero cases". It may be possible the 20 pin has a leg up in terms of PCB routing in some rare design but for the other 99% the 103 would usually do. One can always ignore features not needed but hard to make use of those not present.ps. LPC parts came in and it was surprising to see the 20 pin SMD package was actually bigger than the 48 pin 103, a LOT bigger.

author: paulie
author_rank: Frequent Contributor
timestamp: September 28, 2014, 02:06:43 pm
content: This is probably best answered here because someone else just asked a similar question.QuoteYes.http://www.mouser.com/ProductDetail/NXP/LPC812M101JD20FP/?qs=%2fha2pyFadujd6Yxbwm6s6vWcdu8reqzbi4ydgJDibZaEL%2f0jTMWFtw%3d%3dIn this case I followed the "Fribble Method" of minimizing expense by tacking onto a large order so shipping worked out to about 3 cents each. Even without this total cost would still be a dollar and change. The chips have actually arrived now. Next step lets see if we can manage to program these with same minimum tools as the ST parts.

author: paulie
author_rank: Frequent Contributor
timestamp: September 28, 2014, 06:10:03 pm
content: This is promising. I've hooked one of these up to the PC and it seems to be responding to serial commands as described by SirNick at the beginning of his C/Unix thread. Now to see if the Flashmagic utility sca gave me works to upload a hex file. All I have ATM are ones that were assembled for the ST chips so can't expect it to do anything but it will be a good sign if there are no error messages.

author: nctnico
author_rank: Super Contributor
timestamp: September 28, 2014, 09:41:06 pm
content: Hmmm, NXP cared to put a 30MHz ARM microcontroller in a DIP8 package.

author: paulie
author_rank: Frequent Contributor
timestamp: September 29, 2014, 03:59:08 pm
content: Quote from: mrflibble on September 27, 2014, 06:25:45 pmThat's what I thought. I bought the $4 dev board and a few chips then found out there is no bootloader. The break-in-half board is nothing more than a USB/serial so that can't be used to flash them either. More money for a custom programming dongle? Nope. Back in the junk box.Looks like STM and LPC may be the only solution for low cost ARM experiments.

author: mrflibble
author_rank: Super Contributor
timestamp: September 29, 2014, 05:08:02 pm
content: Quote from: paulie on September 29, 2014, 03:59:08 pmUsing the ~ $25 pioneer board as programmer has been mentioned a few times by miguelvp. Your call if $25 is acceptable for a dev board that can double as programmer for those $4 boards.

author: miguelvp
author_rank: Super Contributor
timestamp: September 29, 2014, 07:36:46 pm
content: Quote from: paulie on September 29, 2014, 03:59:08 pmHow much do you want for your junk?Btw you can use the $4 dev board to program (not debug) the other chips.http://www.cypress.com/?id=4&rID=98796Edit: The $25 Pioneer can also debug the code on the chips, but to just program it, the $4 breakout board will do.Edit2: Also you can use Keil to program (And Debug) the chip:https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg515630/#msg515630But if you use ulink make sure you apply power to the chip because it doesn't supply power.

author: SirNick
author_rank: Frequent Contributor
timestamp: September 29, 2014, 09:43:33 pm
content: LOL Man.. if I ever sell products, I'm going to hire you guys to be my parts shoppers. I'm too lazy.. I just go to Digikey and pick what I want, and grumble if I'm "forced" to second-source stuff from Mouser.Hey, Paulie.. if you or westfw end up with an ASM file for the 812, let me know. I could use something to test the bootloader code I'm working on, and don't want to get distracted going down the rabbit hole of writing a proper test app just yet.

author: paulie
author_rank: Frequent Contributor
timestamp: September 30, 2014, 03:42:45 am
content: Quote from: miguelvp on September 29, 2014, 07:36:46 pmI don't think that's the case. First of you should know the CY8CKIT-049 "programmer" is nothing more than a USB/serial interface and requires the target to have a built-in bootloader. As mentioned last time we discussed this the target chip on the 049 obviously has one but it is not one of the $1 parts included in the promotion.I spent quite a lot of time investigating this and at best came up with several links explaining how to compile and install a custom bootloader using a programmer that has true SWD flashing capability like the miniprog3 or pioneer. These are quite costly for my purpose. Your link showing how to build a programmer using parallax stamp was similar to others that didn't look cheap or easy to implement either.Next in conversations with Cypress FAE at digikey was told the 4200 chips I purchased did not have boot code installed. Other more expensive versions do.Finally cypress documentation AN84858 states:QuoteThere were a few more hints in this direction but along with high cost after promotion ($4-$5 each) I decided these were not worth pursuing as a low cost ARM option for casual experimentation. If you have any convincing evidence to the contrary I would be very appreciative as there's still a few sitting around here gathering dust.

author: miguelvp
author_rank: Super Contributor
timestamp: September 30, 2014, 04:16:38 am
content: Quote from: paulie on September 30, 2014, 03:42:45 amOk, the CY8CKIT-049 is a USB/serial interface and does require the target to have a built-in bootloader, and as you mention the chip built into the 049 has the bootloader programmed.The link I gave:http://www.cypress.com/?id=4&rID=98796Uses that 4200 inside the 049 to program an external chip that doesn't have a bootloader and it's factory virgin, so you can program the 2nd external 4200 (or 4100, or whatever).The program in there uses the on board 4200 pins P2.0 for SWDIO, P2.1 for SWDCK and P2.4 for XRES_n on the protoboard to connect to the external chip. You hook those to the virgin 4200 on P3.2 for SWDIO, P3.3 for SWCLK and the appropriate XRES pin (depends on what chip you have (pin 33 on the 44-TQFP, pin 30 on the 40-QFN or pin 25 on the 28-SSOP packages).So I'm not talking about using just the USB-UART part of the board, but the whole prototype board to program the external virgin chip.QuoteDo you have any current programmers listed here?If you do then you can use Kiel to program and debug the chip. Otherwise you can use the prototype CY8CKIT-049 42xx board as stated.Quotewhat $1 chips did you get (package information) and what prototype board did you get (41xx or 42xx)?Because the project in that link is easier on the 42xx board.The project in that link "4 dollar programmer.zip" should be able to program (not debug) the external virgin $1 chip with any .hex file that is compiled for that external chip.Edit: for example I did program this chip with the Pioneer, and it was one of those $1 chips, I can reprogram it using the $4 42xx prototype board and document the steps if you like.It doesn't have a bootloader because I didn't wire a button to activate the bootloader on it nor a bootloader status led for that matter.

author: Laurynas
author_rank: Contributor
timestamp: September 30, 2014, 05:55:42 am
content: Quote from: miguelvp on September 29, 2014, 07:36:46 pmNice find!I was using my Pioneer as a programmer, but it's nice to see that usb->serial->1$ PSoC->SWD programmer is implemented.I wonder if this would work with 4000 series basic chips

author: miguelvp
author_rank: Super Contributor
timestamp: September 30, 2014, 06:06:20 am
content: Quote from: Laurynas on September 30, 2014, 05:55:42 amAs the target yeah, but not as the programmer since you need the UART and the UART SCB mode components which they won't be present in the 4000 series.I know they are present in the 4200 I hope they are in the 4100 as well.Edit: BTW, are you using the pioneer as a programmer debugger or just as a programmer? the reason I ask is because there is a way to use it as a miniprog 3 if you are interested.

author: miguelvp
author_rank: Super Contributor
timestamp: September 30, 2014, 07:29:05 am
content: Ok, didn't do the detailed in-depth yet but just wanted to make sure it worked.Caveat: and a big one! the project is not a bootloadable one so once you program your $4 prototype board you can't restore it unless you have another $4 board or a $25 Pioneer or a $90 miniprog, or other programmers including Altera and Xilinx programmers among the ones supported by Keil, but I only have the Pioneer and the $4 prototype board (2 of them one 42xx the other 41xx and I haven't tried it with the 41xx yet).So I took the project and built it, boot loaded it into the prototype board.Then I made a blinky program for the external chip and uploaded the .hex code following the instructions.wired the VDD, GND, XRES, SWDIO & SWDCLKAnd it runs the blink program on the external chip just fineAgain, this will disable the bootloadable code on the prototype kit, I guess I can work on making the $4 programmer code bootloadable so you don't brick the prototype board.I can recover it because I have the pioneer to override the code, but in any event, once you program the prototype kit as a programmer you can use it indefinitely by changing the python script to point to a different hex file to program your target chip.Edit2: One more caveat, unless you put the right decoupling caps to use the internal regulator, you have the choice of shorting pins but then you have to feed it 1.8V +- 5% available on the VCCD pin but that is not exposed on the headers and it just goes to C1, I guess you can solder a wire to get the VCCD 1.8 rectified voltage if you decide to short the target chip pins to use the external regulated supply.But might as well put the decoupling caps so you can feed anything from 1.8V to 5.5V.

author: Laurynas
author_rank: Contributor
timestamp: September 30, 2014, 07:47:12 am
content: Quote from: miguelvp on September 30, 2014, 06:06:20 am4100 series have SCBs so they should work here. But I just wish that someone would write a decent software UART (not just TX that cypress has as standard component.) this way we could make some use of ARM core and get this into 8 pin minimal devices. (not that it has some real cost advantage, just for fun:))As for pioneer I soldered some wires where the resistors were so it works like a proper debugger.

author: miguelvp
author_rank: Super Contributor
timestamp: September 30, 2014, 07:58:53 am
content: Quote from: Laurynas on September 30, 2014, 07:47:12 amYou'll be interested then in this:http://www.element14.com/community/thread/27067/l/psoc-5lp-programmer-firmwareOn the 2nd page I modified the released 2.03 KitProg code to use the 5LP header to drive the SWDIO and SWDCLK, also not in there I changed the version.h code to force it to 2.08 so that it works with other cypress tools.http://www.element14.com/community/thread/27067?start=15&tstart=0

author: Laurynas
author_rank: Contributor
timestamp: September 30, 2014, 08:41:32 am
content: bookmarkedmuch more work done than soldering, but looks much better than my solution.

author: miguelvp
author_rank: Super Contributor
timestamp: September 30, 2014, 09:15:24 am
content: Quote from: Laurynas on September 30, 2014, 08:41:32 amNot really more work, I just changed two pins on the cydwr file so it will use the 5LP header pins for SWDIO and SWDCLK and the version number, also prevented the bootloader/bootloadable modules to upgrade past version 1.1 and the USBFS to leave them at 2.51 or 2.50 where 2.51 was not an option.

author: Laurynas
author_rank: Contributor
timestamp: September 30, 2014, 10:26:34 am
content: Quote from: miguelvp on September 30, 2014, 09:15:24 amBy changing version number you are telling PC that it's using new firmware while it does not do so.While this will work in most cases, some risk exists unless cypress keep updating their programmer code source.Soldering 3 wires is a less risky solution, but it makes pioneer kit unusable without re-soldering resistors.Anyway this PSoC 4 programmer code and your PSoC5 changes are progress towards AVR style cheap dev tools. And that is important to attract more devs to this great architecture.

author: paulie
author_rank: Frequent Contributor
timestamp: September 30, 2014, 11:32:51 am
content: Quote from: miguelvp on September 30, 2014, 04:16:38 am42xx board and CY8C4245PVI-482 chips so my prototype looks exactly like yours. It seems that two of your solutions will work for super low cost programming. Reprogramming the kit board will keep cost to $4 which is well within my budget and would fit right into the purpose of this thread. Because they referred to the board as "Stamp" I initially confused it with the Parallax product so didn't appreciate this approach. Definitely worth a try.More importantly the ability to use an STlink dongle is great news because a couple of those were purchased, one on Ebay for $5 and another on Aliexpress for $4. This last solution is by far the easiest since there are no modifications involved. Installing the Keil package on my netbook is a bit of a pain but when the LPC and STM8 projects are done this may be next.Thanks for taking time to explain this and hopefully more details and discussion are coming.

author: paulie
author_rank: Frequent Contributor
timestamp: September 30, 2014, 11:55:04 am
content: Quote from: SirNick on September 29, 2014, 09:43:33 pmFor me it's the other way around. Mouser prices are significantly less than Digikey (although pressed they will usually match) but the clincher is inability to use Paypal at Digikey. My account always has balance so fees are avoided and I'm very fond of the protection policy which has saved my butt more than once.Quote from: SirNick on September 29, 2014, 09:43:33 pmI have a package with linker script, source, and hex identical to the ST one on first post here but for LPC. I was planning to put up the ST8 stuff first and don't know if it will be timely or useful to you but will see if I can dig out the LPC version when i get home.Quote from: SirNick on September 29, 2014, 09:43:33 pmToo much time watching Matrix movies? Take the blue pill.

author: paulie
author_rank: Frequent Contributor
timestamp: September 30, 2014, 12:14:17 pm
content: Quote from: mrflibble on September 29, 2014, 05:08:02 pmIf these were to be used for serious development, even for hobby use, that would make sense. In my case 8 bit is still my main arena and ARM is just casual experimentation. There are so many families and variations cost would quickly add up. Already over a dozen different parts from 4 manufacturers and it ain't over yet so we would be talking big money if I adopted this mindset:Quote from: Bassman59 on August 08, 2014, 04:58:49 amHe considered that a bargain. I suppose it sounds great compared to the old days when hundreds for hardware and thousands for software were the norm but not in my case which is just for curiosity and fun.

author: miguelvp
author_rank: Super Contributor
timestamp: September 30, 2014, 02:49:26 pm
content: Quote from: Laurynas on September 30, 2014, 10:26:34 amI agree, I had it as 2.03 since most of the toolchain will just complain that is not up to date but that's fine, the only piece of software that refused to work was the bridge control panel that would not connect unless the kitprog was on the latest version. That's the reason I changed it and I can communicate with the external chip via I2C etc via the 5LP.@paulieI will work on a bootloadale version of the $4 programmer, and add more detail on the process.Also I want to note that after the promotion ($1 which today is the last day) they wont go to $4-$5 a pop, regularly the one you got is $2.49 qty 1 I believe.I'll add more details on the third party programmers but I don't have an st-link so I can't tell if that will work for sure until someone tries. You can create the full project in Creator including programming the UDBs and then export to keil and theoretically you should be able to use the supported programmers. The application note regarding uVision only used ulink pro, but that doesn't mean the other ones won't work.In theory you can use any micro controller to program the chip via SWD.

author: miguelvp
author_rank: Super Contributor
timestamp: October 01, 2014, 12:44:23 am
content: So I did look more into the project and it does have the bootloader already in there, weird they don't have the source for it just the hex file as a dependency.But if I press the user button while powering it with the programmer installed it does blink and it will accept a new bootloadable program.The first time I did try, I used the prebuild one in there and that bricked the prototype board, but I did reset it back with the pioneer.So you have to load the 4 dollar programmer project and upgrade the components build it and then program the board.I'll do a step by step instructions shortly.

author: westfw
author_rank: Super Contributor
timestamp: October 01, 2014, 05:46:21 am
content: QuoteTechnically, the STM32F103C8t6 only has 64k of flash.WRT in-lining the standard peripheral library:It turns out that there is a simpler way to get partly optimized code. Simply include the .c file from the STP modules as well as the .h files:Code:#include "stm32f0xx_rcc.h"//clock routing used#include "stm32f0xx_gpio.h"//gpio modules used#include "stm32f0xx_adc.h"//adc module used#include "stm32f0xx_usart.h"//usart used#include "stm32f0xx_misc.h"//interrupts used#ifdef DOINLINE#include "stm32f0xx_rcc.c"//clock routing used#include "stm32f0xx_gpio.c"//gpio modules used#include "stm32f0xx_adc.c"//adc module used#include "stm32f0xx_usart.c"//usart used#endifDoing this for Dannyf's init/adc/uart blinky program shaved off a bit more than 10%, which isn't bad for an essentially zero-effort change. It didn't improve any using modified STP files, either. (However, the simple uart deinit/init example, which was crafted to explicitly capitalize on the inline definitions, DID do much better with modified STP source - it only went down about 5% in size with the double-includes. I'm not sure exactly why...)Code:BillW-MacOSX-2<10307> make dannyn/usr/local/armgcc/bin/arm-none-eabi-gcc -DSTM32F10X_MD=1 -mcpu=cortex-m3 -mthumb -O3 -ffunction-sections -fdata-sections -Wl,--gc-sections -gdwarf-2 -include assert.h -o danny_normal -DSTM32F030=1 \-I normal danny.c \normal/stm32f0xx_misc.c normal/system_stm32f0xx.c \normal/stm32f0xx_usart.c normal/stm32f0xx_rcc.c \normal/stm32f0xx_adc.c normal/stm32f0xx_gpio.c/usr/local/armgcc/bin/arm-none-eabi-size danny_normaltext data bss dec hex filename3288 1120 40 4448 1160 danny_normalBillW-MacOSX-2<10308> make dannyi2/usr/local/armgcc/bin/arm-none-eabi-gcc -DSTM32F10X_MD=1 -mcpu=cortex-m3 -mthumb -O3 -ffunction-sections -fdata-sections -Wl,--gc-sections -gdwarf-2 -include assert.h -o danny_i2 -DSTM32F030=1 \-I normal -DDOINLINE danny.c \normal/stm32f0xx_misc.c normal/system_stm32f0xx.c/usr/local/armgcc/bin/arm-none-eabi-size danny_i2text data bss dec hex filename2900 1120 36 4056 fd8 danny_i2

author: miguelvp
author_rank: Super Contributor
timestamp: October 01, 2014, 06:09:47 am
content: Quote from: paulie on September 30, 2014, 11:32:51 amThis is a link to part one out of three, in here i'm just creating the target program for the virgin chip.https://www.eevblog.com/forum/microcontrollers/psoc-examples/msg522554/#msg522554Next I'll put the steps to program the prototype board to act as a programmerand after that I'll put the steps to use the programmer to program the code from part 1 into a virgin chip that has no bootloader on it.(I might do part two now, or maybe tomorrow since it's 1 AM already)

author: miguelvp
author_rank: Super Contributor
timestamp: October 01, 2014, 08:28:41 am
content: Oh well, decided to stay up (it's 3:30 AM now) but I have all three parts posted in there:https://www.eevblog.com/forum/microcontrollers/psoc-examples/msg522554/#msg522554

author: paulie
author_rank: Frequent Contributor
timestamp: October 01, 2014, 12:50:38 pm
content: That's pretty impressive. You have proven we dont have to end up in the poorhouse to play with PSOC4 either. I plan to try this out myself as soon as my STM8 and LPC projects are done. Only one GUI based setup at a time fits in the limited SSD space on my day computer which is a netbook. I wonder if there might be a small flash utility hidden somewhere inside the Keil or Creator package. This would allow me to fit PSOC in with the other minimal GCC toolsets like I've done with STM and LPC.So far it looks like we have 3 members of the $1 one minute ARM club: ST, LPC, and PSOC. Maybe there are others hiding out there too.

author: mrflibble
author_rank: Super Contributor
timestamp: October 01, 2014, 07:35:47 pm
content: Quote from: westfw on October 01, 2014, 05:46:21 amIndeed. And 37 gpio.The STM32F103RET6 is the one in the bigger package with 128k flash.

author: mrflibble
author_rank: Super Contributor
timestamp: October 01, 2014, 07:38:06 pm
content: Quote from: miguelvp on October 01, 2014, 08:28:41 amAnd thank you very much for posting all that. Those posts just made a psoc buying incident very very likely.

author: paulie
author_rank: Frequent Contributor
timestamp: October 02, 2014, 09:22:16 am
content: Quote from: mrflibble on October 01, 2014, 07:35:47 pmSTM32F103C8T6 is the one that's much cheaper in medium package with 128k flash.Some may have noticed the PSOC promotion is over. My $1 chips would cost over $4 with shipping now so good thing I got in under the wire. It might still be worth it to me if it was possible to use STlink for programming but so far no evidence this actually works.

author: Kostas
author_rank: Regular Contributor
timestamp: October 02, 2014, 09:36:00 am
content: Quote from: paulie on October 02, 2014, 09:22:16 amIs it over? It seems I can still buy them at $1 a piece, with free shipping. In fact, it seems I can get any ic with free shipping, but not any of the dev kits they offer.

author: aon
author_rank: Contributor
timestamp: October 02, 2014, 10:58:45 am
content: Quote from: paulie on October 01, 2014, 12:50:38 pmSome of the Silabs EFM32ZG chips are pretty close to a dollar (even in singles) and come with a UART bootloader for low-cost programming. But they're in QFN's which might be a show stopper for some, and availability via the inofficial channels is close to nonexistent (EDIT: actually, taobao has some things that look rather interesting, might have to look into that at some point).Oh, and there are some cheap chips in the freescale kinetis L series as well that I've looked at. For me, the thing that separates ST from the rest is the abundance of (some variants of) the chips and cheap programming tools.

author: mrflibble
author_rank: Super Contributor
timestamp: October 02, 2014, 03:20:31 pm
content: Quote from: paulie on October 02, 2014, 09:22:16 amDatasheet?

author: paulie
author_rank: Frequent Contributor
timestamp: October 02, 2014, 03:44:50 pm
content: LOL. This has been discussed here, in the ghetto thread, my RCG kinks on page one, Multiwii forum, and many other places on the internet. Contrary to specs 103c8 have 128k flash. This is easily demonstrated with the ST flash program by overriding the default 64k entry and verifying true size with "fill" and "verify" options on the next page. Also note that several commercial products depend on this overage.It's possible that new versions may not have this bonus feature and ST may start producing chips without but IMO more likely to get hit by a meteor. Just one of the reasons this particular chip remains untouchable regarding MCU cost/benefit.

author: mrflibble
author_rank: Super Contributor
timestamp: October 02, 2014, 03:50:54 pm
content: I was almost waiting for it. I tend to stick with datasheets when listing features forotherpeople's benefit, but to each their own method of presenting information.

author: westfw
author_rank: Super Contributor
timestamp: October 02, 2014, 05:51:58 pm
content: QuoteIt does bother me that we're ignoring datasheet specs and paying "gray market" prices that aren't reproducible from generic vendors (even in large quantities. Mouser/digikey prices for stm32f103c8t6 are about $3 in full reels of 2400.) Especially without obvious explanations...

author: SirNick
author_rank: Frequent Contributor
timestamp: October 02, 2014, 06:34:10 pm
content: It makes me wonder as well. What benefit is there to the manufacturer to underrate the flash spec? Strictly a yield thing? Is flash production that prone to failure? Hmm...Definitely not something I would bank on, without some word from the vendor saying: "Yep. It's here to stay. Just too lazy to change the specs."

author: paulie
author_rank: Frequent Contributor
timestamp: October 03, 2014, 01:57:02 am
content: Unlikely ST will issue a press release saying " Yup, those $5 chips are EXACTLY the same die as the $1 chips". Unfortunately for us not a humanitarian institution totally unconcerned with profit. Instead they must have discovered that it's cheaper to maintain one product line vs two. At the risk of upsetting again here's a couple more:Some of the six pin "brain dead" Atmel chips have twice the stated memory too. Really. And atmel does not advertise this either.ATMEGA328 runs fine at 16mhz on 3.3v. Over the entire temperature range. Just like with STM32 there are some (successful) commercial products here that depend on bonus features. Not a single credible case of failure out of thousands of users.Of course if something like military or life dependent applications are involved it might be a good idea to stick with the party line. Not so much for technical reasons but mainly to avoid vulnerability in potential tort actions. In any case I'm willing to take the hit for any tragic hobby mishaps resulting from my evil misinformation campaign.There are generally two basic viewpoints on this subject, those who have decided datasheet is bible and those with a more atheistic attitude. Personally I am oriented more toward practice than theory. You can call it cutting corners if it makes you feel better. It's a choice and has held me in good stead so far as apparently yours has for you guys. Just my two cents, or should I say dollar and two cents.

author: westfw
author_rank: Super Contributor
timestamp: October 03, 2014, 05:09:49 am
content: So neglecting politics, what's the next thing to implement in assembler?

author: true
author_rank: Frequent Contributor
timestamp: October 03, 2014, 06:46:36 am
content: Quote from: paulie on October 02, 2014, 09:22:16 am~$2.50/ea, free shipping direct from Cypress... not sure why you keep saying >= $4...

author: miguelvp
author_rank: Super Contributor
timestamp: October 03, 2014, 06:51:55 am
content: Quote from: true on October 03, 2014, 06:46:36 amI know, I brought that up about 3 times already.

author: paulie
author_rank: Frequent Contributor
timestamp: October 03, 2014, 11:28:03 am
content: Because that's what mouser charged when I went back to purchase more for a friend (3.28*5=15.4 +5.99=22.39 /5= $4.48 each):http://www.mouser.com/ProductDetail/Cypress-Semiconductor/CY8C4245PVI-482/?qs=sGAEpiMZZMuoKKEcg8mMKCq3qKLhcxNGDk4txzttb8I%3dCloser to $5 at Digikey. If someone had mentioned here that free shipping was available from Cypress I could have cut my expenses in half.

author: paulie
author_rank: Frequent Contributor
timestamp: October 03, 2014, 07:33:36 pm
content: Quote from: westfw on October 03, 2014, 05:09:49 amMore like religion if you ask me. I shouldn't complain because if it weren't for "white market" suckers to support development and infrastructure us black marketeers would be left out in the cold.To answer your question I've managed to get a crude logic analyzer implemented in 103c and trying to port to STM8. 25 cent LA!Meanwhile, in addition to the LPC demo I posted on page one earlier this week, the STM8 dummy demo in reply #5 slot has been updated with one that actually toggles the LED. Still only 3 instructions. On request a photo of the setup has been added:

author: paulie
author_rank: Frequent Contributor
timestamp: October 03, 2014, 09:45:13 pm
content: Quote from: aon on October 02, 2014, 10:58:45 amThanks for the hint. I ordered EFM32ZG110F32-QFN24 as soon as you suggested them and they just arrived. Even with shipping and in single they are little more than a buck. 8k version 80 cents. Totally weird pricing schedule. Amazingly almost no difference in price between 1 or 100 pieces and 32k vs 8k.QFN is not a big problem at all. In fact with a dab of paste and cheap heat gun even easier because there's no soldering iron involved. The 24 pin fit right in place on those generic QFP boards. They look like a very good deal and can't wait to try these out. Now to download some manuals and learn how to program. Thanks again for finding new candidates for the 1$ 1 minute club.

author: SirNick
author_rank: Frequent Contributor
timestamp: October 03, 2014, 10:44:01 pm
content: Quote from: paulie on October 03, 2014, 09:45:13 pmAmen to that. I got one of those OSH Stencils too. My dev board was the first time I've used many of the SMD packages, with only a few trial runs with TSSOP parts before it. The whole process went very smoothly. Had a few solder bridges to clean up due to using too much paste, but that was easy to fix. The most time-consuming thing was sorting through my parts to find the R and C values I needed. Definitely makes me think twice about doing through-hole stuff any more than I have to.

author: miguelvp
author_rank: Super Contributor
timestamp: October 04, 2014, 12:34:45 am
content: I wanted to just try to make a QFN deadbug style just to know I could do it.So I took the wiring diagram and flip it, then flipped and mirror all the labels and components so I could have the bottom view (and changed the label from top view to bottom view).I wired it up until I got to the XRES, added the decoupling caps and connected the ground with a 22 AWG cable on the other side of the board. Only 9 pins left but I had plenty of GPIOs plus SWDIO/SWDCLK so I attempted to program it before completion.It powers up and I get regulated 1.8V out of VCCD. I got no shorts but hooking it up to my programmer it doesn't recognize it. Granted, I think I connected 4V by mistake to VCCD instead of VDDD so I might have fried the chip.On another document I saw that VDDD and VDDA should be shorted, I tried that as well but it just doesn't talk to the programmer via SWD.I know I can buy 5 boards for a buck or so, but I just wanted to check if I could solder 0.5mm with just one of those third helping hand with magnifying glass, some wire that I have no idea where it came from and my cheap Tenma (Hakko knockoff). I still have 19 of those chips left but the next attempt will be with one of those cheap boards and a skillet.I stacked the 0.1uF caps on top of the 1uF caps when both where needed.So right now the only thing this is good for is to regulate from a 1.8V-5.5V unregulated input and get 1.8V regulated output and helped me clear my head while doing it, kind of relaxing since I had no choice but to take my time and work slowly.The pads on those PSoC4 QFNs are smaller than small.I consider the result a Fail, but I did enjoyed wiring it up.

author: true
author_rank: Frequent Contributor
timestamp: October 04, 2014, 03:18:13 am
content: Quote from: paulie on October 03, 2014, 09:45:13 pmTheir pricing shows (especially with typical prices in their propaganda listing them at 100k units) that they only care about very large customers.The chip is pretty light on peripherals for other chips in this price range, but does have a possibly useful mix (2 timers x 3pwm, but no other high speed or higher resolution timers with interrupts; 1 usart 1 i2c, adc, idac, rtc, pulsecounter and that's about it) but still doesn't seem like a bad choice if what it has will fit your application. I almost picked it for an upcoming project but went to $1 sale PSoC4's instead. Project scope also grew so it's a good thing, I need the extra pins, was considering the G210 as well but the peripherals were too limiting; I also was able to use the UDBs on the PSoC4 for my project to great effectI also have some to play around with - maybe I'll come up with some low power project to use it in.

author: aon
author_rank: Contributor
timestamp: October 04, 2014, 07:07:21 am
content: Quote from: paulie on October 03, 2014, 09:45:13 pmAlthough it might be a bit beyond the scope of this thread, another thing that seems nice about the EFM32's is that their standard peripheral library has a permissive open source license (instead of vague statements on a forum which is the case with STM32), and seems to be reasonably well documented. Thedocumentationis reasonably easy to find - I guess the actual code files come in the devboard support packages available on their site.

author: westfw
author_rank: Super Contributor
timestamp: October 04, 2014, 07:37:19 am
content: QuoteThe code I've been looking at has big headers:Code:* <h2><center>&copy; COPYRIGHT 2012 STMicroelectronics</center></h2>** Licensed under MCD-ST Liberty SW License Agreement V2, (the "License");* You may not use this file except in compliance with the License.* You may obtain a copy of the License at:** http://www.st.com/software_license_agreement_liberty_v2*That doesn't seem vague. (although, since it's not one of the much-discussed OSSW licenses, it might take thousands of dollars worth of lawyers before I could have a high confidence that some of the things I've done (like turning the .h files into assembler format includes) are actually permissible. Especially if I wanted to, say, SELL them... ("My business plan predicts that there is a HUGE market catering to people who want to program ARMs in assembly language. I'm going to be rich!")

author: aon
author_rank: Contributor
timestamp: October 04, 2014, 11:18:50 am
content: Quote from: westfw on October 04, 2014, 07:37:19 amI've seen that licence somewhere too - but theSTM32F10x StdPeriph libraryhas nothing of the sort.This topic on the chibios/rt forumcomes up if you dig around a bit.QuoteExactly - the EFM32 emlib uses theZlib licensewhich is pretty easy to understand.I'm aware that none of this probably really matters in real life (especially for no-name hobbyists like me), but it baffles me that someone would homebrew an open source licence instead of just slapping a standard permissive one on something like a peripherals library. Seems like something you'd provide to your customers as a convenience and not a very major piece of IP.

author: westfw
author_rank: Super Contributor
timestamp: October 04, 2014, 08:08:59 pm
content: QuoteSure it does; that's what I was looking at. I was careful to look at the .c files as well as the .h files, too.The discussions you list are a bit old (2011), while the source code I'm looking at all has 2012 or later copyrights.It looks like the STP download is pretty out of date. OTOH, I guess I'm looking at a "STM32_Nucleo_FW_V1.2.1" download rather than a "Standard Peripheral Library" download, and the "New thing" is "CUBE", which doesn't seem to have an F1xx version. Curious.Vendor software licenses usually aren't exactly "open source"; they don't want you adapting their code to some other vendor's chip, for example, and it seems to be relatively frequent that they don't want third parties distributing source to the vendor libraries. (Microchip gets this complaint. If you write OSSW code for some clever USB or ethernet gadget that uses their USB or TCP stack, you can't include the stack in your distributed project; user have to download the stack from microchip separately.) (although: not that different than LGPL.) In general, I'd rather have vendors write their own licenses than slap on the WRONG famous OSSW license! (SO many Arduino *libraries* with GPL3...)

author: paulie
author_rank: Frequent Contributor
timestamp: October 05, 2014, 12:54:35 pm
content: Post number 5 slot has been updated with a command line version of the STM8 tools:https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg506113/#msg506113150k complete! Even considering the first post GCC package was stripped down to 1% of standard distribution a DOZEN of these could be attached in the same space and still rooms left over for photos. Talk about minimum. One thing puzzles me though: Why must reset vector in the source files be 0x82008004 instead of the expected 0x00008004? WTF?

author: mrflibble
author_rank: Super Contributor
timestamp: October 05, 2014, 11:24:23 pm
content: Quote from: paulie on October 05, 2014, 12:54:35 pmFlash versus sram memory location?

author: paulie
author_rank: Frequent Contributor
timestamp: October 05, 2014, 11:53:30 pm
content: Quote from: mrflibble on October 05, 2014, 11:24:23 pmGood guess. That did play a part in wide performance difference for BOOT0/1 jumper settings on the 103c chip. However not quite the situation with 003 which has no boot. With a little help from single stepping that mystery is solved. No mention of this in any of the docs AFAIK. Here's a hint: begins with the letter 'j'. Let's allow a little time to see if any of the experts can come up with the explanation. LOL.

author: mrflibble
author_rank: Super Contributor
timestamp: October 06, 2014, 12:27:11 am
content: Quote from: paulie on October 05, 2014, 11:53:30 pmThat's easy. That's the January JTagging Janitor Jamboree.And ifthatisn't it I guess I'll just have to wait until the guess timer expires, and the mystery shall be unveiled.

author: westfw
author_rank: Super Contributor
timestamp: October 06, 2014, 08:06:05 am
content: Well, I've found my first case where the C compiler(s) produce better code than I wrote in assembler.??You might remember this simple loop from the clock initialization:Code:clklp:ldr r1, [r0, #RCC_CR]tst r1, #RCC_CR_HSERDY/* wait for clock ready */beq.n clklpThat seems obvious enough. Read the register, check the relevant bit, loop if it's not set.But the C compiler produces code like:Code:lp: ldr r2, [r1, #0]lsls r2, r2, #14bpl.n lpAnd guess what? the "tst" instruction with the immediate bit value turns out to be a 32bit instruction, while the "lsls" instruction to shift the relevant bit to the sign position (it took me a bit to figure out that that's what it's doing!) is only 16bits. So the C code is better.Of course, now that I know this "trick", I can theoretically do the same thing. But it's pretty inconvenient to convert that bitmask symbol value that I have into the required shift value... :-(

author: paulie
author_rank: Frequent Contributor
timestamp: October 06, 2014, 01:40:53 pm
content: Quote from: westfw on October 06, 2014, 08:06:05 amHey... I don't see any C code there at all.It's not surprising that a team of asm programmers, spending years hacking and tuning and who have built the foundation upon which all "centipedes" rest, can do better than me. Somewhere around 90% of my library of subroutine collection was extracted from Objdump dumps. In fact your second example resembles my typical programming than the universally accepted sprinkling of includes, labels and symbols. For me they are better placed as comments. Makes debugging easier. Of course my projects are very simple by comparison so I get away with it.One thing I don't like is when the output of a disassembler is incompatible with the assembler. For me it's a great reverse engineering and debugging tool to be able to feed it back in. As one who is great and wise once said... grrr.

author: paulie
author_rank: Frequent Contributor
timestamp: October 06, 2014, 11:22:21 pm
content: Quote from: mrflibble on October 06, 2014, 12:27:11 amWell at least JTAG was in the ballpark. Looks like nobody here has a clue so the key word was "JPF" (jump far, opcode 0x82008004).Turns out STM8 do not really have a reset vector with address like all the other chips discussed in these threads. Like AVR and others it actually starts execution of code at that location and the "vector" is a jmp instruction not an address. To demonstrate this the demo in reply #5 slot has been replaced with one that has no entry yet runs fine. It's a 2 instruction program now that toggles an LED! Let's see the C centipedes top that. This has always been one of the advantages AVR had over other chips IMO. Particularly on the TINY parts where every byte is sometimes at a premium.Mystery solved.ps. Naturally if you use hardware interrupts the table must be fully populated. At least up to the entry for the peripheral triggering it.

author: westfw
author_rank: Super Contributor
timestamp: October 06, 2014, 11:46:34 pm
content: I'll admit to reviewing the STM8 documentation recently.32bit instruction word, eh? No wonder they seem to have so much flash compared to most other cheap 8bit micros!

author: Kjelt
author_rank: Super Contributor
timestamp: October 07, 2014, 08:04:36 am
content: Quote from: westfw on October 06, 2014, 11:46:34 pmActually the STM8 code is about 30% smaller than a M0 or Atmel AT90. AFAIK the instruction part of the opcodes are 8 or perhaps in some cases 16 bit, the total size of the instruction can be larger due to the addresses or data to operate on. It is a bit hard to jump in 16M address space without a 32 bits adress

author: paulie
author_rank: Frequent Contributor
timestamp: October 07, 2014, 05:07:28 pm
content: Yes, many 8 bit instructions. However AFAIK the few 32 bit instructions have 8 bit operator and 24 bit operand like JPF so can't access 32bit/4Gb.

author: paulie
author_rank: Frequent Contributor
timestamp: October 07, 2014, 06:49:51 pm
content: In the process of playing around with SDCC STM8 compiler a potential inconvenience crops up. It turns out if you make the SWIM pin (PD1) an output and don't have reset hooked up the chip can't be flashed with STVP again. If you do have reset connected the user program does not run automatically after flashing. One solution is to connect a switch to reset like with the STM32 parts but I prefer to simply not use the SWIM pin for I/O and leave reset open. This applies to both assembler and C programs.

author: paulie
author_rank: Frequent Contributor
timestamp: October 08, 2014, 11:12:18 am
content: A fellow at the local amateur radio club had some wiring problems with his LPC project this weekend so a photo of my setup has been attached to reply slot #3:https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg506039/#msg506039.Thanks to cheap chips from Mouser and Flashmagic programming utility working with these is a cinch.

author: Brutte
author_rank: Frequent Contributor
timestamp: October 08, 2014, 12:38:47 pm
content: Quote from: westfw on October 06, 2014, 11:46:34 pmThese have a variable width op-codes. Spanning from one byte up to five bytes. 32-bit is the width of the flash memory.

author: Kjelt
author_rank: Super Contributor
timestamp: October 08, 2014, 12:51:35 pm
content: Quote from: paulie on October 07, 2014, 05:07:28 pmOne exception

author: westfw
author_rank: Super Contributor
timestamp: October 08, 2014, 03:41:03 pm
content: QuoteAh. I see I mis-read the datasheet; it had so little information on the CPU or instruction set that I misinterpreted the "32 bit wide instruction bus" as meaning that the CPU had a 32-bit fixed-width instruction..."Never mind."

author: paulie
author_rank: Frequent Contributor
timestamp: October 08, 2014, 11:54:14 pm
content: Quote from: Kjelt on October 08, 2014, 12:51:35 pmPlus of course the infamous JPF. The 16Mb in my comment was incorrect and has been edited. I meant that with only 24 bits it's not possible to access 4Gb which would need 32 bits which is not possible.Quote from: Kjelt on October 07, 2014, 08:04:36 amWhile it's true some instructions can technically be 5 bytes long, not really because one of those is a "pre-opcode" and the other a regular operator. So with 2 operators that leaves only 3 operand bytes max so 32 bit address is not possible (or needed considering the memory map).

author: westfw
author_rank: Super Contributor
timestamp: October 09, 2014, 05:35:17 am
content: More work on the Hello World assembler code.Added Uart input and decimal output. Demonstrates implementation of "mod" using UDIV/MLS sequence (gleaned by examining C compiler output) and recursion (!)(Note: no longer works on M0/M0+, because they don't have divide instructions!)

author: paulie
author_rank: Frequent Contributor
timestamp: October 09, 2014, 08:26:47 pm
content: Just tried it and working like a charm. No "corrections" this time. However I'll probably reformat so it can be read with a text editor and rename to avoid confusion with previous versions that had the same filename. I know it's not the case here but in the professional world two different files with same name is a mortal sin. Thanks again for another great educational booster.Not to change the subject (aka to change the subject) I have an SDCC package that's actually smaller than any of the assembly ones and even easier to use. I managed to tame the STVP command line version for use with this and the STM8 assembler so everything, including flashing, is a single keystroke. This will go up on page one too when I get a chance.

author: westfw
author_rank: Super Contributor
timestamp: October 10, 2014, 12:41:14 am
content: QuoteIs it not plain text already? I looks so, here...QuoteAgreed. I don't consider this a different file, though; it has "small" enhancements over the previous post.(Next: interrupts. That will be a new filename.)

author: paulie
author_rank: Frequent Contributor
timestamp: October 10, 2014, 12:47:55 pm
content: I would suggest you continue to attach using the same format as before because there will be dozens if not hundreds of MAC/Linux users who depend on that. It literally only takes 5 seconds or so to load with MS Word and "SAVE_AS/TEXT" but I'm not sure how easy to go the other way. By text I mean compatible with CRLF editors like Notepad.As far as naming it only becomes a serious issue when several files are loaded in the same post like on page one so if you don't mind me copying and renaming there it don't matter what they are originally called.The important thing is that with every new version me and at least a few other guys I know learn new instructions and assembler tricks. Not just this chip either. Your latest effort helped me develop a more efficient version of the STM8 bootloader I've been working on. The existing C implementations didn't resemble what was really needed feature wise and had no chance of compiling as is under SDCC which is the only C compiler I have room for ATM. At least not without lots of work. Some addresses in that STM8L.H file are flat wrong for the 003 chip. A few changes were made to accommodate the demo but it was just easier for me to implement in asm. Thanks again for taking time to help out the bare-metal crowd.

author: westfw
author_rank: Super Contributor
timestamp: October 10, 2014, 02:54:56 pm
content: Ahh. CRLF vs \n...

author: miguelvp
author_rank: Super Contributor
timestamp: October 10, 2014, 04:03:58 pm
content: people should use notepad++ in windows as their default text editor

author: paulie
author_rank: Frequent Contributor
timestamp: October 11, 2014, 07:52:18 am
content: Another first!I've managed to attach a complete C compiler toolset to reply slot #5. A little bigger than I first thought but still only about a megabyte. Extract with 7zip and just like before hit 'a'. This time the hex file is also automatically flashed into the chip. AFAIK it don't get any easier than this.ps. Here's a peek at the hello world source file:Code:/* uartsxx.c uart tx string created by paulie on eevblog.com 10/8/201401 minimum*/#include "stm8s.h"int tx_string(const char *str){ unsigned char i;i=0; while(str) { while(!(USART1_SR&USART_SR_TXE)); USART1_DR=str[i++]; }return(i);}int main(){ unsigned long l=0;CLK_DIVR=0x00; //frequency 16 MHz #0x50c0USART1_CR2=USART_CR2_TEN; //en TX RX #0x5235USART1_BRR1=0x11; //368=9800 11=57k baud #0x5232while(1) { tx_string("Hello World! "); l=720000; while (l--); } //1 sec}

author: westfw
author_rank: Super Contributor
timestamp: October 11, 2014, 08:00:30 am
content: (really wishing the STM8 stuff was in a separate thread...)I have an ARM asm interrupt-driving UART receiver working. It needs cleaning up (and probably adding the tx half) before I post it. It was ... interesting. I have to confess that I'm using the Keil simulator to debug some of this code; debugging with print statements and LEDs doesn't work too well until after you get rid of the infinite-fault generating code...Code size now 636 bytes, BTW. I put the vector table in RAM and fill the unused vectors at runtime (memset(), essentially, sacrificing RAM to save flash space. Which is good, because there are 300+ bytes of vector space. (although of course it takes some code to implement the fill, and some more to add the vectors that are actually used.)

author: paulie
author_rank: Frequent Contributor
timestamp: October 11, 2014, 09:13:12 am
content: Quote from: westfw on October 11, 2014, 08:00:30 amThis didn't seem too upsetting taking up half the "STM32 Ghetto" thread. Cortex M7 and STM4 did'nt strike me as particularly ghetto either so I'm guessing the viewing audience will survive. I considered putting some of this in that thread but decided against it in view of the drastic fear of asm there. Anyway getting this C compiler down to where it would fit as a forum attachment has me feeling quite pleased with myself.ARM notwithstanding, STM8 is the first really impressive technology to catch my eye in a long time due to being "Worlds Lowest Cost MCU". I must admit I owe it all to that great humanitarian and Super Contributor dannyf.

author: paulie
author_rank: Frequent Contributor
timestamp: October 11, 2014, 12:17:18 pm
content: To avoid derailing the SuzyC thread any further it might be more polite to continue here since this is already a total train wreck.Quote from: Kjelt on October 11, 2014, 11:10:51 amYes, tiny die is great but the problem is they have chosen pure "Unobtanium" as a doping agent. An element so rare it has never been detected on earth or anywhere else in the universe by spectroscopic analysis. Additionally predicted to not exist at any time in the future either due to unique paradoxical atomic properties. I would love to be proven wrong here but to my knowledge this is actually the Worlds Cheapest MCU:This was located after less than a minutes search and, as mentioned previously, I've purchased these for 2 cents less. I challenge anybody to find anything with vaguely similar capability and availability.ps. It is also a requirement to consider shipping charges because they actually are included in the "free shipping" on all Ebay and Aliexpress deals.

author: Kjelt
author_rank: Super Contributor
timestamp: October 11, 2014, 02:22:46 pm
content: Paulie: this is not how you compare prices, the reason that some person on Ebay can sell you some processor for a low price can have numerous causes, one that he overordered for a cancelled production and likes to see some return on his lost money (semiconductors can never be given back), another that he found some reels in a container in the alley and took them home.Does that mean he can sell you 1 million of those processors if you wanted to go full production: NO.Does that mean that this is the real cost of that processor: NO.Does that mean ST sells them for that price: NO.Give you an example, if you ask nicely I can sent you 10pcs of a STM8S208K8 for the shipping costs of the envelope, does that mean those processors cost 0,00 so are free? NO.So to compare fairly you should talk to the manufacturer or use the quotes from the same source. Now lets take for instance Farnell that always has too high prices but that is because they give you a service namely you don't have to buy 1 million processors if you only want a few, they have large warehouses where they keep your stuff dry, a lot of personell that will get your stuff and sent it for the next day courier delivery, while on the other hand you had to wait for your container to arrive from China by boat in 2 months time. Anyway that costs a lot extra so those prices are ofcourse much higher than if you ordered directly with the manufacturer BUT you can at least have a fair comparison if the source is equal.Take your STM8S003F3P6 and look at Farnell: they cost € 0,365 ex VAT per 1000 pieces and €0,351 per 8000 pieces.Then look at the STM32F030 and they cost € 0,412 ex VAT per 1000 pieces.So the cortex M0 costs 13% more than the STM8 (1000 pieces) BUT the Cortex M0 has double flash, quadruple RAM and four times more speed AND it is 32 bits.STM8S0 STM32F0Program Memory Size: 8 KB 16 KBRAM Memory Size: 1 KB 4 KBCPU Speed: 16 MHz 48 MHzNo. of I/O's: 16 15I can not disclose or at liberty to disclose the prices what these devices cost if you buy them in large quantities but as I stated in the other topic, the CortexM0 is going to win on price and the reasons are the smaller nm production process (more dies per waver) and also important there are going to be a lot of competitors that are offering the Cortex M0.

author: mrflibble
author_rank: Super Contributor
timestamp: October 11, 2014, 02:39:46 pm
content: Yup, the price point of cortex-M0 is going to be interesting the coming year or so. Aren't ST & NXP migrating some M0/M0+ designs from 90 nm to 40 nm? That would be even better for price per die.Mmh, just checked the article I was thinking of ... that was about "some cortex-M series" being migrated, so not necessarily M0/M0+. But we'll see. Either way, cheaper cortex-M-anything is good news.

author: westfw
author_rank: Super Contributor
timestamp: October 12, 2014, 04:57:27 am
content: Meh, we'll see. I have some $0.25 ATtiny11s that I bought, shortly before they were made unobtainium. TI has essentially gotten rid of their entire line of CM3 chips. When you base a "buy" decision on essentially random factors (like whether they're really cheap from aliexpress), you're at the whim of the manufacturer and whatever distribution chain got them to you. At least with a cortex chip, it's looking extremely likely that there will be some sort of "nearby" replacement, even if (say) NXP decides that the DIP-packaged ARMs are too unprofitable to continue....Aside from the dilution of ARM content here, I also think that the STM8s have enough interest to justify their own thread...

author: westfw
author_rank: Super Contributor
timestamp: October 12, 2014, 05:16:00 am
content: So here's the interrupt-driven "Hello World."There are several interesting "features" exhibited in the new code:1) Use of the ".bss" directive to create data in RAM.2) Remember the STRUCTDEF macro I created to create peripheral register offsets from the C structure definitions? It turns out to be useful for user-defined data structures as well. Like the FIFO queues for the uart.3) double register indexing is used for both the memory fill ( str r0, [r1, r2, lsl #2]) and FIFO code.4) With my simple queue structure, it turns out that that ISR/Thread concurrency is a big issue. I added "critical section" code.5) I sweat that ARM implemented their assembly-language instruction set in such a way as to make it intentionally difficult for assembly programmers to know what is going on, code-size wise. "adds r1, #1" (set condition codes) is a 16bit instruction, while "add r1, #1" is a 32bit instruction. But any add to "lr" is 32bits. Ah well, I suppose it's good for the compiler folk.6) Speaking of C, I was curious if C would generate code similar to my assembly code for q_get and q_put, given the same basic logic (as close as C could come, anyway.) I could, and it did. Almost identical. except....7) Oh look! There are cbz and cbnz instructions; those will be handy.8) When dealing with code addresses in (for example) vector tables ("pointers to functions"), don't forget to add one to the actual address, to select Thumb mode. Otherwise, your exception/fault handler will cause a fault, which ...9) As code complexity increases, the tradeoffs between "fixed ABI" and "carefully crafted register use" become blurrier. I'm using r0-r3 for almost everything, which C considers "not preserved" by subroutines, but I need to preserve them :-(I could be using r4-r7 ("preserved"), but then I'd have to move them in and out of the r0..r3 argument registers.Anyway, here it is...

author: true
author_rank: Frequent Contributor
timestamp: October 12, 2014, 09:25:07 am
content: Quote from: mrflibble on October 11, 2014, 02:39:46 pmIf you see process move, you'll only see this on faster / higher performing parts for quite some time yet. There is little advantage over a proven, cheap low-leakage process to having an even smaller low end core when the bonding pads, higher power portions, etc. still take up a large space. Low power medium-to-low performance parts especially will probably stick on a larger low power process for quite a while.

author: paulie
author_rank: Frequent Contributor
timestamp: October 13, 2014, 07:52:17 am
content: Quote from: westfw on October 12, 2014, 05:16:00 amThe new name and reformatting sure speeds things up but there are some problems getting it to compile. SCB_BASE and NVIC_BASE undefined and '.bss will not fit in ram' errors. Maybe you are using a different linker script? Or maybe mine is not correct for the 103c?Quote from: westfw on October 12, 2014, 05:16:00 amI'm curious too. Would it be possible for you to post the C version ELF file. Source is nice too but my netbook is not set up with the full GCC C compiler ATM and we can generate that from ELF in addition to HEX and LST.ps. I see there are big changes afoot on the avatar area. I was pretty sure you were UK but now see you're a real live nephew of my Uncle Sam. Also I was pleased as punch to see somebody else has immortalized me in his avatar byline. It's true! LOL.

author: westfw
author_rank: Super Contributor
timestamp: October 13, 2014, 08:00:43 am
content: Oops. The existing .ld file has an incorrect RAM amount, and I had to add the SCB/etc to the .asmh file as well.I should put this stuff in a github repository or something...

author: paulie
author_rank: Frequent Contributor
timestamp: October 13, 2014, 08:11:58 am
content: Say, in case you missed it would it be possible for you to put up the ELF file for your C version? I'm very curious about the difference compared to asm.

author: paulie
author_rank: Frequent Contributor
timestamp: October 13, 2014, 08:33:40 am
content: Quote from: westfw on October 13, 2014, 08:00:43 amDid the GCC dudes make a mistake or did I pick the wrong one?Quote from: westfw on October 13, 2014, 08:00:43 amPersonally I dislike all of those repositories so hopefully you will continue to post here too. I know the hotshots love those because it protects their exclusive club and shows how smart they are but note that 90% of lurkers are too lazy to even click on an attachment and 99% won't go to another site. I try to make things as simple and accessible a possible.

author: mrflibble
author_rank: Super Contributor
timestamp: October 13, 2014, 08:51:27 am
content: Quote from: westfw on October 13, 2014, 08:00:43 amThat might indeed help in keeping things a bit organized. Especially over time.Incidentally,bitbucketis a nice free alternative. AFAIK github used to have a free version, but last I checked they required you to enter credit card information even for the free version.

author: westfw
author_rank: Super Contributor
timestamp: October 13, 2014, 09:08:13 am
content: QuoteHmm. I can't tell. Where exactly did yours come from? My gcc download from launchpad.net doesn't seem to have any .ld files for the ST microcontrollers. The Nucleo package, the VLDiscovery package, and chibios, have "correct" versions for slightly different chips with the same memory (103R8, which is the 64pin version), but they all have big copyright notices plastered in them. I can't find anything that looks like the .ld file you had posted (nor a .ld file explicitly for the 103c8...)I've already got the githib account (https://github.com/westfw), so I guess I'm grandfathered. I'm pretty sure they're still free for "open source" projects, though they've "always" charged for closed projects (um, yes:https://github.com/pricing) Google code is another possibility (https://code.google.com/u/103342639718054305536/) I don't like their organization as much (not "user" based?), but I like their bug tracker better. Eventually you end up with your "stuff" and your attention scattered all the hell over everywhere :-(

author: paulie
author_rank: Frequent Contributor
timestamp: October 13, 2014, 03:58:13 pm
content: Quote from: westfw on October 13, 2014, 09:08:13 amIt took me a while to figure it out because there were several slightly different versions on my hard drive but looks like this was the one I used for Harakiri flight controller. Probably because it's the only one with the 128k flash entry required by that. Looks like none of them used more than 8k RAM but in any case the correction to 20k is now included.BTW after your fixes the ISP version works fine for me now.

author: paulie
author_rank: Frequent Contributor
timestamp: October 13, 2014, 09:54:29 pm
content: I just got a request offline to "convert" westf's latest files. LOL. Doesn't anybody bother to keep up with latest posts?A. Westfw files don't need any converting now. They are already text format and compatible with page one schematic.B. For convenience have been reposted on page one. It's a good idea to check there once in a while because it's always being updated.I always test them myself before passing on to fellow $1 buddies.

author: neslekkim
author_rank: Super Contributor
timestamp: October 13, 2014, 09:59:02 pm
content: For convenience, the code should have been in Github or something.. lot easier to read the code along with the discussions here

author: paulie
author_rank: Frequent Contributor
timestamp: October 13, 2014, 10:30:24 pm
content: Maybe good for gurus but I guarantee that would not make it easier on the noobs who barely understand clicking on an attachment. Scattering files all over the internet will stop quite a few right there in their tracks. Here in the outside world I'm working with a bunch of guys who have hardware experience at best. Only one is more experienced than me and he agrees that code repositories are more of a cult than useful for casual projects like this.IMO keeping files in one place means the forum or whatever where the topic originated. Maybe not the Mikkelsen way (bet you thought I couldn't read backwards, LOL) but easier for those who dont speak git. I admit it's better than some of those repositories that are just weird and better now with the zip button but still...

author: westfw
author_rank: Super Contributor
timestamp: October 14, 2014, 05:35:32 am
content: I started:https://github.com/WestfW/Minimal-ARMComments welcome. I somewhat intend to flesh out the wiki with some content extracted from these threads. Eventually, and if I can figure out a good way to incorporate the sense of "forward progress" that you can get from a forum but tends to disappear in static documentation.One of the nice things about github is that you can browse the source code for something without committing to actually downloading anything.QuoteOh come on. We're talking about programming RISC microcontrollers in ASSEMBLER, in the absence of much support from either the vendors or the general community for doing so. Because we're masochistic old farts reliving our pasts, or something. This is not the place for someone who "barely understands clicking on an attachment"...

author: miguelvp
author_rank: Super Contributor
timestamp: October 14, 2014, 05:47:32 am
content: Where is westfwMacros.S?It's no where in the Git

author: westfw
author_rank: Super Contributor
timestamp: October 14, 2014, 05:57:39 am
content: QuoteI didn't write all the code in C; just the q_get and q_put functions. So it didn't get as far as a .elf file, though I can (and will) attached the .o and source.The C code looks like:Code:Disassembly of section .text.q_get:00000000 <q_get>:0: f890 3022 ldrb.w r3, [r0, #34] ; 0x224: b163 cbz r3, 20 <q_get+0x20>6: f890 2021 ldrb.w r2, [r0, #33] ; 0x21a: 3b01 subs r3, #1c: 1c51 adds r1, r2, #1e: 5c82 ldrb r2, [r0, r2]10: f001 011f and.w r1, r1, #3114: f880 3022 strb.w r3, [r0, #34] ; 0x2218: f880 1021 strb.w r1, [r0, #33] ; 0x211c: 4610 mov r0, r21e: 4770 bx lr20: f04f 30ff mov.w r0, #4294967295 ; 0xffffffff24: 4770 bx lr26: bf00 nopDisassembly of section .text.q_put:00000000 <q_put>:0: f890 3022 ldrb.w r3, [r0, #34] ; 0x224: b410 push {r4}6: 2b1f cmp r3, #318: d80a bhi.n 20 <q_put+0x20>a: f890 2020 ldrb.w r2, [r0, #32]e: 3301 adds r3, #110: 1c54 adds r4, r2, #112: f004 041f and.w r4, r4, #3116: f880 3022 strb.w r3, [r0, #34] ; 0x221a: 5481 strb r1, [r0, r2]1c: f880 4020 strb.w r4, [r0, #32]20: f85d 4b04 ldr.w r4, , #424: 4770 bx lr26: bf00 nopAnd that part of the assembler code looks like this:Code:0000001c <q_get>:1c: f891 0022 ldrb.w r0, [r1, #34] ; 0x2220: 0000 movs r0, r022: d00c beq.n 3e <qg_exit>24: b404 push {r2}26: 3801 subs r0, #128: f881 0022 strb.w r0, [r1, #34] ; 0x222c: f891 2021 ldrb.w r2, [r1, #33] ; 0x2130: 5c88 ldrb r0, [r1, r2]32: 3201 adds r2, #134: f002 021f and.w r2, r2, #3138: f881 2021 strb.w r2, [r1, #33] ; 0x213c: bc04 pop {r2}0000003e <qg_exit>:3e: 4770 bx lr00000040 <q_put>:40: b504 push {r2, lr}42: f891 2022 ldrb.w r2, [r1, #34] ; 0x2246: 2a20 cmp r2, #3248: da0a bge.n 60 <qp_exit>4a: 3201 adds r2, #14c: f881 2022 strb.w r2, [r1, #34] ; 0x2250: f891 2020 ldrb.w r2, [r1, #32]54: 5488 strb r0, [r1, r2]56: 3201 adds r2, #158: f002 021f and.w r2, r2, #315c: f881 2020 strb.w r2, [r1, #32]00000060 <qp_exit>:60: bd04 pop {r2, pc}The main differences are that I use the Z flag for return value in the assembler (which C can't do), and I preserve R0..R3 while the assembler preserves r4... (and lets r0..r3 be trashed.)

author: westfw
author_rank: Super Contributor
timestamp: October 14, 2014, 06:02:21 am
content: QuoteAdded. I thought I had eliminated it's use (it doesn't have much in it yet...)

author: paulie
author_rank: Frequent Contributor
timestamp: October 14, 2014, 09:07:29 am
content: Quote from: westfw on October 14, 2014, 05:35:32 amMaybe it's a "hardware" thing but for guys who know nothing about assembler or C the former was considered a breakthrough event for more than a couple members at the local ham radio club. They commented that "all that programming stuff" was mumbo jumbo but when the LED went on a few weeks back during my friends demo I could see their eyes light up and the light bulb above their heads too. Loading a value into a register and putting it out on a latch was a piece of cake compared to all those "symbols and curly cue stuff".I think what happens here is that once we go through the pain and barriers in understanding required for something like C programming we forget what it was like in those early days. Or maybe some peoples brains are prewired for it. In any case I have personally observed a real world situation where attempts were made first at introducing HLL to beginners and then the bare metal approach. One got nowhere and the other resulted in firing up interest, initially in a small handful, but now more than couple dozen "hardheads".There has been since some progress in re-introducing HLL concepts but I won't even bring up what happened when C++/OOP reared it's ugly head.

author: westfw
author_rank: Super Contributor
timestamp: October 14, 2014, 09:16:57 am
content: Ah. That's true. I had forgotten about the the "interesting subsets" of would-be microcontroller users: those that have a significant hardware design background, but little knowledge of software, and those that have a significant software background but little knowledge of electronics...

author: mrflibble
author_rank: Super Contributor
timestamp: October 14, 2014, 09:36:08 am
content: You can also look at it the other way. This way they get exposed to"how to press the pretty buttons to get code from remote repository to local directory". And before you know it they have their own local repo that they use for their own small projects. Thus helping them organize their own work better than they did in the past with 32485 zip files made at various points in time. Progress allround!Well, I can always hope.

author: paulie
author_rank: Frequent Contributor
timestamp: October 14, 2014, 11:46:15 am
content: We'll see how the noob set responds to git get when the next meeting comes up this weekend. Also it would be interesting to see how they respond to the concept of macros. Let's hope westfw will come up with another demo making use of that wonderful feature of GCC asm to show off his neglected macro file. Maybe combined with some new hardware trick like timers or DMA.

author: mrflibble
author_rank: Super Contributor
timestamp: October 14, 2014, 12:39:17 pm
content: Another idea for a feature to showcase use of assembler: saturating arithmetic. That has the advantage of actually being a borderline real life use case.Oh oh oh! Better yet, make a delta sigma modulator with the loop filter in asm and using dma to pump out the data. And I'm serious too.I actually did part of that (minus the dma) some time ago. And then after evaluation ditched the stm32f4 in favor of fpga because that way it was trivial to get good performance.At any rate, a tight asm based loop with saturating arithmetic is just about the poster child for using assembly. And those hams even get to show off the spectrum analyzer, because higher order delta-sigma modulated PWM displays a lower noise floor than straight up dithered pwm.

author: westfw
author_rank: Super Contributor
timestamp: October 14, 2014, 03:27:53 pm
content: "Saturated arithmetic" with or with without the M4 "dsp" instructions?None of the current "ghetto" systems (103 (M3), 003 (M0)) has the dsp add-on?

author: paulie
author_rank: Frequent Contributor
timestamp: October 14, 2014, 06:19:19 pm
content: Quote from: mrflibble on October 14, 2014, 12:39:17 pmAre you volunteering? If so remember that you may be putting westfw out of a job.

author: mrflibble
author_rank: Super Contributor
timestamp: October 14, 2014, 07:26:44 pm
content: Quote from: westfw on October 14, 2014, 03:27:53 pmYeah, some of the instructions usedI thinkrequired cortex-M3 or M4. I didn't really pay all that much attention to it at the time because there was no intention to port it to smaller devices. I see the M0 still has a MUL, but that will not be the goodness of the single cycle multiply-accumulates as found on the M3/M4.Anyways, all you have to do is write asm for a few years and then cortex-M3 will fit within the $1 requirement.Quote from: paulie on October 14, 2014, 06:19:19 pmFor the asm? Not really. I already evaluated it, and found that 1) for my requirements hand crafted asm did not have any real advantages over compiled C code, and 2) higher order (3 and above) delta sigma was a better fit for fpga's (spartan-6 in this case) than stm32f4's. You run out of registers so fast on those pesky MCUs.But for the delta-sigma part I may do a future write-up. Not sure if there's much interest in it around here.

author: paulie
author_rank: Frequent Contributor
timestamp: October 14, 2014, 10:08:09 pm
content: Quote from: mrflibble on October 14, 2014, 07:26:44 pmIf you wanna run outta registers real quick program STM8. Reminds me of the old 6502. Almost identical programming model.

author: miguelvp
author_rank: Super Contributor
timestamp: October 14, 2014, 10:26:05 pm
content: Two is more than plenty if you have an accumulator

author: westfw
author_rank: Super Contributor
timestamp: October 15, 2014, 01:24:45 am
content: BTW, a quick look on Mouser says that there are over 100 ARM microcontrollers that cost less than $2, in ones.From at least 5 vendors (SI Labs, ST, Freescale, NXP, Cypress.) Real prices for 1st line chips from a real distributor.Digikey has a similar list, and adds the Nuvoton chips...

author: bingo600
author_rank: Super Contributor
timestamp: October 15, 2014, 05:29:52 am
content: Quote from: mrflibble on October 14, 2014, 07:26:44 pmYes pleaseAnd if you release the Arm & FPGA source it would be an extra bonus.I'm a VHDL beginner , but hope to learn from it.Have a cheap ep2c45t144 board and a S3E starter , but hoped to use the Altera.Would like to test it for the EFC on a 10Mhz OCXO , where i would have used a dithered PWM as a DAC./Bingo

author: westfw
author_rank: Super Contributor
timestamp: October 15, 2014, 05:59:06 am
content: I don't know that I'm up to writing mathematical algorithms in assembler. I have to admit that when some cpu vendor says something like "we've added saturated multiple and accumulate instructions for DSP applications", I have trouble imagining what sort of algorithms they're supposed to help with. The earliest DSPs were just starting to appear when I graduated from college, but I spent my career pretty far away from "math"...

author: mrflibble
author_rank: Super Contributor
timestamp: October 15, 2014, 09:11:41 am
content: Quote from: miguelvp on October 14, 2014, 10:26:05 pmFor higher order modulators? Not if you want decent performance. Two is more than plenty if you are content with pushing and popping all the time. Actually two is barely adequate even then, because with just two registers you limit yourself to a rather suboptimal subset of instructions. But given yourat the end I guess you knew that.Then again, two is more than not nearly enough approaching barely adequate if you have several accumulators, I'll grant you that. Where "several" is equal to or greater than order of modulator.

author: mrflibble
author_rank: Super Contributor
timestamp: October 15, 2014, 09:28:33 am
content: Quote from: bingo600 on October 15, 2014, 05:29:52 amWell, it's in verilog, the testbench is in system verilog and I'm using Xilinx parts. But for the rest it's exactly as you wish.And amusingly enough this whole delta-sigma business started out as a simple PWM DAC. So then you dither it, but it's a bit noisey. And then you wonder "mmmh, well that's a bit noisy, isn't there a better way?". And then it's "mmmh, hey wait a minute, don't delta-sigma modulators shape the noise in pretty shapes?". And then before you know it you have a side project playing with delta-sigma thingies. And then and then and then your time went*poof*.

author: mrflibble
author_rank: Super Contributor
timestamp: October 15, 2014, 10:12:27 am
content: Quote from: westfw on October 15, 2014, 05:59:06 amWell, one use is in filters. If overflows would result in instability then you can use saturation arithmetic to help prevent that. You might get some nonlinearities, but better that than an outright oscillator.Anyways, for this case I found it to be easier to just use a model that was proven to be stable. Or rather, proven that a stable configuration exists. And then the actual probably-stable configuration is conjured up out of optimization, simulation and a"Yeah, that'll probably do"proclamation.For those interested, thedelsig toolboxreally helps with the above conjuration.I mostly concentrated on the CIFB topology, since I found that to be relatively easy to map onto both mcu and fpga. Of course on the mcu it's a big loop and on the fpga it's a pipeline, but you get the idea.

author: Brutte
author_rank: Frequent Contributor
timestamp: October 15, 2014, 03:11:43 pm
content: Quote from: paulie on October 13, 2014, 08:33:40 amThe gcc-arm-embedded toolchain is perfectly fine.If they say this ld is for a generic ARMv7M then that is exactly what they mean. Same applies to ld's for ARMv7A, R and qemu, also available there.If you want startup code, system init and linker scripts for your specific uC, you have to write/tweak your own ones or copy those three files from vendor's gcc examples. I suggest picking the former method for ld and startup (templatesfor various architectures available in gcc-arm-embedded toolchain) and the latter for system_init.

author: paulie
author_rank: Frequent Contributor
timestamp: October 15, 2014, 11:00:16 pm
content: This is bare metal assembler here so no startup or init code in any of the programs in post #1.Out of several thousand users of the original Basefight multicopter project only 2 or 3 actually got involved with the compile process. Everybody deals strictly with hex files there. Unlike the Arduino Multiwii it was ported from, the relatively hostile ARM toolsets are too big a jump. Not being the brightest bulb on the Christmas tree I decided to give compiling a go myself. There was virtually zero support so I copied the LD file from a C blinky template. No luck with Baseflight so I moved on to Harakiri changing the 64k to 128k. No luck with Harakiri either so ARM toys were shelved for couple months until the Ham club demo.The STM32.LD worked fine for all the programs here unitl westfw decided to chew up all the RAM for vectors and who knows what else. This uncovered the error. Changing the 8k to 20k fixed that so until something actually stops working this is the script for now,

author: paulie
author_rank: Frequent Contributor
timestamp: October 16, 2014, 02:39:53 pm
content: Based on a request for a register symbol table for STM8 asm I've attached a .H file to the page one post. It's derived from the ST programmers reference document so should be accurate. I only spend a few minutes on it so be careful. The C compiler one from reply slot #5 had several incorrect addresses. I only fixed the ones needed for my C demo to work so might be a good idea to redo that from this asm version since it's more dependable.ps. Here's a snippet showing some of the more useful entries:Code:;stm8.h from DM00024550.pdfPD_ODR equ $500F ;Port D data output latch register 0x00PD_IDR equ $5010 ;Port D input pin value register 0xXX(1)PD_DDR equ $5011 ;Port D data direction register 0x00PD_CR1 equ $5012 ;Port D control register 1 0x02PD_CR2 equ $5013 ;Port D control register 2 0x00...UART1_SR equ $5230 ;UART1 status register 0xC0UART1_DR equ $5231 ;UART1 data register 0xXXUART1_BRR1 equ $5232 ;UART1 baud rate register 1 0x00UART1_BRR2 equ $5233 ;UART1 baud rate register 2 0x00UART1_CR1 equ $5234 ;UART1 control register 1 0x00UART1_CR2 equ $5235 ;UART1 control register 2 0x00UART1_CR3 equ $5236 ;UART1 control register 3 0x00...CLK_SWR equ $50C4 ;Clock master switch register 0xE1CLK_SWCR equ $50C5 ;Clock switch control register 0xXXCLK_CKDIVR equ $50C6 ;Clock divider register 0x18CLK_PCKENR1 equ $50C7 ;Peripheral clock gating register 1 0xFF...ADC_DB1R equ $53E0 ;ADC data buffer registers 0x00ADC_DB2R equ $53E1 ;ADC data buffer registers 0x00ADC_DB3R equ $53E2 ;ADC data buffer registers 0x00ADC_CSR equ $5400 ;ADC control/status register 0x00ADC_CR1 equ $5401 ;ADC configuration register 1 0x00ADC_CR2 equ $5402 ;ADC configuration register 2 0x00...

author: paulie
author_rank: Frequent Contributor
timestamp: October 19, 2014, 09:21:37 pm
content: Another productivity enhancement. A new A.BAT is upload to the second post that not only compiles but automatically flashes and runs the user program with a single key. In recent benchmark tests this method was found to be several times faster developing code than a couple of the common graphic IDE environments.Here's a peek:Code:arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.sif errorlevel 1 goto badarm-none-eabi-ld -Map t.map -T stm32.ld -o t.elf t.oif errorlevel 1 goto badarm-none-eabi-objdump -d t.elf > t.lstarm-none-eabi-objcopy -O ihex t.elf t.hex\stmflash\stmflashloader -c --pn 5 -Dtr --Hi -i STM32_Med-density_64K -e --all -d --fn t.hex -r --a 0x8000000:bad

author: paulie
author_rank: Frequent Contributor
timestamp: October 22, 2014, 05:42:35 pm
content: I came up with a small imrovement to the batch file that allowed me to win the "STM32 CLI/GUI Smackdown" last weekend (actually easy because only one other guy besides me champions cli, LOL). Moving the DTR command outside to a separate line eliminates the need for Arduino type circuit or hitting reset to download again. Also note the BOOT/RUN and reset switches are no longer required. Cuts a few seconds off the edit/assemble/run loop. That works with C too. Here's the secret to share now that the competition is over:Code:arm-none-eabi-as -mcpu=cortex-m3 -o t.o t.sif errorlevel 1 goto badarm-none-eabi-ld -Map t.map -T stm32.ld -o t.elf t.oif errorlevel 1 goto badarm-none-eabi-objdump -d t.elf > t.lstarm-none-eabi-objcopy -O ihex t.elf t.hex\stmflash\stmflashloader -c --pn 5 -Dtr --Hi\stmflash\stmflashloader -c --pn 5 -i STM32_Med-density_64K -e --all -d --fn t.hex -r --a 0x8000000:badps. In case I forgot to mention it in the other post you do need to connect DTR from the USB/serial dongle to pin 7 (nrst) and also put your own port number in place of the "5".

author: westfw
author_rank: Super Contributor
timestamp: October 22, 2014, 11:52:57 pm
content: QuoteWait... What did you do? I've been hating the boot sequence on my board (set BOOT0, reset, download, unset BOOT0, reset again), but I've been resigned. Don't you need at least two additional connections from the serial port to do some sort of auto-reset?

author: paulie
author_rank: Frequent Contributor
timestamp: October 24, 2014, 04:12:22 am
content: At least one additional serial connection: DTR. As shown in the photos from page one BOOT0 stays jumpered. The point is it's not necessary to poke at the target board every time anymore. Because of rare but possible bootloader initialization and I/O state dependencies it is a good idea to disconnect all development cables and test it stand alone before calling it ready for prime time.

author: Brutte
author_rank: Frequent Contributor
timestamp: October 24, 2014, 05:45:41 am
content: Quote from: paulie on October 19, 2014, 09:21:37 pmWith mySplitCodewhole [recompile+program+start debugging] cycle lasts under 3 seconds and that timing does not depend on the application size much (similar timings for development of 1kB or 1MB application).With single click, under Eclipse, of course.

author: westfw
author_rank: Super Contributor
timestamp: October 28, 2014, 07:16:51 am
content: BTW, it's come to my attention that the Leaflabs "Maple" board (one of the first attempts an an ARM-based Arduino compatible) was based on the STM32f103, and in fact some of the cheap 103 boards you can buy are "Maple Mini" clones.It looks like the Maple software effort has been largely abandoned, but combining their last efforts with the new Arduino IDE framework (which is more flexible WRT upload/compile/etc scripting) should be possible, giving one the ability to run many Arduino sketches on arbitrarily simple STM32f103 boards.Efforts in that direction might be more worthwhile than continued work on assembler stuff...

author: paulie
author_rank: Frequent Contributor
timestamp: October 29, 2014, 05:52:16 pm
content: Truly an excellent idea. The asm does get old quickly for serious development. Strangely Maple boards are even cheaper than the Ebay "blue" boards but 103cb chips cost several times more 103c8. Since these two chips are drop in identical except for ID porting libraries should be trivial. Unfortunately Maplelabs appears to have abandoned Wintel development in favor of Linux/Mac which effectively relegates this to laboratory curiosity status.I do have one of the Maplemini clones and as soon as you finish off your One Minute PC version I'm certainly on board.

author: paulie
author_rank: Frequent Contributor
timestamp: November 04, 2014, 11:34:18 am
content: So i gave Maple's development package a try with less than promising results. I do have a genuine Maplemini but couldn't get it to work at all. I wonder if anybody has ever succeeded in installing or running the blinky?

author: westfw
author_rank: Super Contributor
timestamp: December 08, 2014, 02:06:27 am
content: BTW, I've managed to make a "pruned" version of the gcc toolset from launchpad.net that is "only" a ~16MB download.(no C++, no tlo, no cortex-A libraries. no FPU support, etc.) It still needs some work to include the ST includes and startup code, and it's about 8x larger than Paulie's asm-only set of tools, but it's not so bad for a full C compiler.

author: paulie
author_rank: Frequent Contributor
timestamp: December 09, 2014, 03:48:28 am
content: Oh my. 16 megabytes is a far cry from the hundreds for the standard package. That certainly sounds like it qualifies as minimum development and yet a serious tool. Maybe big competition for SDCC which I lament not being available for any of the ARMs. Please report and hopefully provide links when up an running.

author: poorchava
author_rank: Super Contributor
timestamp: December 09, 2014, 06:57:56 am
content: Quote from: westfw on October 15, 2014, 05:59:06 amDSP instructions often help with "everyday" math being done on microcontroller, but I find that in most cases you need to go to at least -o2 for the compiler to make all the obvious conversions. For example a good compiler can convert a long array access loop into smaller number of SIMD instructions. Another thing is, that a typical Cortex-M4F is still shit compared to a "real" dsp processor with multiple ALU's, heardware loop logic, multiple adress registers, multiple memory busses, 64 bit SIMD engines and so on. A simple example is a standard 2048pt 32-bit fixed point real FFT (quite a frequently used case). My CM4 running at 120MHz executes FFT in about 2.5-3ms using CMSIS-DSP lib. The same operation on some smaller TI Piccolo processor takes some microseconds.

author: Marco
author_rank: Super Contributor
timestamp: December 09, 2014, 08:54:16 am
content: 2048 point fft in some microseconds on a microcontroller dsp hybrid, that doesn't sound right.

author: poorchava
author_rank: Super Contributor
timestamp: December 09, 2014, 01:10:07 pm
content: Ok, perhaps it wasn't piccolo, my bad. Anyway i it was some low model from TMS320 family, C54 or C55 I think.

author: Marco
author_rank: Super Contributor
timestamp: December 09, 2014, 03:48:25 pm
content: Still doesn't sound right, I will agree though ... the lack of zero overhead looping and the combination of single issue with a load/store architecture makes Cortex-M4 poorly suited suited for DSP. You can code around most of it, but it takes a lot more effort.It's a shame TI is the only one doing anything with Piccolo, it was a far better DSP architecture than what we get on all these other ARM micros.

author: paulie
author_rank: Frequent Contributor
timestamp: December 16, 2014, 09:32:39 pm
content: Quote from: paulie on November 04, 2014, 11:34:18 amOk... nobody else in the world seems to have got that running so here's an update from yours truly. SUCCESS! Not with the original Maple package which appears to be a total flop but from a team of hotshots that ported STM32f103 over to Arduino. Unbelievably easy to program, unbelievably powerful/flexible, and... that's right... unbelievably cheap. Fully assembled STMF103 boards with next chip up from the Ebay or DIY versions but less than $4 shipped.I've been playing around with not only Blinky, but SD card and RF demos. As usual with Arduino they just up and run first try. With 1.5.8 installed it really does take less than a minute to setup and go.ps. If there's interest I'll put up some links and photos.

author: gibbled
author_rank: Regular Contributor
timestamp: December 17, 2014, 06:03:16 pm
content: I'm interested Paulie...

author: paulie
author_rank: Frequent Contributor
timestamp: December 17, 2014, 07:34:40 pm
content: Heh.. For a minute there I though it was just the three of us (me, myself, and I). IMO this is the biggest deal to come along in a long time. Right now ARM is one of the hottest topics on this and just about every other MCU forum. All it needs is for somebody to tame it with something like Arduino. Eclipse and the other "professional" toolsets are really not for beginners. Disliked by many professionals too.Anyway here's the fellow who managed to take it out of Mapleleafs hands when they dropped the ball and polish it into something useful to beginners and experienced alike:http://www.rogerclark.net/stm32f103-and-maple-maple-mini-with-arduino-1-5-x-ide/There are some more links to put up when I get a chance but that one strikes me as most complete and easy to follow (I don't believe it, two well done websites in one week). I'll take some photos of my own setup too. Did I mention this works great on the $1 DIY board?

author: Rasz
author_rank: Super Contributor
timestamp: December 18, 2014, 03:23:54 pm
content: I heard herethat maple labs is not interested in low margin boards, and wont work on cheap stm32 stuff anymore

author: paulie
author_rank: Frequent Contributor
timestamp: December 18, 2014, 07:59:13 pm
content: Actually it was very high margin product when they were getting $40 each. Naturally chinese IP thieves jumped on that and started cranking them our for a tenth the cost. THEN they sorta lost interest. Kinda like what happened with Arduino company. Deja vu all over again.

author: westfw
author_rank: Super Contributor
timestamp: December 19, 2014, 03:36:38 am
content: So... you realize that most of what Roger has done is to get the Arduino High level libraries (SPI, I2C, etc) up-to-date (1.x based APIs rather than 00xx based)? I thought you didn't approve of such high-level coding :-)"Maple" was the first attempt at porting the Arduino environment to a different chip, done back when official support was pretty much AVR m8/m168 only. They didn't to a great job at figuring out how to do that, and the subsequent arduino modifications happened in incompatible ways, but I'm not sure "dropped the ball" is a fair condemnation. I'm pretty happy with their "exit strategy"; the HW designs, SW efforts, and a bunch of "documentation" stayed open source, and was invaluable in the current attempts to reinstate support.QuoteThat's true; leaflabs says as much:http://leaf-labs.squarespace.com/about-maple/It's largely irrelevant; as this thread has postulated from the beginning, there is now LOTS of cheap ST32F hardware out there, and Rogers current efforts are a good starting point to having a lot of it work under the Arduino environment. (It's ALSO one of the first efforts to add a third-party package to the new multiplatform 1.5.x Arduino framework, which is IMO pretty important completely separately from the ST connection.)

author: paulie
author_rank: Frequent Contributor
timestamp: December 20, 2014, 02:18:16 pm
content: Quote from: westfw on December 19, 2014, 03:36:38 amHaHa... The truth is I'm a huge fan of HLL. Particularly compilers like Microchip C and Winavr because they are compact and efficient. Specially the earlier versions. But it's true I do like the assemblers for those and use them a lot. SDCC has taken my fancy lately too. In addition to the STM8 it motivated me to dust off some old CPM boards and an AVR Z80 emulator.It's laughable to see how infatuated some people are with HLL. Multi-page programs (OOPS is right!) and kbytes or even megabytes to toggle a bit instead of half dozen bytes of clean code. BLOATWARE? For some reason not so thrilling.Arduino was not a favorite either until recently seeing what can be done to ease the pain of ARM programming.

author: zapta
author_rank: Super Contributor
timestamp: December 20, 2014, 03:51:46 pm
content: Quote from: paulie on October 14, 2014, 11:46:15 amGit also provides a link to download the repository as a zip file. May me easier than having to deal with the git client.

author: fortran77
author_rank: Newbie
timestamp: March 08, 2016, 07:39:15 pm
content: Thanks for this thread. I'm trying FASMARM and this is one of the few places I've found any assembly examples for STM32F103.Took me about a minute to download the assembler.I include my pin-scanner those cheap chinese boards really need one, out of 2 cpu cards 3 pins were not in contact with their pads.Forgot to tell it's also setting up timer1 for 72MHz pwm outputs on pin A8-A11 also some other code in there.BTW this is not my normal alias but I thought the year of my first language would be nice here!Also any help with updating the register include file would be appreciated.

author: westfw
author_rank: Super Contributor
timestamp: March 13, 2016, 12:51:50 am
content: QuoteDo you understand EMACS?Three EMACS keyboards macros (included at the end of the .asmh file) are iterated over a merged .h file, to accomplish:1) Convert "#define X Y" to ".equiv X, Y"2) Convert "typedef struct { stuff } foo_t;" to "STRUCTDEF foo / stuff / ENDSTRUCT3) Covert arrays like "uint32_t dummy;" (inside the structs) to "uint32_ta dummy, n"Note that a bunch of "normal" C keywords (like "uint8_t") are redefined as gnu-as macros, which greatly reduces the the amount and complexity of the work that the editor macros have to do.Also note that the process is very specific to the way that ST structures their files. I've come across other vendors that have separate files for each peripheral, and nested structures/unions/etc. It would take a lot of changes to similarly pre-process those files for use as gnu-as use. :-(It might be possible to come up with a set of sed scripts that do the same thing. They'd be equally incomprehensible to read, but easier to run.

author: westfw
author_rank: Super Contributor
timestamp: June 23, 2016, 11:50:49 pm
content: I've added an assembler/bare-metal "blink" example for the Atmel SAMD10 Xplained Mini board.It's designed to be opened in Atmel Studio, and demonstrates a way to set up an assembler project in AS, as well as being a trivial SAMD10 demo. (Atmel Studio is NOT a "lightweight development environment", though!)Observation: Cortex M0 is annoying. While "nominally" just another ARM variant, the three-instruction delay loop that I had implemented for CM3 had EVERY instruction rejected as invalid on the CM0. :-(Code:mov r1, #(4*1024*1024) // Constant is too large for thumb16// (doesn't allow shift during mov)delay:subs r1, #1 // doesn't like "subs" (wants "sub"// (even though the listing shows subs !)bne.n delay // Doesn't like ".n" (all thumb16 branches are "near"?)// (again, the listing shows "bne.n"...)All the constants in the Atmel .h files have trailing "U" designators, even in the "#ifdef __ASSEMBLY__" parts. Grr.(Crap like this is one of the things that make assembly programming increasingly unpleasant.)https://github.com/WestfW/Minimal-ARM/blob/master/Atmel/samd10asmBlink/samd10asmBlink/main.S