We have been working on a project to get e-paper displays work with Raspberry Pi Pico board. We already managed to get everything working with ESP8266-board, but for power consuming reasons we would like to use Pico. E-paper display what we use is Waveshare 2.9" SPI.
We are trying to use this library: https://github.com/ZinggJM/GxEPD2
It works well with ESP8266, has someone managed to get it working also with Raspberry Pi Pico, and if so, could you provide any tips to get it working with Pico? Please find attached error message what we receive.
This is error message That I get:
Arduino: 1.8.13 (Windows 10), Board: "Raspberry Pi Pico, Serial, None"
C:\Users\ \Documents\Arduino\libraries\GxEPD2\src\GxEPD2_EPD.cpp:17:10: fatal error: pgmspace.h: No such file or directory
17 | #include <pgmspace.h>
| ^~~~~~~~~~~~
compilation terminated.
exit status 1
Error compiling for board Raspberry Pi Pico.
Lines below from this file GxEPD2_EPD.cpp:17:10:
14 #if defined(ESP8266) || defined(ESP32)
15 #include <pgmspace.h>
16 #else
17 #include <avr/pgmspace.h>
18 #endif
The header it doesn't find is pgmspace.h, which is the support for accessing the program memory on AVR based arduinos (which use a Harvard memory model). This is not required for most 32bit based CPUs, since they have a flat von-Neumann memory model. Many other 32bit boards (such as the one for the Arduino Due or the ESP32) include a dummy header file to mimic the AVR behavior. Since these are nothing but replacement macros, you might be able to use the implementation of the Arduino Due (which is conceptionally very close to the Raspberry Pico). The definition is here.
Related
I have a Micro bit v1. Days before, I was unable to search the Bluetooth signal of it, so I followed the instruction on microbit.org to upgrade its firmware. But after I copied the firmware file into it, a FAIL.TXT file showed up in the disk MAINTENANCE. What's more, since then on, every time I connect the Micro bit to my computer, it enters this MAINTENANCE disk, no matter I press the Reset or not during the connection. I've tried different versions of firmwares of the Micro bit v1, but none of them succeed.
The details about this Micro bit are shown as below.
# DAPLink Firmware - see https://mbed.com/daplink
Unique ID: 00000000066aff565357825187123855a5a5a5a597969908
HIC ID: 97969908
Auto Reset: 0
Automation allowed: 1
Overflow detection: 0
Daplink Mode: Bootloader
Bootloader Version: 0254
Git SHA: db711ec68a861b9d9b0d7a7a82071796ec117687
Local Mods: 1
USB Interfaces: MSD
Bootloader CRC: 0x0697f838
Interface CRC: 0x4915d882
Remount count: 1
URL: https://mbed.com/daplink
The contents of FAIL.TXT are shown as below.
error: In application programming aborted due to an out of bounds address.
type: interface
So, I am wondering that, what possibly has occured this upgrade failure ? And how can I fix my Micro bit ?
I am 7 months late, I know, and I made an account just ot answer here. I see some strange things I haven't seen before in your details;
You're missing the part of the UID that specifies the version of the
Micro:Bit (4 first numbers are supposed to be 9900 for 1.3 and 9901
for 1.5, not sure if it's different if you have 1.0).
Interface version is missing from the details.
Local mods being set to 1 means you have unsaved local changes to the Micro:Bit.
Remount count being set to 1 means it has failed to flash the previous hex you tried to flash to it. Not a good sign, but it means you only tried (or it only counted) once to reflash the firmware.
Try flashing an erase hex to the Micro:Bit, then an up-to-date firmware hex, and lastly the OOB hex. This worked for me when I experienced a similar issue.
I hope any of this can help you, or any others that stumble upon this post in the future.
Please reach out if you still need help!
This micro:bit has wrong HIC ID (97969908 instead of 97969901). It doesn't have original bootloader that's why you are not able to flash original interface firmware. According to DAPLink 97969908 is STM32F103XB bootloader. I think there are 2 possible solutions: 1st is to flash original bootloader and original interface firmware then, 2nd is to make some with DAPLink source files to compile a new interface firmware that would work with 97969908 bootloader.
See here https://github.com/ARMmbed/DAPLink/discussions/956
For a milling machine I need to connect magnetic linear sensors which output a quadrature signal in order to read the position of 4 axes. The professional digital readouts are rather expensive. After some searching I tried to use an Arduino board and Yuri's digital readout Android software. I kept having issues with the bluetooth connection between my tablet and the Arduino failing.
I've since settled on a four axis serial to USB box, sold by a company which is involved the precision measurement industry. Now my issue is that the software supplied by the vendor for the converter box is only offered for Microsoft Windows. I'd like to run a Raspberry Pi 3 as my readout instead of dedicating a laptop.
I'm reading that running x86 on ARM is possible via QEMU or a paid software option. I'd rather not have to run WINE or a full Windows installation. I think it's possible to make this work in Linux on a Pi3 with a little bit of code. Where I think I will have the most trouble is that the Windows software requires some manner of special code to 'authenticate' the USB box.
Internally the box has a PIC18F45K22 8-bit RISC chip and a MC74HC86A XOR chip. I suspect the latter is used to combine the signals of the four axes before output. The USB to serial chip is a common FTDI FT232RL which I can see connects as ttyUSB0. Running 'screen' against that device has produced no output.
The specification of the microcontroller indicates that it is re-programmable with 1024 bytes of EEPROM. Among the other code they've flashed to the chip, would they have programmed in the 'authentication' code mentioned earlier? Short of de-compiling the Windows program, can I interrogate the device across USB without ruining it?
The microcontroller manufacturer site seems to have reasonable documentation and even code samples. Assuming the flashed code isn't obfuscated, could I download the contents of the EEPROM? From there I suspect I could see what commands are required to initialize the box. I could either remove the 'authentication' or re-write the program in its' entirety and flash it.
the atmega microcontrollers have the internal programmable memory.So the usb flash device write data to internal memory of atmega through spi or it store the program and works as slave?i also want to know can the atmega get program,file in the MicroSD and run without internal memory or it need to run a program in internal disk then including the program in MicroSD?i don't know how the process work in atmega microcontroller.
There are several ways to program the AVR:
Using an external programmer. The Chip is in reset state during this. Then the programmer uses special a special protocol to directly write to the flash inside the controller. This is how your USB programming device probably writes code to the AVR. There are several protocols for this, but the most common one uses the same pins that are used by SPI. You should not confuse them just because of that ;-).
The controller writes the program itself. The chip is actively executing a program. That program on the chip fetches the instructions from e.g. a sd card and using the SPM instruction to copy it to local flash.
The AVR can only fetch instructions from it's own flash memory - you cannot execute directly from RAM or from any other external source.
The best answer for this question you can find at the end or middle of datasheet for AVR device (eg ATMEGA 328P-PU). If you are using some flashing device connected with computer, there is some initialization sequence after start and then there are send some 4 Bytes commands that tels microcontrolers, where to store values to flash and/or eeprom, fuse bits, or cares about erasing etc. There is also posible to read ID of chip.
Atmega microcontroler can be also programmed in paralel mode, where are some bits used for sending commands that tels, what to do with data on data bit.
If you ask about downloading program from SD card or any other device, there is possible to write to the flash through SPM, as there was told above. Some devices do not have part of flash for downloader - if I remember ATMEGA 48, and devices, that have configurable part of memory usable also for downloader, that can handle this, eg. ATMEGA 88, 168, 328. So if you want to download program from SPI, USART, TWI, etc, you need to configure fuse bits and create downloader that will do it for you. I am not sure, how ATMEGA 48 do this, but there si probably possible to write whole flash by SPM instruction.
However the best answer you can find in the datasheet. On pages folowing 255 you can find further information. http://www.atmel.com/images/Atmel-8271-8-bit-AVR-Microcontroller-ATmega48A-48PA-88A-88PA-168A-168PA-328-328P_datasheet_Complete.pdf
I have a project that needs to be compatible with STM32F1s and STM32F4s. I'm starting with a basic project that can use GPIOs and am now trying to get USB HID support. I have USB HID working on STM32F4s with another project using the standard peripheral drivers and USB OTG, but am having a difficult time with the HAL drivers. No matter what I've tried the USB device keeps showing up as an Unknown Device in windows. Where can I best start debugging this issue? Stepping through the code with an SWD makes it seem like the board seems to be working as it should. As far as I can tell the endpoints and descriptors for HID are correct.
Use STM32CubeMX to setup USB for you. Then you need to change the heap size, because the default one is not big enough. For some reason, you cannot change the heap size from STM32CubeMX. To change it, you need to edit the start up file (startup_stm32f4.....s) and find the line:
Heap_Size EQU 0x00000200
and change the value to a bigger one, for example:
Heap_Size EQU 0x00002000
I just got my BeagleBoard-Xm and I'm wondering if there is any detailed step by step tutorials on how to get a very simple bare metal software running on the hardware?
The reason I ask is I want to deeply understand how the hardware architecture works, everything from the bootloader, linkers, interrupts, exceptions, MMU etc. I figured the best way is to get a simple hello world program to execute on the beagleboard xm without an OS. Nothing advanced, just start up the board and get a "hello world" output on the screen. thats it!
The next step would be getting an tiny OS to run, that can schedule some very simple tasks. No filesystem needed, just to understand the basics of the OS.
Absolutely no problem...
First off get the serial port up and running, I have one of the older/earlier beagleboards and remember the serial port and just about everything about the I/O being painful, nevertheless get a serial port on it so you can see it boot.
It boots uboot I think and you can press a key or esc or something like that to interrupt the normal boot (into linux). From the uboot prompt it is easy to load your first simple programs.
I have some beagleboard code handy at the moment but dont have my beagleboard itself handy to try them. So go to http://sam7stuff.blogspot.com/ to get an idea of how to mix some startup assembler and C code for OSless embedded programs (for arm, I have a number of examples out there for other thumb/cortex-m3 platforms, but those boot a little differently).
The sam7 ports for things and memory address space is totally different from the beagleboard/omap. The above is a framework that you can change or re-invent.
You will need the OMAP 35x techincal reference manual from ti.com. Search for the omap part on their site OMAP3530.
Also the beagleboard documentation. For example this statement:
A single RS232 port is provided on the BeagleBoard and provides access to the TX and
RX lines of UART3
So in the trm for the omap searching for UART3 shows that it is at a base address of 0x49020000. (often it is very difficult to figure out the entire address for something as the manuals usually have part of the memory map here, and another part there, and near the register descriptions only the lower few bits of the address are called out.)
Looking at the uart registers THR_REG is where you write bytes to be sent out the uart, note that it is a 16 bit register.
Knowing this we can make the first program:
.globl _start
_start:
ldr r0,=0x49020000
mov r1,#0x55
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
strh r1,[r0]
hang: b hang
Here is a makefile for it:
ARMGNU = arm-none-linux-gnueabi
AOPS = --warn --fatal-warnings
COPS = -Wall -Werror -O2 -nostdlib -nostartfiles -ffreestanding
uarttest.bin : uarttest.s
$(ARMGNU)-as $(AOPS) uarttest.s -o uarttest.o
$(ARMGNU)-ld -T rammap uarttest.o -o uarttest.elf
$(ARMGNU)-objdump -D uarttest.elf > uarttest.list
$(ARMGNU)-objcopy uarttest.elf -O srec uarttest.srec
$(ARMGNU)-objcopy uarttest.elf -O binary uarttest.bin
And the linker script that is used:
/* rammap */
MEMORY
{
ram : ORIGIN = 0x80300000, LENGTH = 0x10000
}
SECTIONS
{
.text : { *(.text*) } > ram
}
Note the linux version from codesourcery is called out, you do not need that version of a gnu cross compiler, in fact this code being asm only needs an assembler and linker (binutils stuff). The arm-none-eabi-... type cross compiler will work as well (assuming you get the lite tools from codesourcery).
Once you have a .bin file look at the help on uboot, I dont remember the exact command but it is probably an l 0x80300000 or load_xmodem or some such thing. Basically you want to x, or y or z modem the .bin file over the serial port into memory space for the processor, then using a go or whatever the command is tell uboot to branch to your program.
You should see a handful of U characters (0x55 is 'U') come out the serial port when run.
Your main goal up front is to get a simple serial port routine up so you can print stuff out to debug and otherwise see what your programs are doing. Later you can get into graphics, etc. but first use the serial port.
There was some cheating going on. Since uboot came up and initialized the serial port we didnt have to, just shove bytes into the thr. but quickly you will overflow the thr's storage and lose bytes, so you then need to read the trm for the omap and find some sort of bit that indicates the transmitter is empty, it has transmitted everything, then create a uart_send type function that polls for transmitter empty then sends the one byte out.
also forget about printf(), you need to create your own print a number (octal or hex are the easiest) and perhaps print string. I do this sort of work all day and all night and 99% of the time all I use is a small routine that prints 32 bit hex numbers out the uart. from the numbers I can debug and see the status of the programs.
So take the sam7 model or something like it (note the compiler and linker command line options are important as is the order of files on the link command line, the first file has to be your entry point if you want to have the first instruction/word in the .bin file be your entry point, which is usually a good idea as down the road you want to know how to control this for booting from a rom).
You can probably do quite a bit without removing or replacing uboot, if you start to look at the linux based boot commands for uboot you will see that it is copying what is pretty much a .bin file from flash or somewhere into a spot in ram, then branching to it. Now branching to linux, esp arm linux involves some arm tables and possible setting up some registers, where your programs wont want or need that. basically whatever command you figure out to use, after you have copied your program to ram, is what you will script in a boot script for uboot should you choose to have the board boot and run like it does with linux.
Saying that you can use jtag and not rely on uboot to work, when you go that path though there are likely a certain number of things you have to do on boot to get the chip up and running, in particular configuring the uart is likely a few clock dividers somewhere, clock enables, I/O enables, various things like that. Which is why the sam7 example starts with a blink the led thing instead of a uart thing. The amotek jtag-tiny is a good jtag wiggler, I have been quite pleased, use these all day long every day at work. The beagleboard probably uses a TI pinout and not the standard ARM pinout so you will likely need to change the cabling. And I dont know if the OMAP gives you direct access to the arm tap controller or if you have to do something ti specific. You are better off just going the uboot route for the time being.
Once you have a framework where you have a small amount of asm to setup the stack and branch to your entrypoint C code, you can start to turn that C code into an OS or do whatever you want. If you look at chibios or prex or others like it you will find they have small asm boot code that gets them into their system. Likewise there are uart debug and non-debug routines in there. Many rtoses are going to want to use interrupts and not poll for thr to be empty.
If this post doesnt get you up and running with your hello world (letting you do some of the work), let me know and i will dig out my beagleboard and create a complete example. My board doesnt exactly match yours but as far as hello world goes it should be close enough.
You could also try TI StarterWare:
http://www.ti.com/tool/starterware-sitara