Author Topic: One Dollar One Minute ARM Development  (Read 135586 times)

0 Members and 1 Guest are viewing this topic.

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #175 on: September 19, 2014, 06:16:37 pm »
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.

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #176 on: September 20, 2014, 01:55:28 am »
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.)
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #177 on: September 20, 2014, 04:44:17 pm »
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.
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #178 on: September 20, 2014, 09:28:29 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #179 on: September 21, 2014, 07:51:18 am »
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: [Select]
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 lr
ldr r0, =RCC_BASE
ldr 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_USART1EN
str r1, [r0, #RCC_APB2ENR]
ldr r1, [r0, #RCC_APB2RSTR]
orr r1,r2, #RCC_APB2RSTR_USART1RST
bic r1, #RCC_APB2RSTR_USART1RST
str r2, [r0, #RCC_APB2RSTR] /* Reset the UART */
nop
nop
str r1, [r0, #RCC_APB2RSTR] /* Un-reset */
nop
nop

/*
 * 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_BASE
ldr r1, =F_CPU/115200
str.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 lr

And 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: [Select]
   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: [Select]
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.)

 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #180 on: September 21, 2014, 01:02:40 pm »
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!
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: One Dollar One Minute ARM Development
« Reply #181 on: September 21, 2014, 03:03:01 pm »
Actually I have to agree that .h files are no place for C code.

The 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.
« Last Edit: September 21, 2014, 03:04:44 pm by Marco »
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #182 on: September 21, 2014, 06:47:29 pm »
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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #183 on: September 21, 2014, 09:25:51 pm »
Quote
I finally did get the UART working
Could 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: [Select]
static const debugbits = 0;

  if (debugbits & DEBUG_PRINTCHARS) {
    // blah blah
  }
will normally compile to nothing just as well as
Code: [Select]
#if DEBUG_PRINTCHARS
   // blah blah
#endif
but 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...
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #184 on: September 22, 2014, 05:47:31 am »
Arrrgghhh!  I'm an idiot...
Code: [Select]
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 lr
ldr r0, =RCC_BASE
ldr 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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #185 on: September 22, 2014, 07:34:27 am »
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 :-(

 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #186 on: September 22, 2014, 01:38:30 pm »
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,
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #187 on: September 23, 2014, 02:22:02 am »
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.

 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #188 on: September 23, 2014, 08:38:33 am »
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_gas  In case you want to do things like
Code: [Select]
NESTIFTEST:             
        cmp r0, 12
        _if e
          mov r0, #5
          cmp r1, #13
          _if cs
            eor r2, r2
          _else
            add r2, r2
          _endif
          mov r4, #123
        _endif
       
        adds r0, r4
        _if eq
           add  r2,#1
        _else
           add  r2,#2
        _endif
It 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.)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #189 on: September 23, 2014, 09:57:26 am »
Quote
I'll see if I can extract an example [of how the peripheral library looks like it was designed to be inlined.]
Here we go.  I wrote a tiny little program to initialize the USART using the ST peripheral library:
Code: [Select]
static USART_InitTypeDef myuartconfig = {
    115200, // Baudrate
    USART_WordLength_8b, // Wordlength
    USART_StopBits_2, // StopBits
    USART_Parity_No, // Parity
    USART_Mode_Rx + USART_Mode_Tx, // Mode
    USART_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: [Select]
/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.out
   text    data     bss     dec     hex filename
   2816    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.out
   text    data     bss     dec     hex filename
   2512    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.")
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: One Dollar One Minute ARM Development
« Reply #190 on: September 23, 2014, 08:19:21 pm »
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 a better way, but whatever.)
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #191 on: September 23, 2014, 10:28:23 pm »
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: [Select]
;;; 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.c
BillW-MacOSX-2<10079> /usr/local/armgcc/bin/arm-none-eabi-size a.out
   text    data     bss     dec     hex filename
    596      36       0     632     278 a.out

BillW-MacOSX-2<10088> /usr/local/armgcc/bin/arm-none-eabi-nm -S a.out |grep " T "
000080d0 00000018 T RCC_APB1PeriphResetCmd
000080b8 00000018 T RCC_APB2PeriphResetCmd
00008024 00000094 T RCC_GetClocksFreq
000080e8 000000b0 T USART_DeInit
00008198 000000bc T USART_Init
0000801c 00000006 T _start
00008000 0000001c T main

;;; inline functions
BillW-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.c
BillW-MacOSX-2<10081> /usr/local/armgcc/bin/arm-none-eabi-size a.out
   text    data     bss     dec     hex filename
    356      36       0     392     188 a.out

BillW-MacOSX-2<10090> /usr/local/armgcc/bin/arm-none-eabi-nm -S a.out |grep " T "
000080c8 00000094 T RCC_GetClocksFreq
0000815c 00000006 T _start
00008000 000000c8 T main
Note 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...

 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #192 on: September 24, 2014, 07:21:41 am »
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.
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #193 on: September 24, 2014, 07:48:52 am »
Just finished building a monster dev board of my own, so I'm about to dive into ARM head-first.

Thanks 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?
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #194 on: September 24, 2014, 09:22:34 am »
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.

Quote
Could you provide a bit more detail on the setup?
Sure.  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: [Select]
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: [Select]
/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.
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #195 on: September 24, 2014, 02:51:02 pm »
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.
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: One Dollar One Minute ARM Development
« Reply #196 on: September 24, 2014, 08:00:14 pm »
Thanks 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?

I 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.)
« Last Edit: September 24, 2014, 08:17:21 pm by SirNick »
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #197 on: September 26, 2014, 09:44:01 am »
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.

I 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?
 

Offline SirNick

  • Frequent Contributor
  • **
  • Posts: 589
Re: One Dollar One Minute ARM Development
« Reply #198 on: September 26, 2014, 10:16:56 pm »
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/
 

Offline paulieTopic starter

  • Frequent Contributor
  • **
  • !
  • Posts: 849
  • Country: us
Re: One Dollar One Minute ARM Development
« Reply #199 on: September 27, 2014, 05:35:49 pm »
I don't see the F103 as much superior in every respect, nor do I even see them costing less.
...
F030's for $0.70, yes.

You 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf