the stm32l discovery board

[catamphetamine]

Hello.
I didn't find a "send a message" button so I'm creating an "issue".
I'm currently studying your STM32 book and bought (a while ago) an stm32ldiscovery board as opposed to stm32vldiscovery board.
What do you think should I do: will it be better for me to try to adopt your template for my stm32l microprocessor or should I order an stm32vldiscovery?

[geoffreymbrown]

Unless you have a pretty good idea already how this works, you'd be better
off with the vl board.
Geoffrey

On Wednesday, December 10, 2014, Nikolay Kuchumov notifications@github.com
wrote:

Hello.
I didn't find a "send a message" button so I'm creating an "issue".
I'm currently studying your STM32 book and bought (a while ago) an
stm32ldiscovery board as opposed to stm32vldiscovery board.
What do you think should I do: will it be better for me to try to adopt
your template for my stm32l microprocessor or should I order an
stm32vldiscovery?

—
Reply to this email directly or view it on GitHub
#5.

[catamphetamine]

ok, thanks, I'll order one from digikey

[catamphetamine]

Hello Geoffrey.
I'm reading your book once again, chapter 4 now, and my program halts as soon as I stop my GDB debugging session (i use eclipse).
Do you have any idea why is that?
I mean, in the "Debug perspective", i click that red stop button, and the LED isn't blinking anymore because the program just freezes.

[geoffreymbrown]

When you stop the GDB session, what happens if you push the reset button on
the board ? Perhaps with a more detailed explanation of the procedure
you are following, I can help you find the problem. Something like --

1. connect board to USB
2. start st-util
   ....

Geoffrey

On Sun, May 29, 2016 at 8:54 AM, Nikolay notifications@github.com wrote:

Hello Geoffrey.
I'm reading your book once again, chapter 4 now, and my program halts as
soon as I stop my GDB debugging session (i use eclipse).
Do you have any idea why is that?
I mean, in the "Debug perspective", i click that red stop button, and the
LED isn't blinking anymore because the program just freezes.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABq_UiD1saJUC_laWImp3T8R8elNrTM2ks5qGYyWgaJpZM4DG5aJ
.

[catamphetamine]

Wow, really, the black RESET button does the trick and the program is running again.
Thanks!
Now I can take it to my work and brag about blinking an LED : )

[catamphetamine]

Oh, by the way, I downloaded your book on the internets somewhere.
For free, of course.
I guess this thing is supposed to be sold.
Can I donate a few bucks to your paypal account maybe?

[geoffreymbrown]

No need for payment -- I intended it to be free. Make sure you have the
latest copy

http://www.cs.indiana.edu/~geobrown/book.pdf

Geoffrey

On Sun, May 29, 2016 at 9:08 AM, Nikolay notifications@github.com wrote:

Oh, by the way, I downloaded your book on the internets somewhere.
For free, of course.
I guess this thing is supposed to be sold.
Can I donate a few bucks to your paypal account maybe?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABq_UokKhTS3nD-L9B5mTiVtlB0DdXwzks5qGY_GgaJpZM4DG5aJ
.

[catamphetamine]

Hello Geoffrey, I found a small typo in your book on page 80:

// Initialize USART1_Tx
GPIO_InitStruct.GPIO_PIN = GPIO_Pin_9;

It should be GPIO_Pin instead.
Had to google it for a bit of time, because "Why can't it find "gpio_pin" when it clearly reads "gpio_pin" inside the .h file"

[geoffreymbrown]

Thank you ! It's always the bits that aren't directly input from the code
repository that cause problems. In any case it's fixed now>

Geoffrey

On Sun, Jun 5, 2016 at 3:33 PM, Nikolay notifications@github.com wrote:

Hello Geoffrey, I found a small typo in your book on page 80:

// Initialize USART1_Tx
GPIO_InitStruct.GPIO_PIN = GPIO_Pin_9;

It should be GPIO_Pin instead.
Had to google it for a bit, because "Why can't it find "gpio_pin" when it
clearly reads "gpio_pin" inside the .h file"

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABq_UiX8hm80-037VdJPqW0SO8QIpLNEks5qIyRzgaJpZM4DG5aJ
.

[catamphetamine]

I like the way your book rolls by the way.
Usually it's like "Here's the listing, just copy & paste and run it", "Yeah, whatever".
And this book really isn't gonna give you off anything that easy, it makes you use that brain of yours.

[catamphetamine]

I tried to do the exercise 5.3 Echo but I don't understand how to write to the USB UART.
screen command works as expected and echoes my input.
But how do you send data without screen?
I googled this answer:
http://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer
And they tell to use echo.
But there's no data being received on the RX and it's stuck in the while loop waiting for data

while (USART_GetFlagStatus(USART1, USART_FLAG_RXNE) == RESET);

echo commands simply "freeze" and nothing happens, i.e. echo command doesn't exit (unless manually interrupted).
If you did encounter this specific issue then maybe you could give me a hint.
Otherwise it may be my OS not working or something else (I'm on OS X hackintosh)

[geoffreymbrown]

In unix like systems, tty's are a bit problematical. You could open the
port (/dev/tty.xxx) as a file
and read/write to it with a program. Here's a bit of code that opens a
tty in "raw" mode. If you do this in a program, then you can treat it
like a normal file. I don't think it works to just cat stuff to the
/dev/tty.xxx file.

Geoffrey

int fd = open(argv[1], O_RDWR | O_NDELAY | O_NOCTTY);

if (fd == -1){

  perror("can't open device");

  fprintf(stderr,"%s\n", argv[1]);

  exit(errno);

}

if (fcntl(fd, F_SETFL, 0) < 0) {

printf("Error clearing O_NONBLOCK\n");

exit(errno);

}

struct termios config, orig_config;

if (tcgetattr(fd, &config) < 0) {

  perror("can't get serial attributes");

  exit(errno);

}

cfmakeraw(&config);

config.c_cc[VMIN] = 1;

config.c_cc[VTIME] = 10;

config.c_cflag |= CLOCAL | CREAD;

if (tcsetattr(fd, TCSANOW, &config) < 0) {

  perror("can't set serial attributes");

  exit(errno);

On Sun, Jun 5, 2016 at 6:25 PM, Nikolay notifications@github.com wrote:

I tried to do the exercise 5.3 Echo but I don't understand how to write to
the USB UART.
screen command works as expected and echoes my input.
But how do you send data without screen?
I googled this answer:

http://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer
But there's no data being received on the RX and it's stuck in the while
loop waiting for data

while (USART_GetFlagStatus(USART1, USART_FLAG_RXNE) == RESET);

echo commands simply "freeze" and nothing happens, i.e. echo command
doesn't exit (unless manually interrupted).
If you did encounter this specific issue then maybe you could give me a
hint.
Otherwise it may be my OS not working or something else (I'm on OS X
hackintosh)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABq_UiiqLwy0rtSpTRahA8AjEK-a5yZpks5qI0zDgaJpZM4DG5aJ
.

[catamphetamine]

Ok, thanks for the tip.
Really, Unixes seem to work with ttys another way than Linuxes (didn't think of that).

http://stackoverflow.com/questions/18821811/serial-port-hangs

The technical difference is that /dev/tty.* devices will wait (or listen) for DCD (data-carrier-detect), eg, someone calling in, before responding. /dev/cu.* devices do not assert DCD, so they will always connect (respond or succeed) immediately.

Anyway, I found a hacky solution which let me finish the exercise

foo=$1
for (( i=0; i<${#foo}; i++ )); do
  echo "${foo:$i:1}" > /dev/cu.SLAB_USBtoUART
done

echo "\r"  > /dev/cu.SLAB_USBtoUART

sh echo.sh Testing

(just in case anyone comes here resolving the same issues which is unlikely)

[geoffreymbrown]

Thanks, that's a new approach for me.

Geoffrey

On Sun, Jun 5, 2016 at 7:40 PM, Nikolay notifications@github.com wrote:

Ok, thanks for the tip.
Really, Unixes seem to work with ttys another way than Linuxes (didn't
think of that).

http://stackoverflow.com/questions/18821811/serial-port-hangs

The technical difference is that /dev/tty.* devices will wait (or listen) for DCD (data-carrier-detect), eg, someone calling in, before responding. /dev/cu.* devices do not assert DCD, so they will always connect (respond or succeed) immediately.

Anyway, I found a hacky solution which let me finish the exercise

foo=$1
for (( i=0; i<${#foo}; i++ )); do
echo "${foo:$i:1}" > /dev/cu.SLAB_USBtoUART
done

echo "\r" > /dev/cu.SLAB_USBtoUART

sh echo.sh Testing

(just in case anyone comes here resolving the same issues which is
unlikely)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABq_UiT-7RwC8WqpWL_T7yaFrL7CbL9sks5qI159gaJpZM4DG5aJ
.