If you are a newb, using "simplified" / "opaque" libraries that hide all the scary code from you are a sure way to make sure you'll never learn what's really going on with embedded programming.
I couldn't agree more.
I wrote all libraries myself (SPI, I2C, UART, FAT32, SD-card).
For me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...
Fantastic work - I can hardly believe it! I have just completed the following:
•Uploaded your bitstream to the Pepino
•Connected an HMC6352 I2C Compass chip to the Pepino
•Modified two Oberon source code files to port the code from ARM Cortex-M3 to RISC5 using your I2C register addresses.
•Fixed a number of compilation errors
•Uploaded the compiled modules to the Pepino
•Executed the application
and it worked first time!!!!!
Not only that, the whole process only took 40 minutes from start to finish...
_________________
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5
"Code size limited to 128K bytes of flash"
https://imagecraft.com/index.php?option=com_opencart&Itemid=148&route=product/product&product_id=55
Is it a commercial decision ?
QuoteFor me, the limit is USB and TCP/IP. For that we use Linux.
I prefer to deal with my own bugs instead of the ones made by others...
Do you write your own Linux?
No need to write my own Linux. The average code quality of Linux kernel is much better than
what STM (or Microchip & Atmel for that matter) provides.
Linux has a tremendous amount of bugs,
Code review! This is ONE function from stm32f1xx_hal_uart.c (v1.0.1, July 2015)
My comments preceded by the triple-semicolons: ";;;"Code: [Select]if(huart->Init.WordLength == UART_WORDLENGTH_9B)
{...}
else /* is 8 bit data - 8 bit no parity OR 7 plus parity */
{
if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_RXNE, RESET, Timeout) != HAL_OK)
return HAL_TIMEOUT;
if(huart->Init.Parity == UART_PARITY_NONE)
*pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x00FF);
else
{
*pData++ = (uint8_t)(huart->Instance->DR & (uint8_t)0x007F);
;;; This is OK for 7 databits + parity, and in fact is necessary since the
;;; UART hardware is documented as leaving the parity bit in DR instead
;;; of stripping it as with many other UARTs.
;;; However, this seems like it's substantially broken for any word size
;;; OTHER than 7 bits. 8 databits+parity will only return 7bits to the user,
;;; databits less than 7 will fail to strip the parity bit.
}
}
When transmitting with the parity enabled (PCE bit set to 1 in the USART_CR1 register),
the value written in the MSB (bit 7 or bit 8 depending on the data length) has no effect
because it is replaced by the parity.
When receiving with the parity enabled, the value read in the MSB bit is the received parity
bit.
You don't have to agree with the compromise they made but you have to appreciate the compromise they made.
With Oberon you not only can work at the "bare metal" but you can literally carve the metal yourself, if you like, just like Magnus has done here:
How is this not the OPPOSITE of 'obscure'? Where do you see any code being hidden behind 'unknowns?
the STM32F1 UART only supports 8 or 9 bit data. If you enable parity it replaces bit 7 or 8 with the parity. You don't have the options of 9 bit + parity or 7 bit no parity.
I feel that this thread has spawned many arms and approaching thread-death ;-P
I feel that this thread has spawned many arms and approaching thread-death ;-P
Bob, how about addressing my last post? What's YOUR contribution to solving the "ST's terrible ecosystem problem"? I see westfw putting out some code on public domain. Danny is writing some blog with code examples, and you...?
We all welcome your contributions to this topic, Richard, but I'll echo what Bob said: Please tone down the commercial for your product. It's getting a little overripe in the sun.
With layering, I can write code that is almost entirely hardware dependent - for someone who sells code that runs on user-specified hardware, that's a must.
What requirements would a ideal HAL have to meet?